作为测试人员，以前的我们每天参照图1来了解手上还有多少活。

　　图1：等待测试的用户故事个数

　　存在的问题：　　(1)只有故事数量导致我们看不到故事后面工作量的变化。例如，今天测试通过，关闭了3个小的用户故事，但同时今天开发提交了3个大的用户故事。从数量上看，昨天和今天的待完成工作是一样的。在这张图表的暗示下，我们有时要刻意地拒绝优先测试那些比较简单的故事以便让这个数字快速变小的诱惑。　　(2)只看目前手头还有多少未完成的工作无法让人产生太多的成就感或者紧迫感。因为伴随着每日构建，待测试的故事数此消彼长，其数量就象一个随机数，从中我们无法感知测试进度是否在可接受的范围内。还有5个用户故事没有测试？多吗？少吗？来得及吗？没人知道。　　最近，我们改为每天参照图2来了解测试进度是否健康。

　　图2：测试&开发进展图

　　线1：这个迭代至今测试累计完成的工作量　　线2：这个迭代至今开发累计实际已完成（已提交测试）的工作量　　线3：这个迭代至今开发累计理想需要完成（应该提交测试）的工作量　　差距1：线1和线2的差距代表测试人员追赶开发实际进度的情况　　差距2：线2和线3的差距代表开发实际进度追赶开发理想进度的情况　　好处：　　（1）关注工作量而非数量可以更实际地反应进度。除了关注测试进度，也关注开发进度其实也是确保测试进度的方式之一，因为这可以及时预防开发滞后导致测试被动的风险。　　（2）有了历史数据的趋势图，有了和另外的工作量的参照后，从图2上我们可以感到更多的成就感或者紧迫感。这有点象我们跑步的时候如果有个领跑员在身旁，往往会跑得更带劲、更有节奏。个人感觉做软件和跑步有一点不同的是，我们更多的时候追求的不是绝对速度，而是相对速度。因为绝对速度（团队生产率）的提高需要较长的时间，而保证相对速度（团队按照预期将软件产品交付使用；团队内开发按照预期的速度将软件交付测试，测试按照预期的速度将开发好的部分完成测试和缺陷修复的验证。。。）则是每个迭代都要力争的。

最新内容请见作者的GitHub页：