硝烟中的 Scrum 和 XP（四）

                                                              我们怎样做测试

把验收测试阶段缩到最短

---

把需要花在验收测试阶段上的时间减到最少

• 全力提高Scrum团队交付的代码质量。
•  全力提高人工测试工作的效率(即，找到最好的测试人员;给他们最好的工具;确保他们上报那些耗费时间、却能够被自动化完成的工作)

 

该怎么提高 Scrum 团队提交的代码质量呢?我们发现下面这两种办法效果很好:

• 把测试人员放到Scrum团队中
• 每个sprint少做点工作

 

把测试人员放到 Scrum 团队来提高质量

---

测试人员就是“验收的家伙”

如果没有任何事情需要测试，那测试人员该做什么?

首先，他应该要为测试做准备。包括编写测试规范，准备测试 环境等等。

 

在每个 sprint 中少做工作来提高质量

---

简单来说，就是别把太多故事都放到sprint 里面去!如果碰到了质量问题，或者验收测试周期太长，干脆就每 个 sprint 少干点!这会自动带来质量提升、验收测试周期缩短、影 响终端用户的 bug 减少，并在短期内得到更高的生产力，因为团队 可以始终关注于新的东西，而不是不断修复出现问题的旧功能。

 

验收测试应该作为 sprint 的一部分么?

---

有些团队把验收测试当成了 sprint 的一部分。但大部分团队都没这样做。

 

Sprint 周期 vs. 验收测试周期

---

在 sprint 1 之后，我们得到了满是 bug 的 1.0.0 版本。在 sprint 2 中， bug 报告开始涌入，团队花了大部分的时间来进行调试，然后又被 迫在 sprint 的中期发布了修复了 bug 的 1.0.1 版本。到了 sprint 2 末 尾，他们发布了 1.1.0 版本，提供了一些新特性，但 bug 数量有增 无减，因为他们从上一个版本发布以后就一直被 bug 所干扰，所以 能够用来保证代码质量的时间就更少。在 sprint 2 中的红色斜线表示出了混乱的存在。

解决办法：全力提高 Scrum 团队发布的代码质量。在一个 sprint 中 及早发现并修复 bug，要比 sprint 结束以后再这样做的代价小得多。

方式 1:“在旧版本可以产品化之前，不构建新特性”

方式 2:“可以开始构建新东西，但是要给‘将旧功能产 品化’分配高优先级”

糟糕的方式——“只关注构建新东西”

 

别把最慢的一环逼得太紧

---

有些团队把验收测试当成了 sprint 的一部分。但大部分团队都没这样做。

假设验收测试是你那里最慢的一环。测试人员稀缺，或者低劣的代 码质量造成了过长的验收测试周期。

• 让一些开发人员去做测试人员的工作
• 延长sprint长度，把验收测试放到sprint里面来。
• 把一些sprint定义为“测试sprint”，其中整个团队都作为
• 验收测试团队进行工作。
• 雇佣更多测试人员(即使这会意味着减少开发人员)。