在绝大部分团队里面,大家遵循的流程都是开发->测试->发布这样的过程。在开发完成后,交给测试进行集成测试,发现Bug后提交给开发,开发再修改这样直到缺陷都被修复。这样的过程导致一个问题:在一个Sprint中,必须留给测试足够的时间,否则会无法交付。而且测试在一开始会比较无所事事,而到了后期又特别忙。我们曾经有个Team,最后采用方法是在一个2周的冲刺内,一周用来测试。这样的过程很显然不够敏捷,效率也不够高。
还有一个传统的问题是开发和测试的矛盾。由于在传统的过程中,开发和测试是对立的,经常引起各种争吵。我经常看到是开发抱怨测试怎么能这么测,这么测有什么意义?但测试就认为这是个Bug。甚至有时候双方不能就这是否是个Bug达成一致。
我们在经过一些回顾后,采用了如下方式,收到不错的效果:
- 在Sprint开始后,测试立即对UserStory编写检查项。这些检查项大部分就是1句话,表明测试准备对这个UserStory做哪些检查。比如对一个登录功能,其中一个检查项是:连续输错验证码4次,验证码应该失效。
- 开发人员在开发中,仔细阅读检查项,并根据UserStory和检查项一起进行开发,并按照检查项自测功能。
- 开发完成后,测试人员立即到开发人员机器上,观看UserStory开发结果,并按检查项进行检查,同时,产品会对功能进行验收。
这样测试人员的工作就被平摊到Sprint各个阶段,不会出现最后才参与。而且由于检查项事先写好,不容易出现开发和测试扯皮。同时这样是把测试人员作为开发Team中的一员,他职责不再是找Bug,而是协助开发人员开发合乎要求的产品;最后是整个团队更加高效、和谐。