1.8　引入工程冲刺

　　因为我们已经花时间向业务经理解释了测试的整个过程和实践，所以他们了解了技术债务的观念。每当我们为了顾及截止日期而走捷径的时候，代码就变得很难处理。如果我们没有时间将工具升级到最新版本，或者没有时间尝试能让我们更高效地工作的最新软件，我们的速度就会下降。这就好比如果我们拖欠信用卡债务，利率就会上升，我们所欠的债务就越来越多。如果我们被技术债务缠身，就无法以客户期待的速率来发布大量的软件。

　　所以，我们每6个月会进行一次特别的迭代，称为“工程冲刺”在这次迭代中不需要发布任何新的功能点（engineering sprint）。我们可以利用这段时间完成以下工作：升级到最新的Java版本、进行大型重构、尝试新的测试工具、重构FitNesse测试来消除冗余。在一次工程冲刺中，我们将源代码版本控制系统从CVS转变为SVN（Subversion）。在另外一次工程冲刺中，我们将构建过程从CruiseControl转变为Hudson，从而为缩短反馈周期提供了更多的选择。每当在更短的时间内发布了更多更好的功能点时，业务人员就可以看到这些投资的回报。

　　1.9　团队成功

　　我们的团队在一年的时间内，从没有自动化测试发展到将所有的回归测试进行自动化。我们的自动化金字塔还不完全是理想的形状，但是我们有了好的测试框架和在每个级别（见图1-2）实现测试的驱动程序。尽管这样，我们却没有满足现状，而是继续寻找在各个级别有效地进行自动化回归测试的方法。当我们可以控制功能测试的自动化之后，我们将着手性能测试的自动化。我们有处理不完的挑战！

　　最好的是，我们有时间对每个用户故事或功能集合进行充分的探索性测试，这样的话，在产品中就很少会有问题浮出水面。同时自动化测试也可以帮助我们进行探索性测试。我们希望创建：使用Ruby的具有高灵活性的脚本，Watir（Ruby中的Web应用测试）测试驱动，以及测试/单元框架。它们接收运行参数，允许我们在几秒或者几分钟内建立复杂的测试数据和情景，而不再需要花费时间搭建繁琐的手动测试平台。通过脚本可以直接对需要进行测试的部分进行测试，这样我们就可以拥有更多的时间来深入探索软件。

　　【真知灼见】

　　使用自动化测试来支持创新型手动测试。

　　我们的目标是使所有回归测试实现自动化，但是这一目标有几点需要说明。要达到一个合理的ROI，自动化测试在设计时必须要考虑到长期可维护性。因此要求程序员拥有好的设计技巧，可以帮助设计各个级别的自动化测试。我们不断对测试进行重构以使维护费用较低。同时，在选择将哪些测试保留在自动化回归测试套件中时，团队要有准确的判断力，需要“正好”（good enough）覆盖。测试太多意味着反馈周期太长和维护费用过高。同时，我们还有少量的遗留代码没有被自动化测试覆盖，当我们进行可能对遗留代码造成影响的大范围的代码重构时，我们要留一些时间进行手动回归测试。

图1-2　自动测试金字塔使用的工具