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