但麻烦很快就出现了。第一，开发人员用Java代码写的测试，QA不好理解，也不是很清楚哪些场景被测试覆盖到，哪些没有，所以无法信赖测试结果；第二，测试跟开发共用一套数据库，数据总是受到污染，因此造成测试失败，浪费大量定位和修复的时间。而数据库是由国外的客户控制的，催促了很长时间也没能给测试分离出一套专用的数据库来。
测试红啊红，修啊修，后来一算时间，在自动化测试上投入了120多人天，却依然得不到一套稳定执行的测试用例，不但没办法保证交付质量，还让每个人心力交瘁。于是毅然决然的停掉了。
过了两三个月，客户终于准备好了一套专门用来跑功能测试的数据库，开发团队也对行为驱动开发有了一定的认识。于是又开始写自动化测试，这次用了Cucumber，QA写场景，Dev写实现。
写了大概有100多个场景的测试，又有人开始质疑这一切：第一，整套系统实在是太庞大复杂了，写到现在为止，连1/4都没覆盖到，所以上线还是手工回归。我们到底要花多大的精力才能把所有的场景都自动化起来，这些投入是不是值得？第二，测试环境还是不稳定，比如本地数据跟CI用的数据不一致，比如Tomcat里面部署的应用常常启动不起来，等等。每个问题都要消耗大量的人力。这些浪费能不能平衡自动化测试到最后能够带来的收益？
但团队中还有其他人对自动化测试持有乐观态度，认为问题总是可以解决的，只要坚持不懈就能够看到长期的回报。于是就有了这次讨论。
分析
绘制系统循环图的第二条法则是：“从有趣的地方开始”。在这个案例的场景下，开发团队最关心的是该不该写自动化测试，它对交付能力会带来什么影响，于是我们选择“自动化测试的数量”作为起始点。
接下来是第三条法则──“询问‘它将驱动什么’，以及‘它的驱动力是什么’”
我们首先可以想到的是，自动化测试的数量增加，会缩短发现Bug的周期，但是这个作用是需要测试数量积累到一定程度才会发挥出来的。它同时还会增加测试的开发和维护成本，增加测试执行时间，缩短手工测试周期。见下图：
手工测试周期的缩短会带来交付周期的缩短，提升产品收益，从而使人们更倾向于编写自动化测试。于是在图中就出现了一个增强环路：
而测试的开发维护成本增加，会导致开发进度放缓，从而削弱收益，于是在图的下方出现了调节环路，这条调节环路的存在，会阻碍人们在自动化测试上的投入。
