4.2.3. CSIT 入口条件
虽然开展测试前仍然需要提前准备必要的硬件资源,如测试仪表和被测设备,以及配合被测设备工作的相关测试环境。但各资源到位的时间需要提前,因为CSIT的加入使测试的介入时间明显靠前。
相比原测试流程,不再一味等待里程碑的确认和文档的发布,而是积极幵展开发和测试活动。可以没有系统需求说明,但只要对此特性的核心功能完全掌握,就可以幵始编码。一旦此功能的某个子功能完成编码,没有设计文档,测试人员也可以开展测试活动。所谓的入口条件,不再是一组僵化的里程碑检查表,而是动态的,是很难从项目开始就完全计划好的,是整个虚拟团队的沟通结果。
4.2.4. GSIT的组织结构
按照测试流程改进的经济性原则,CSIT测试团队应小于SIT/SVT测试团队,测试人员和开发人员的比例应控制在1:3以下。而且鉴于CSIT的灵活性和不确定性,建议多让经验丰富的测试专家参与CSIT。但可调配的测试专家毕竟是有限的,测试专家只能纟耳成CSIT的核心团队,其职责不仅限于自己负责的特性,还要对其他若干成员的软件特性负责,包括帮助其他若干成员制定测试计划和测试策略,在测试过程中把握CSIT整体的质量和进度。测试经理可以通过有限的测试专家,就可以了解到整个CSIT的状态,而无需询问所有成员。
不仅创新外在的组织方式,更要注重内在的团队文化的培养。虚拟团队并不是职责相同或不同而被安排在一起X作的一群人,他们需要通过紧密的协作,而成为一个整体,并将整体的效率最大化。虚拟团队中没有队长和队员之分,成员间互相驱动,相互沟通和配合,共同开展活动,必要时通过讨论共同完成虚拟团队的决策。而这种自组织团队的凝聚力来自于各团队成员的共同目标,就是幵发出更高质量的软件特性。这种自组织团队的建立,能够缓解不同部门成员之间的对立形势,出现的问题不再是系统软件说明书不明确,也不是编码的缺陷或者测试的失误,而是整个虚拟团队的问题。CSIT参与者更着眼于整个团队的目标,而不仅仅是个体的任务。
而敏捷所强调的人的核心作用,必须体现在CSIT团队成员的主动性和驱动性上。在整个开发和测试过程中,CSIT成员每天都要主动与虚拟团队的其他成员沟通各种项目相关的信息,使沟通更加直接和有效。由于CSIT比以往SIT/SVT介入的都要早很多,具体的工作内容是随着软件开发的状态而动态变化的,这就要求CSIT成员从被动的服从指令,到主动发掘自己可幵展的新工作。另外,频繁而有针对性的交互,有利于及早地发现不同成员对特性的理解的偏差,也就更容易及早地解决问题。理想的CSIT测试人员不仅能够设定和完成自己的目标,还能够分担项目经理/测试经理的压力,刺激和驱动项目的进展。
冰冷的文档和邮件只是迫不得己的选择,面对面的沟通和热情洋溢的电话,才是CSIT成员推荐的沟通方式。在可能的情况下,直接走到沟通对象面前开始探讨问题,远比其他任何形式的沟通效率都要高。各成员问主动询问是否需要帮助,将使这个团队成为一个真正高效的团队。
自组织的团队中是不需要管理者下达指令的,但管理者可以帮助和指导团队共同制定目标,提供资源上的支持,并鼓舞每个人的积极性。在这里,管理者需要做的不是控制,而是放松控制,让团队自己寻找最合适的方式来完成1:作。
4.2.5. CSIT的文档管理
敏捷所推崇的轻量化的流程可以轻文档,但并不能没有文档。适量的文档不仅有助于整理思路,还能加快沟通,提高讨论的效果。而且从整个项目的角度来看,包含有几十个人的大团队,文档仍然是最合适的用来传递知识和决策的途径。
这样的思路,不仅适用于需求文档和设计文档,也适用于CSIT测试用例和测试报告。
CSIT提倡适当简化的测试用例。一是由于CSIT开展较早,不大可能拥有大量的被测设备和测试环境,为了达到与使用大环境近乎相等的效果,在测试设计上要求对系统有很深的理解,必须充分利用等价类,在有限的测试条件下简化测试方法,有必要时应引入灰盒,甚至部分白盒的测试手段。再者,CSIT用例应将重点放在测试点本身的完整性上,而不是测试步骤的具体描述上。这样不仅节省了大量的测试用例编写和修改的时间,也使参与评审的其他人员更容易了解用例的要点,能够更好地参与评审。
推荐的测试用例编写计划是,在没有需求和设计文档的情况下,也要完成80%的用例,并开展测试。在测试过程中,结合发布的文档完成剩余的20%。另外,CSIT的知识更多来源于实战经验,其实很难在CSIT开始之初就设计出完备的测试用例,还有很多测试用例是根据测试的深入,而逐渐开发出来的。值得指出的是,CSIT测试用例和测试报告是很重要的CSIT交付物,但不必过于花哨,同时建议减少不必要的长篇文字报告。
如果开发人员能够提供设计文档和UT测试用例,CSIT测试人员必须积极推动和参与评审,并丰富自己的测试用例。另一方面,CSIT测试用例的讨论,也要确保开发人员能够参与,并通过测试用例的评审,使其在编程时就已经充分了解代码使用的场景,从编码幵始就减少设计缺陷的可能性,以减少后期各阶段测试的压力。CSIT测试用例的评审也不一定要在测试开始前完成,经过简单实践操作而完善的测试用例,反而更具参考意义。所以,测试用例只需在CSIT开始的前期完成即可。
4.2.6. CSIT的测试活动设计
由于CSIT提前于整个功能的发布,也不一定有需求和设计文档可供参考,此时开展的CSIT的测试对象是部分子功能的代码片段,更具X模型中探索性测试的特征。也就是说在没有文档支持的情况下,就要把交付的代码片段当作需求和设计文档,通过渐进式的测试过程,由点到面,逐步摸索出软件的功能和实现情况,给开发人员以有效的反馈。而测试人员自身也从由简到繁的实际使用和测试过程中,逐渐加深对系统的认识,也逐渐加大测试强度。
根据通信产品嵌入式软件的特点,不仅按照软件特性把任务分配到每个人,使多个测试工程师能够并行幵展测试。而且一个软件特性还能够继续划分为多个子功能模块,多个子模块之间可以是递进的关系,也可以是并列的关系。幵发人员依次发布具备各个子功能的版本,而CSIT测试人员则针对不同迭代周期里交付的子模块尽早幵展CSIT,并持续开展集成活动,直至整个软件特性的交付。这样的设计实质性地提前了测试活动的介入时间,也使得测试的对象更加清晰,客观上还促使开发人员提高了代码的节奏。
除了各种即时的非正式的沟通外,还建议虚拟团队开展定期沟通会议。会议由各项目成员轮流主持,负责准备此次会议的议题,并完成会议纪要,从而使项目里的每个成员都能从不同的角度体会项目和思考项目。通过沟通会上各成员的状态变化,还能够找出当前整个团队的薄弱环节,由团队成员共同决策并加以帮助。而此次接受帮助的成员在未来,也将会很愿意帮助其他需要帮助的成员,从而实现团队积极互助的氛围。同时,这种正式地进度展示也能够增加团队内的透明度,对团队中各成员能够起到一定的促进作用。
团队间的互相沟通与支持还体现在,当一个迭代周期结束而交付子模块时,开发人员可以进行简单演示,使测试人员能更容易上手,也更充分地理解软件功能。而当完成某子功能的测试后,可以在团队内进行子功能的演示,来确认需求的实现状况,还可以发布给其他需要此子功能的其他团队。使软件的价值不仅一次性体现在最终发布上,在软件特性逐渐完备的过程中,也能得到准用户的试用和反馈。以此来不断确认团队各成员间的联系,明确团队成就,完成团队的自我激励。
面对复杂多变的系统行为,普通的黑盒系统测试只能验证系统行为的最终状态,而很难验证整个系统行为的过程和内部的运转机制,也就无法保证系统行为的一致性。也就是说在同样的激励条件下,系统做出了正确的反应但内部实际上执行了错误的代码分支,或者系统这次及时地做出了正确的反应,但在下一次也许延迟动作,甚至误动作。这种深层次的缺陷,往往要等到后期大规模的测试中才更容易暴露出来,但对于整个项目来说却希望及早地发现这样的问题。所以,有必要在有限的测试环境下,采用更深层次的测试手段以发现更深层次的问题,实现灰盒测试,甚至白盒测试。
快速高效的迭代特别需要自动化测试脚本的保证,以免测试通过的内容在新的迭代中反而出现问题。尽管在某企业原有的测试过程中,自动化测试由专门的团队承担,但往往自动化测试的进展比较缓慢,难以达到快速反馈的要求。所以,尽管原来大多数测试人员只承担手工测试,但至少应该使用自动化测试脚本辅助测试,加强测试压力和减少回归测试所占时间,把精力放在真正值得手工测试的场景上。
4.2.7. CSIT 出口条件
作为灵活的测试活动,完成CSIT中90%的测试用例为参考点,但也仅作为参考点而不是里程碑,通过对CSIT阶段故障数和代码改动的收敛趋势分析,由整个虚拟团队共同决定是否结束CSIT。而且,SIT的开始并不以CSIT结束为前提条件,也就是说在测试环境不冲突的前提下,CSIT和SIT可以在一定时期内共同开展。另外,CSIT还应该为SIT测试人员提供软件特性的培训、演示和直接的测试指导。
