TDD可能是在对缺陷进行编码前，就将其从产品中剔除的最好机会。作为一项有力的敏捷技术，TDD多用于极限编程项目。它与CMMI模型中的确认、验证以及需求开发过程域都有密切的关联。

运用早期确认与验证技术，开发者一个人便可写出基本的测试用例，用以验证所需的功能。如果无法通过测试用例，开发者便可以尽可能少的代码通过测试。开发者会清理代码，使之达到可接受的性能以及代码标准与原则。这个过程也可视之为代码重构。当TDD与敏捷项目中常见的，以短期sprint或迭代形式呈现的迭代与增量型的生命周期方式相结合，便可实现其价值的最大化。

需求开发

TDD允许开发者增量地创建测试用例，以及满足测试用例的软件。自动化测试的框架通常被用来确保TDD的实践是简单而高效的。在后续的开发中，当软件受到变更的影响，被证实的测试用例可用于确保变更不会带来意想不到的后果。结合CMMI需求开发过程域，随着时间的推移，应用TDD实践将帮助团队发现并清晰化需求。

·  确保在考虑TDD时，软件操作概念与场景，与产品的实际使用环境相吻合。很多情况下，需求存在于用户交互、运行环境、维护与产品退役之中。操作概念与场景的开发是一个迭代过程，在这一过程中TDD是个好方法。

·  尽可能早地，将引发更广泛层面的问题或风险的需求识别出来。时间限制、系统属性、质量属性很可能是导致需求冲突、风险叠加或成本上升的原因。在TDD时考虑这些方面，有助于达成最佳的平衡。

·  确保在运用TDD实践清晰化需求时，考虑到了预期的环境。在开发的早期阶段，模拟出环境是对的；但是编写的测试用例应转化为对最终产品需求的确认。

确认

随着测试用例与软件的编写，需求在有效的闭合循环过程中，被创建、更新、修正与稳定。立即学习与成本控制将自然地发生，因为需求缺陷在开发的同时就会被发现，且不会遗落到后期开发的生命周期中。CMMI确认过程域何以增强TDD呢？正如前面系列文章中的阐述，CMMI涵盖了有用的实践与信息，以完善敏捷框架中被遗漏的细节：

·  当开发团队使用TDD实践创建与细化满足确认需求的测试用例时，要确保测试考虑到了产品的实际应用环境。

·  确认的结果要反馈给开发团队，这样他们可以学习并改善需求以及用以确认需求的用例。这一点，在很多项目中都极易被忽视。

将确认的思维应用于开发工作的早期，使用TDD支撑验证，已被证实可以避免昂贵的需求缺陷。

验证

执行TDD的实践，有助于团队随着时间推移开发与清晰化需求，并可对需求进行及时的验证。一旦建立起测试用例库，需求变更便可通过回归测试，被较容易地评价与验证。使用测试用例库进行验证时，还可能发现意外的结果，在介绍测试用例时便可将其修正。在引入和交付变更时，产品在第一时间便能正常运作，这是与高层管理层与外部客户建立信任的极好方式。

·  在开发产品的过程中，验证要趁早，并且还需具有一定的频次。验证的结果，可以节约了与重大问题相关的缺陷隔离与返工的高昂成本。

·  开发团队要使用验证的结果，学习与改进需求以及用以验证需求的测试用例。这一原则无论在敏捷还是CMMI中，都是核心的原则，但却被很多项目组忽视。

在引入时就消灭缺陷，是经过证实可以成功交付项目的办法。