使用Kanban，当我完成功能A的测试，就会直接提交给客户。我感到一种成就感。产品部署是我辛勤工作的回报...结束...任务完成。我感觉我控制了功能A的开发速度。我越努力，测试效果就越好，越能集中注意力，测试速度也越快。我们南方人有句话叫“把那活儿办了”，我被它激励着。但只要有需要，我仍有做更多测试的自由。

　　身为测试我爱Kanban-之三

　　...测试没有完成期限...想测多久就测多久。

　　回到Scrum的黑暗时代，在迭代版本结束时，所有迭代功能都必须完成测试。由于编码工作通常会持续到最后一刻（我们无法控制），测试人员有时不得不偷工减料。甚至有时整个团队（比如：开发工程师，市场分析师）都会跳出来协助测试，压缩测试时间的趋势仍然存在。团队渴望成功。但成功更多的是通过交付的功能特性的数量来衡量，而不是它们的质量。这就是最后期限的代价

　　使用Kanban，没有最后期限...对你没听错！测试人员需要测多久，就测多久。即使与之前预估的时间差距很大，也不会造成迭代中时间的浪费或局促。根本就没有迭代！警告：我担心不熟练的测试人员在拥有这样的自由后会遇到麻烦。大多数测试人员已经习惯了被告知还剩多少时间可以测试（即，“时间到了！”原则）。所以，使用看板，应用其它的测试完成原则来判断是否结束测试就变得更重要了。

　　身为测试我爱Kanban-之四

　　回归测试可有可无。什么？太可怕了！！！

　　回到Scrum的黑暗时代，每次回归测试花费我们4天的时间。产品界面有很多业务逻辑，大量拖放和下拉式功能，和动态数据，因此不适合做自动化。我们回归测试的方法曾经是投入一堆人来做（参见我的博文Group Regression Testing and Chocolate）。使用Scrum，每次产品部署都是一个完整的版本，包含大约14个模块，涉及产品的很多东西。 这样，我们经常做包含所有模块的全量回归测试。但即使做完一次详尽的回归测试，也仍会有一两个遗漏bug（即，bug遗漏到生产环境）。

　　你问我回归测试的失败有多频繁。…不是很频繁，但，在我看来，这是很大的浪费。

　　使用Kanban，每个版本只涉及产品的一小部分，所以我们不再打完整版本，这就像一个产品补丁。因为每个版本只改变产品的一小部分，所以每个版本我们不再做全量的回归测试。这其实风险很低。为什么要测试那些不变的东西？

　　所以现在我们做回归测试就是只考虑一个风险：待上线的那个功能特性。这有时意味着回归测试需要1个小时，有时不需要回归测试。至今为止，回归测试完全在浪费时间。这是件好事。

　　我们在2月份改用Kanban，至今为止，产品发布没有遗漏一个bug（是的，但愿好运长久）。

　　这个成功也许只是一个巧合。或者...也许团队把注意力放在功能上，更容易避免出现遗漏bug。嗯...

　　身为测试我爱Kanban-之五

　　当我们在最后一刻发现bug时，不能避之不理。

　　我们准备在明天发布一个超级重要的功能。不好，你还不知道么...我们又发现了好多bug。

　　回到Scrum的黑暗时代，我们可能这样说服自己发布带有bug的版本：“没那么可怕...也许用户不会注意到...我们经常随后发布补丁”。

　　但是，使用Kanban，事情可能变成这样：

　　“...嘿，我们明天不要发布，让我们多给自己一天时间测试”

　　● 没有人必须加班。

　　● 迭代计划不需要重做。

　　● 没有既定的固定维护时间窗口限制我们的灵活性。

　　● 质量不是迭代计划的牺牲品。

　　● 我们不需要带着已知的bug进行发布（也就是说，发布了就不会有任何已知的bug）