软件测试流程改进案例

　　第五章 软件测试流程改进案例

　　5. 1.GSIT的实践概要

　　在实际的项目管理过程中,此次某企业的研发项目规模大约1ML0C,在各软件特性整体发布之前,计划了 2~4个月的CSIT,因为CSIT和软件研发过程几乎并行,对SIT开始时间的延迟很小,所以整个研发周期并没有因为CSIT的引入而延长,反而使SIT在一开始就有足够稳定的代码,从而能够顺利幵展测试,保障了整个研发项目的进度。在不同特性的CSIT计划上,根据不同软件特性的规模和难易程度,相应地安排了不同的CSIT周期。

　　CSIT开始阶段,根据不同软件特性的子功能划分,可以进一步提前测试介入的时间点,所以其实际开始时间要早于计划的时间,具体的幵始时间动态地根据软件幵发进度,由虚拟团队共同决策而定。

　　CSIT实践中,代码与反馈互动紧密,客观上提高了开发的节奏,即使遇到阻断性缺陷,也都能即使解决,由于CSIT人数较少,客观上也减少了阻断性缺陷影响的范围。虽然部分软件特性有延期交付的情况,其中一个特性还因为在CSIT中发现的严重缺陷,而重新设计导致幵发进度整体延期2周,但CSIT都进行了动态的调整,并持续开展测试。

　　CSIT后期,各个软件特性的CSIT按计划交付给SIT的软件都比较稳定,由于种种原因延期的CSIT也都在SIT开始后,继续开展测试,各软件特性的SIT均按计划顺利幵展。

　　5.2. CSIT的组织实践

　　相对于SIT/SVT测试经理,设置CSIT测试经理负责CSIT的整体管理。包括CSIT的整体规划,CSIT人员的安排,CSIT测试资源的准备和与其他团队协调虚拟团队的组建。CSIT过程中还要跟踪CSIT进展和虚拟团队的运转状况,帮助和培训虚拟团队迅速达成目标。

　　多位测试专家组成的CSIT核心团队,负责CSIT中各软件特性的交付质量。

　　测试专家不仅承担某软件特性的CSIT,还要帮助若千其他测试人员完成整体的测试设计,评审其测试用例,并在测试过程中帮助CSIT测试经理协调软硬件资源,并向CSIT测试经理直接汇报测试的进度和质量的情况。

　　在本次实践中,CSIT测试工程师的规模大约是开发工程师的三分之一,低于SIT/SVT的比例。CSIT测试工程师则是CSIT的执行者,虚拟团队的成员。他们需要以主动的姿态与虚拟团队的其他成员共同发掘当前所能够开展的CSIT活动,逐步完成测试用例的编写,完善和评审,并最终执行。测试专家每周都要与其沟通CSIT活动的进展。

　　敏捷要求整个开发团队紧密配合和频繁沟通,最好就在同一个办公环境下工作,而某企业的研发项目是由中美印三地成员共同完成。实践中,美国与其他两地时差较大,主要采用频繁的邮件沟通,并在美国下班前和中国刚上班的这段时间进行电话和视频的沟通。而中印时差较小,刚好是沟通更为紧密的开发和测试团队,各种沟通方式都可以实现。另外,在项目的关键阶段,往往釆用中长期出差的方式,把多地的虚拟团队成员聚到一起开发,进一步加强沟通的效率和效果。

　　三地的团队沟通会议一般安排在北京时间的中午左右,以保证美国和印度成员都能参加。

　　5. 3. CSIT的测试用例/测试环境/缺陷管理

　　实践证明,即使没有各类文档,只要通过各虚拟团队成员间的有效沟通和测试经验,就能完成测试用例主体的编写,包括子功能块的识别和覆盖,以及整体规模的80%。再通过对后续稳定的需求的确认,即可完成整个测试用例,并开展评审活动。当具体的软件设计完成后,可以进一步调整测试步骤,即使在CSIT测试过程中,测试用例译需要进行不断地优化和细化。CSIT所追求的是更具实用性和有效性的测试用例、测试环境和缺陷管理。

　　在测试设计中,人与人之间沟通的力量是巨大的。在CSIT测试用例编?写的过程中,测试人员通过沟通发现了某特性的部分子功能因为开发团队的疏ri,居然没做开发计划。如果后期才发现这个问题,肯定会造成项目延误,而应急投入的人力产出的代码质量也是堪忧的。有效的测试用例评审,往往能使开发人员在与会后,立即发现需求和实现的分歧,在没有真正开展测试活动之前就发现设计缺陷,避免后期更大的改动成本。

　　轻文档的测试思路,造就了精简的测试用例内容。测试用例不再是题目加长篇累赎的描述,而是通过简明扼要的描述,甚至是一句话来概括这条测试用例的测试思路,也可以在后面补充具体的测试点。这种高度概括性的描述,要求测试人员对测试内容有着深刻的理解,轻文本的数量,而重文本的内涵。而且通过实践发现,测试用例评审的效果有明显提高。原来一个测试用例都可能占据整个电脑屏幕,评审者其实很难从这样海量的信息中抓住真正的要点。简明测试用例的优势不言而喻。