一旦他们因为某些因素而倒向反对方,对整个改进计划的影响是非常不利的,必须全面考虑其避免大改动和过多风险的要求,使其保持满意,而争取其支持。B区的内部/外部用户与测试流程改进的利益密切相关,而他们没有过多的权力,可以通过适当的沟通来满足他们对利益关注。A区的开发团队和系统工程师也是流程改进的参与者,应该多增加他们的利益与测试流程改进的关联程度,以增加其参与的积极性。
4.1.2.测试流程改进策略过程
管理理论认为:管理软件项目的过程能够保证软件产品具有相对稳定的质量。也就是说,产品的质量依赖于企业的过程能力,而不依赖于个人能力。而且通过不断完善过程,可以不断提高产品的质量。更重要的是,有效的流程和流程改进必须适合企业自身的特点,否则只能增加管理难度,增加成本,最后却没有带来产品质量的提高。
根据利益相关者分析,不可能完全颠覆某企业的软件项目开发和测试流程,必须利用对通信产业嵌入式软件幵发的流程和运作细节的深刻认识,将理论和模型以最优的方式应用于某企业的测试过程改进实践。力求以尽量小的变动,取得尽量大的效果,以减小组织和个人对新流程的不适应,实现与老流程的无缝对接,保持对内外部用户交付高质量的软件,进而达到投入产出的最优配比。
测试流程的改进应从组织结构,文档管理和测试活动三个方面幵展设计。
4.1.3.测试管理模型的选择与借鉴
为了进一步完善现有的测试项目管理流程,通过对各测试模型和流程的研究,整理出如下对当前某企业测试流程改进可借鉴的思想精髓和方法论。
从过程管理的角度看,V模型和W模型都可以认为是基于软件幵发瀑布模型的优化和细化,其完全继承了瀑布模型中,将各个活动定义为阶段性和串行开展的局限性。
X模型建议,多个程序片段并行执行开发和测试,模型中的亮点探索性测试的提倡也是为了避免把大量时间花费在测试文档编写上面,而增加真正用于测试的时间。
H模型提出,测试流程可以与其它流程并发的进行,当某个测试准备就绪时,软件测试即从准备阶段进人到测试执行阶段,尽量缩短项目周期。
前置测试模型指出,测试工作因尽早介入,每个完成的组件都可以尽快开展测试,用较低的成本来及早发现错误(同样错误的后期纠错成本往往要大得多),并且在此过程中软件开发和测试人员应密切配合。
相对更强调阶段性和文档驱动的传统开发测试流程,敏捷的概念颠覆性地提出四句宣言。其中“个体与交互胜过过程与工具”更强调组织中优秀的个人和团队协作的作用,任何强大的方法和工具只能构成组织的外强,如果没有内在人的核心力量的话这个组织只能是中干的。因为方法和工具时死的而人是活的,优秀的成员即使只有普通的方法和工具,也能比使用优秀方法和工具的普通成员做更好。虽然敏捷主张个体和交互,但仍然需要过程与工具。例如,Scrum大致是遵循产品负责人整理产品需求(Product Backlog) 规划出本次迭代目标(SprintBacklog)今成员细化任务并完成代码和测试(Sprint Burn Down)—发布具备部分功能的但可用的软件产品(Sprint Review Meeting & SprintRetrospective Meeting)—幵始下一次迭代。而XP的内部过程,实际上是一个个测试驱动开发的子循环(TDD,Test Drive Development)。当需确定了某个版本用户需求并规划为多个轻量级的迭代后,对于某功能是实现,并不是立即开展设计和编码工作,而是首先编写测试用例和测试代码,再编写相关的功能代码以满足测试。然后,继续添加其他功能,直至完成全部的开发功能。
“可以工作的软件胜过面面俱到的文档”也是敏捷提倡以人为核心的另一方面的表述。传统是瀑布幵发模型及其优化模型,大都是文档驱动型。例如需求文需要首先完成,开发人员再根据需求文档完成设计文档并开发,测试人员根据各种文档编写测试用例和开展测试,整个过程中各成员间都以文档为纽带和依据,缺少任何文档都可能直接延迟甚至中断产品的发布。但过多的文档将会分散了各成员精力和焦点,各种延误导致文档的不及时更新可能造成项目休克,文档编写和和后期修改不定期地冲击项目组成员的工作量。所以,敏捷提倡少些文档,而只写必要的文档,消除对文档强烈的依赖,更多的开展项目成员之间面对面的交流,帮助软件不断地发布可用的版本。具体实践包括,项目成员最好是在同一间大办公室中工作,办公环境幵放便于交流,每天项目组成员都要一起幵站会,所有项目和个人进度都在白板上更新和公示。但敏捷仍然需要文档来固化一些主要的需求和算法,也需要进行内部和外部的比较正式的文本交流,但无具体的硬性要求,团队可自行决策。
4. 2.流程改进的方案设计
4.2.1.改进方案的整体设计
在项目管理中,按照尽早开展测试的原则,在具备开展SIT/SVT测试条件之前,针对具备测试条件的软件代码的子功能片段,利用少量的测试人员和有限的硬件环境,幵展持续的集成测试活动CSIT (Continuous Integration Testing)。将原来先编码再测试的研发过程,转变为编码加测试,使CSIT尽量与幵发活动同步幵展,并尽快发布给snv-力求成为有效和高效的测试。
CSIT并没有颠覆某企业整个瀑布开发流程,SIT/SVT的阶段性仍然明显,但CSIT本身并不是一个固定的阶段,与其他阶段无硬性的阶段性要求。对于某些简单的软件特性,甚至可以不做CSIT。通信设备嵌入式软件项目的巨大规模,在宏观的层面上仍需要一种自上而下的设计和规划,但在比较微观的具体实践中,则可以在前期的测试中开展灵活而敏捷的CSIT。
由于CSIT与代码进度结合得非常紧密,每当代码发布新的子功能,CSIT立即对新增和改动的部分幵展灰盒甚至白盒测试,更有针对性也更关注软件内部运行机制,所以测试过程也更直接和深入。而传统的SIT/SVT则是要在整个代码的正式发布后才幵展,发现缺陷更像是在黑暗中摸索代码外部输入与输出之间的关系,缺陷发现的效率和深度有劣势。
CSIT并不期待软件能够交付稳定的代码,但经过CSIT需要交付给SIT的应该是实现绝大多数软件特性,且比较稳定的软件版本,保证其主要功能完好,无阻断性故障遗留,而不是对交付软件的全面测试。CSIT也不是UT,UT仍然需要开发人员自行设计和完成,相对而言UT将更多的精力放在白盒测试上。
CSIT测试团队是由测试工程师组成的专门的测试团队,他们和自己所属软件特性的系统工程师,以及各相关的软件工程师们共同组成虚拟的自组织型团队,充分发挥主动性和参与性,着力培养来自不同团队的工程师之间的紧密合作,充分利用他们的长处使虚拟团队产生最大的效能。
4.2.2.CSIT的经济性设计
根据边际产量递减规律,在项目整体技术水平和其他资源投入不变的条件下,持续增加人力投入会在i/11/m三个区域产生不同的效果。在从无到有的I区,随着人力的投入,产出几乎线性增加,每增加一个人力投入产出逐渐增大,人均效益也逐渐增加。在II区,随着人力的继续增加,总产量仍在提高,但等量的人力投入所产生的产出逐渐减小,人均效益也幵始下降。m区则说明了,继续增加人力对产出己经起到了负作用,越增加人力产出下降越快,人均效益大幅下降。
另外,投入产出比来讲,A点的效率最高,且效果也比较好。B点的效果最好,但效率有所下降。对应于软件测试团队的规模选择,应该把CSIT测试团队的规模选择在A点附近,甚至小于A点。而SIT/SVT为了取得最高质量的版本发布TP,并不允许过多地考虑人力成本,所以其测试团队规模往往在B点附近,并不是最经济的测试方案。也就是说CSIT并不奢望取得最大的测试产出,也不追求完备的软件功能和十全十美的版本质量,CSIT是以有效和高效为目标,以更小的团队规模取得最大的边际产出MP,为SIT/SVT做好先期的测试准备。
具体来说,CSIT测试团队的早期加入,必然出现大幅增加大量缺陷的发现和修复,但如果一味增加测试人员,不仅使沟通分散,测试职责模糊,而且有限的硬件资源也无法满足所有测试人员的需要,甚至可能出现测试人员闲置的情况而影响整个CSIT团队气氛,无论效率还是效果都不是最优。
