在坐地铁的时候，我经常看到一个宣传短片“有序才能通畅”。一个象啤酒瓶形状的窄口玻璃瓶里装满了各色小球。当所有的小球都一股脑向瓶口冲过去时，任何一个都出不来。而当小球按次序一个跟一个时，每个都能很顺畅地从瓶口出来。然后画面出现“有序才能通畅”的字样，提倡大家在地铁里保持秩序、确保通畅。看着这个短片，我不禁想到了我们工作中不那么通畅的情景。

　　情景一：自从项目实施持续集成后，我们早上经常收到自动化测试用例失败的信件。例如，昨天还成功的测试用例在测试环境、被测系统和测试脚本都没有修改的情况今天居然失败了！又如，今天失败的是这几个测试用例，仔细一看，上周也是这几个，上个月还是这几个。而另一方面，我们其他的一些开发和测试人员还在不断地添加新的测试用例呢！我认为此时我们的瓶颈在于这些失效的自动化测试用例和测试用例执行时的稳定性，加快新测试用例的开发其实对于产品质量的健康检测没有太多的帮助。因为经常失败却一直不维护的测试用例集就象破了洞的渔网，有人会认为那个网还在使用应该是不会有漏网之鱼的，直到有一天有条大的漏网之鱼在产品环境被用户发现。所以，它的风险是隐蔽的，危害也是不容忽视的。在这种情况下我建议：不要在持续集成中自动化测试用例执行“常红”的情况下再继续添加更多的自动化测试用例，而应该先解决老问题。

　　情景二：自从我们使用Kanban来可视化用户故事的状态后，我们更清晰地看到在一个迭代刚开始的时候，处在“可测试”那一列的用户故事特别少；而到了迭代的后期，处在“可测试”那一列的用户故事特别多。可以这样说，前期测试在等开发，后期开发在等测试。所以我们面临着这样一个尴尬的情况：好不容易加快了开发或者测试一个环节的速度，整个项目的节奏还是快不起来。因为整个项目组的效率其实是受制于当下的最慢速度的。如果单一环节或者个体加快速度，但整体出现瓶颈和拥堵，那么理清优先级、解决瓶颈问题比追求速度更重要。此刻，我们是否应该抛开角色的界限，当开发是瓶颈的时候，测试人员帮助开发人员进行环境搭建、测试数据的准备、联调等，以期让被开发的用户故事能更快地交付测试？而当测试是瓶颈的时候，开发人员帮助测试人员进行基于测试用例的测试和测试自动化，让测试人员更多地进行基于风险的测试和探索式测试等？在这种情况下我建议：不要让处在Kanban某一列的用户故事特别多或者特别少，而应该全团队一起先解决瓶颈。

　　无论在地铁或者软件开发中，快速都是大家追求的。但整体的快速和个人的快速不同：整体的快速必须建立在有序的前体下。有序才能畅通，地铁如此，开发亦然。

版权声明：本文出自 zdlzx 的51Testing软件测试博客：http://www.51testing.com/?56882

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。