我们怎样做测试
把验收测试阶段缩到最短
把需要花在验收测试阶段上的时间减到最少
- 全力提高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”,其中整个团队都作为
- 验收测试团队进行工作。
- 雇佣更多测试人员(即使这会意味着减少开发人员)。