循序渐进的敏捷-交叉测试

   由于各种原因,团队人员换了一些人,新到的团队成员,由于对业务不够了解,对系统的代码和架构,也不是很清楚,很多时候测试也不到位,导致了一系列问题和bug。很多问题在我们看来都是不应该发生,或是当时如果仔细测试,是完全可以避免的问题。

  针对于这样的情况。我们进行了总结和反思,决定尝试加入交叉测试,来提高系统的质量。

  交叉测试的时间和范围

   迭代的功能完成之后,开发人员互相检查别人的功能和代码,并进行足够的测试,测试和检查的范围包括系统数据库设计、业务需求、解决方案、代码(注释、代码风格)、数据表等。

  交叉测试的流程

  开发人员在完成一个功能之后,找到另一个人员,进行交叉测试

  1. 讲解业务需求。

  2. 讲解解决方案。

  3. 功能演示

  4. 代码交叉测试

  5. 功能测试

  期间,交叉测试人员,随时提出问题和看法,尽早发现开发者在业务和设计方面的问题。

  交叉测试的优点

  1. 对模块的了解不只局限在一个开发人员身上,分担了项目的维护风险;

  2. 规范代码,至少在注释和代码风格方面能保障;

  3. 避免一个人思考问题和对业务的理解存在的遗漏或盲点,多一个人查漏补缺会避免不必要的bug;

  4. 确保所有的功能至少核心功能,都有两个以上的人测试到;

  交叉测试的缺点

  1. 交叉测试会占用开发时间,熟悉别人的功能和代码都要花不少的时间,我估计测试时间是开发时间的1/4至1/3;

  2. 队员水平参差不齐,开发人员和交叉测试人员对业务和代码同样不了解,这样就无法保证交叉测试的质量;

  3. 尽管花了很多时间,有可能还是无法保证交叉测试做完之后,测试范围覆盖到全部模块的业务,无法确保需求或是业务的问题;

  4. 交叉测试会导致开发者会不关心bug的责任问题。

  交叉测试注意的问题

  1. 交叉测试者一定要理解开发人员的业务需求和解决方案,这样才能达到了业务讲解和理解的目的,才能提出问题;

  2. 避免不讲业务需求和解决方案就直接进行测试,这样无法保证交叉测试的质量;

  3. bug应该属于团队所有成员的,不应该由某个人来单独负责,bug也作为一项任务;

  4. 关键性模块才进行交叉测试,这样既避免了交叉测试占用太多的开发时间,又避免了核心业务的不稳定;

  5. 尽量避免不了解业务的人员去给其他开发人员做交叉测试;

 

发表评论

电子邮件地址不会被公开。