我们成功的关键是采用“完整团队”（whole-team）的方法,团队里的每个人都致力于将所有回归测试实现自动化，我们有很多的技术和观点来帮助解决自动化中遇到的问题。自动化测试金字塔的每一层都包含不同的工具，而且大家可以关注不同层。开发人员像写代码那样编写单元测试用例，测试人员更多的是进行GUI测试的自动化，在FitNesse中，双方在中间层合作。然而，在每一个用户故事完成之前，团队中的每个人都负责每个用户故事的所有测试活动。
自动化测试给我们一个快速的反馈周期。如果在几小时内任何一个现有的功能点遭到破坏，在工程冲刺时，我们应该腾出时间来做出改变，使加入更多测试用例后的反馈周期仍然很快。我们知道是代码的哪些改变引起的这个问题，并立刻进行修复。我们可以在经常发布新业务价值的同时，达到公司的要求，开发出最高质量的产品。
1.10 持续改进
2011年是我们自动化测试之旅的第8年，总是要面临新的挑战。正如本章所述，我们的GUI测试套件已经增长到需要2个多小时来运行。这个时间太长了，所以我们将它划分为两个测试套件，并在两个从属机器上并行运行。这需要进行大量的工作，因为有些测试依赖于其他测试，过去没有好好实施而是采取了折中的方法，现在要为此付出代价。我们有超过5400（这个数字还在增长）个JUnit，并且重构的FitNesse测试套件在30分钟内完成。
我们知道在单元级别中的测试覆盖率，但是并不知道在功能性或GUI级别的测试覆盖率。我们目前采用一个的工具进行实验，可以测量出FitNesse测试的代码覆盖率。
相比于8年前，我们现在对自动化测试设计有了更深入的了解，并且我们的测试需要大规模的重构。无论何时，当加入一个测试用例或者对其进行修改的时候，我们都尝试去改善测试，但是只在工程冲刺阶段才进行大规模重构。我们通过一些开源工具进行观测，并不断尝试我们认为可以降低测试维护费用或者提供更快反馈的新工具。
在GUI测试中我们也是这么做的。几年前，当我们发现Canoo WebTest并不能很好地支持JavaScript的时候，就在所有回归测试中开始使用Watir编写新的功能点。约一年之后，Canoo WebTest升级到比那时的Watir可以更好地处理JavaScript和Ajax，而Watir更难与构建过程整合，所以在保留现有的Watir回归测试脚本的基础上，我们又切换回WebTest。
我们也进行了调查，准备使用Slim来替代Fit进行我们的FitNesse测试。同样，我们可能不会立刻把所有FitNesse测试转为Slim，但我们同时发现维护多种工具也没有很大问题。
这些年来，我们的员工相当稳定。一位新程序员和一位测试人员来了又走，但是团队的核心成员一直保留着。我认为这是因为优秀的人才乐意留在他们可以尽最大努力工作的地方，那就是我们团队。比如，我们允许他们做类似自动化回归测试的事情。我们有一些有趣的转变，一位测试人员决定成为一位程序员，所以他参加了一些Java课程的培训，另一位程序员跟他一起合作，他的学习速度非常快。同时，他仍然保留了自己在测试方面的兴趣，尤其在性能测试方面。另一位程序员一直都无法采用TDD方法，尽管经过了大量的指导和培训，因为他的代码始终没有达到标准，最终只好让他离开。我们从不会去刻意填补空缺职位，但我们的团队效率却在提高。每一个团队都需要恰当的人选，而且那些人需要时间来学习、实验和提高。
1.11 总结
你的团队如何？阻碍你进行自动化测试尝试的最大问题是什么？你的团队是否缺乏一个特殊的技能组合？你是否只是需要时间来制定和实施策略？你是否还在等待合适的硬件或者软件？想想你现在能做一些什么事情来提高自动化测试并缩短反馈周期。要有耐心，一步步慢慢来。对你得到的结果进行试验和分析评估，不断进行哪怕只是很小的改进。不知不觉间，你就会享受自动化测试的好处。
（未完待续...）
相关链接：
