敏捷与测试

敏捷这个话题，很多组织在谈，也有在实践的。我之前所在的组织，做过RUP和敏捷的整合尝试，有收到过一些效果。这里把我个人的实践以及一些体会整理一下，分享给大家。

首先，为什么要敏捷？

---为的是更好的迎合市场和客户的需要，能快速响应变化。之前的组织是做产品的，快速响应的要求来自于两个因素。1，竞争对手的。人家推陈出新，我们也不能落后。否则人家一做市场推广，江山就被他们占去一片了；2，客户的。潜在重要客户关注的需求，我们得尽早做出来好让他对我们的产品满意愿意掏钱买。

RUP不是不能接受变更，但是它的方式是控制变更，也就是变更是它不希望看到的。但是加入敏捷，就是要很好的适应变更。来了变更，不影响当前迭代，就自然而然将变更放到下一个迭代中去，原先规划的迭代任务可以根据优先级做退让。

其次，敏捷给测试带来的挑战。

很多时候，大家谈敏捷，很少谈到测试。从我的观点来看，敏捷之后，测试反而显得更重要。因为敏捷希望每个迭代出来的产物都是可运行可演示甚至可交付的，这绝对需要测试来保障。其实敏捷之后，对于尽早测试，全程测试反而支持的更充分了，是好事。只是对测试带来的压力就更大。体现在：

1. 管理迭代中开发结束与测试结束的时间差。

   每次迭代，我们的目标是可运行甚至可交付，那也就是说需要事先定义迭代成功标准，并且通过测试去校验该标准是否达成。但开发跟测试总是有个时间差的，你这边还在测，可能开发就需要投入到下一个迭代开发中去了，为了赶时间，不可能等待你完全测试结束，哪怕只相差一两天，虽然他们也还是会留人力处理后续的缺陷，但是你已经落后了，所以一定要能从前一个迭代中腾出人力来及时进入下一个迭代，并且他们要有能力将前期获取的信息有效传递至后面参与进来的测试人员，如此循环。另外作为测试负责人要事先控制时间差，要参与到迭代任务分配筛选计划中，尽量避免发生时间差过长的现象。

2. 管理讨论结果

   因为敏捷迭代有很高压力，就是在规定的时间内完成迭代目标。一般来说，开发人员还是做不到将需求做到够细、将设计做到够细再入手编码，于是很多时候会在白板上讨论比划来不断明确一些东西。有时候这就是我们测试的依据，这也涉及到RUP非常关注的输入输出原则，非常重要，所以我们不能轻易只将这些东西记在脑子里，但我们又不能做到每次要求他们文档化，于是我们想了个办法，那就是把黑板上的结论拍照片存档，这招很管用，既节约了时间又记录了讨论结果。

最后，我将我之前实践的流程图分享出来。

图一：整体研发计划，分若干迭代完成。

图二：每个迭代的子流程。