测试人员则需要在一两天内完成子功能的预测试,反馈给幵发人员此版本是否可用,如果没有重大问题则继续开展CSIT。子功能的不断发布,使软件项目的进展清晰可见,更细化了项目管理的颗粒度,更容易使风险在产生初期就暴露出来,进而提前规避其变成更大风险的可能性。这种小型的发布还应用于公司内部给其他团队,如硬件性能测试团队和生产团队,使他们有具备某些特定功能且比较稳当的版本可用。而且这些准用户的反馈,更接近于实际的用户,对于软件的优化很有帮助。
由于子功能的发布可以是包括各层软件的整体发布,也可能是子功能中某层软件的发布,原有SIT/SVT的测试方法并不完全适用,而且CSIT更要求加强对内部实现机制的测试,所以实践中广泛应用的是灰盒的测试手段。一般是运用不同层软件的调试命令,模拟软件外部的输入,来测试软件模块的反应。也可以在真实输入的情况下,用调试命令观察软件模块内部和模块间的信号和状态变化。特别是对于反向测试和异常测试,很多情况是在普通SIT/SVT很难模拟和测试到的,运用调试命令则可以实现,CSIT大大增加了异常分支的覆盖范围,进而减小了系统潜在的风险。
CSIT进展的节奏很快,快到难得有回归测试的时间,最好的方法就是自动化测试。实践中,由于公司的自动化测试框架的维护成本较高和测试时间有限,采用的是各成员比较熟悉的轻量化的自动化测试工具,脚本也多是自动化测试过程加人工检查测试记录和结果,实际上是半自动化。但即使不是全自动的回归测试,也节省了大量的时间,对整个CSIT的进展有很大的帮助。
5. 6软件测试流程改进评价
软件项目质量和进度测试工程师提前参与到软件项目中,尽早开展各子系统的小规模集成测试。
随着软件组件的不断交付,逐步扩大集成范围,并对核心功能进行持续的集成测试。一方面,CSIT通过沟通和测试发现了很多需求和设计的不一致,另一方面,CSIT找到许多设计缺陷并帮助开发人员完成再设计。
稳步推进的CSIT,使前期的子系统得到充分的测试,发现了大量的缺陷,高质量的交付软件减小了后期出现阻断性问题和海量问题的出现,使后期的SIT/SVT更加顺畅和高效,保证了整个测试周期,最终有效保证整个项目的交付周期。
组织运转效率和成本从时间安排上,CSIT自身的周期就很短,而且大约80%与开发周期并行,仅占用的整个研发项目周期中很少的部分不足10%,串行开展的SIT/SVT共计占用项目周期约40%。
从组织安排上,CSIT实践中开发工程师和测试工程师的比例大于3:1,而某企业研发项目中开发工程师和测试工程师的整体比例是2:1,也就是说CSIT测试工程师参与人数相对较少,而后期大规模测试的SIT/SVT投入的人力资源更大。而收获的缺陷数量却与SIT/SVT缺陷数量之和相当,无论是从人均产出的角度衡量,还是从单位时间的贡献上,CSIT的投入产出比都是更出色的。
在项目实践中,通过组织和鼓励各角色间的直接和充分的交流,尽量降低组织中的沟通成本。CSIT使代码功能不断向真实的需求逼近。快速的测试结果反馈,能够使开发人员及时地更正代码中的问题,避免了前期简单的问题隐藏到后期变成复杂问题的情况,大大减小了解决问题的人力和时间成本。员工是公司最宝贵的资产之一,CSIT更充分地利用了测试团队的人力资源,减少了部分测试人员在现目前期的空闲状态,提高了测试工程师的周转率,为某企业节约了人力成本。 同时,CSIT也增加了测试设备和被测设备的使用率。
CSIT中测试人员的收益CSIT中的测试人员可以更深入地涉及到软件子系统的内在运转机制,与虚拟团队中开发人员的沟通更有助于其技术水平的提升。自组织团队的工作经历培养了参与者自我驱动的工作习惯和更积极的工作态度,也将使CSIT的测试人员在意识上得到升华。
CSIT作为一个新的尝试,许多测试人员都主动要求投入其中。但CSIT测试团队规模较小,对投入其中的测试人员可以看做是某种特别的认可和鼓励,这种非物质的激励将成为CSIT参与者和其他测试工程师的继续努力的方向和内在动力。
5. 7.流程改进过程中的难点和建议
CSIT的测试计划于开发计划安排得非常紧密,一旦遭遇代码的延期或者阻断性的缺陷,都会直接导致CSIT的整体后延,这种情况是可预见且很难避免的。
所以在做项目计划的时候,为CSIT预留1~3周的缓冲期是必要的。而在CSIT计划中,为复杂子功能预留更多的测试时间也是合理的。
有的成员一时还没能达到敏捷性的要求,不能够主动地推动项目进展。他们思维还是停留在阶段性开展的固有流程上,等和靠的行为比较多,不能够积极地解决问题。比如,等文档的发布,而不是主动地发问;等软件发布,而不是主动与开发人员沟通软件进展和可测试的内容?;靠上级安排计划,而不能主动规划好自己的测试计划;靠上级推动,而不能主动地协调各方资源开展工作。需要对他们加强培训和引导。
CSIT对测试人员整体素质要求很高。不仅要求具有主观的能动性,还需要其对系统有较深的认识,对测试经验要求也比较高,反而在一定程度上降低了对开发人员的要求。同时对多个软件特性开展的CSIT,进一步加大了对CSIT测试人员数量的要求,对后续的SIT/SVT的人员配置有一定的冲击。
三地成员组成的团队,沟通成本比较高。虽然在项目关键的时期采用中长期出差的方式加强共同,但毕竟与理想状态有所差距。三地共同研发的时差问题是客观而无法解决的沟通障碍,三地成员能同时出现的时间段比较有限。好在两地间开发和测试人员的时差不大,沟通比较方便。
语言的天然障碍有一定的影响。以英语作为母语的成员与仅用英语作为工作语言的成员间的交流效果得不到保证,往往是会上沟通,会后还要发邮件重复确认。虽然无法跨越,但应该尽量在会前多做功课,会上进行更有计对性的交流,可以得到一定程度的改善。有条件当然建议安排英语较好的成员入队。
