6.4 停掉生产线和缺陷预防
在团队的所有活动中，哪一件是你觉得最重要的：为新特性编写代码？修复测试中发现的bug？修复生产环境中发现的bug？加速新特性的开发？
令人遗憾的是，在大多数软件团队的优先级列表中，测试的维护都不会出现在靠前的位置。如果办公室大楼里的升降梯坏了，可以确信立刻会有人给设备团队的人打电话。而当测试变得缓慢或脆弱时，除了依赖于它的程序员和测试人员，其他人都不会看到问题的存在。如果你多少还做些测试维护的工作，通常也只在事情坏到令你无法继续忍受，或者因为测试被严重破坏以致产品无法直接发布的时候才做。似乎总是有更重要的事情等着你做。
对测试采取这种思路的团队成员是完全错误的。对依赖于自动测试的团队来说，自动化测试就是团队的心跳，团队需要用一丝不苟的小心和关注来维持它的健康。
丰田的“停掉生产线”
在丰田的制造厂里，每次出现问题时，车间的每位工人都有权力和职责停掉整条生产线。问题马上会得到经验丰富的员工给予的全力关注，且只有等问题得到解决生产线才会重新启动。生产线重新启动之后，会有一个小组负责对问题实施根源分析（root-cause analysis），弄清发生的原因，从而从根源上解决问题。
大野耐1先生第一次提出这一想法时，生产经理们认为他疯了。那时，人们觉得在制造行业最重要的事情当然是让装配线保持运行，必要时每日每夜都不间断。
大野耐先生第一次向经理们提出实现这种新的系统时，有的人听从了，有的人根本不听。一开始，实施了这一策略的经理们发现他们的生产率下降了。每次遇到问题都马上停下来处理降低了它们的产量，而且当他们将产出数字同那些无视老板想法的经理们进行比较时，看上去似乎是老板错了。
然而，慢慢地那些允许生产线停下来处理每个问题的经理们开始发现他们的生产线上停工的情况越来越少了。因为每个问题都以缺陷预防的策略得到处理，这些生产线开始不断为改善机器的质量和运营的过程提供投入。很快，这些生产线的产量便大大超过了那些对貌似发疯的老板阳奉阴违的经理们所控制的生产线。那些经理们的生产线仍然沿着旧时的频率定期地哐啷罢工，被同样的老问题反复地折磨着。
缺陷预防
丰田反直觉却又取得巨大成功的“停掉生产线”策略之所以有效，是因为它是一种更全面的策略——缺陷预防——的一部分，缺陷预防关注于持续改善生产系统。若没有这种更全面的过程，“停掉生产线”的效果将微乎其微。缺陷预防过程分为以下4步。
（1）检测异常情况。
（2）停下手边的工作。
（3）修复或纠正眼下的问题。
（4）调查根源并实施对策。
这4个步骤非常重要，因为它能抓住手边的问题所提供的机会，从而理解过程中一些更为根本的东西。它也意味着让修正问题成为一种习惯，而不是可以推到日后不忙时的一件事情。
举个例子，假设构建被一个失败的测试破坏了。调查原因，发现有个家伙在提交代码之前没有运行所有测试，就是他提交了导致测试失败的代码。他为什么不运行所有测试呢？好吧，是因为他觉得运行测试需要太长的时间，他只运行了自认为覆盖他的改动的那部分测试，然后双手合十祷告一下便直接提交了代码。所以，底层的原因的是特性运行得太慢。理解了问题的根源之后，我们就可以着手修复它了。
有些团队维护一份构建失败的日志，其中记录着每次失败的根源。当有足够的证据证明某个特定的根源有必要处理时，他们便会集中精力来妥善处理它。
把你的团队想象成一条生产线，它为用户生产有价值的特性。如果你发现有个问题在降低它的产出速度，那就停掉生产线，把问题永久修复。实现“停掉生产线”这一策略意味着你决定把获得一套快速、高质量且可靠的测试列为整个团队的头等大事，仅次于处理影响客户的生产问题。当测试出现问题——不论是测试失败这种紧迫的问题，还是闪烁的场景这种无休止的烦恼——都要把最佳的人选推上去，永久地修复它。