测试驱动开发的原则应该运用于每一迭代周期的开发中。但是，测试驱动开发的单元测试仍然是以开发为目的的活动，虽然自动化测试，回归测试和用户的接收测试（User Acceptance Test）可以通过复用单元测试脚本提高以后的测试工作的效率，但单元测试不是我们敏捷测试讨论的重点。
敏捷测试活动的主要承载者还是敏捷测试人员。测试人员如何运用敏捷原则指导测试活动还是笔者在敏捷测试实践一文中要讲述的重点。以下，笔者将通过两个迭代测试模型来帮助了解测试人员如何结合敏捷原则实践敏捷的测试活动。
测试是敏捷开发过程重要的环节，自始自终测试贯穿于每个迭代。Scott W. Ambler 认为就整个产品的敏捷开发生命周期可以分为 4 个阶段，即初始阶段，项目的建设阶段，产品发布阶段和产品的维护阶段，在关键的项目建设阶段中，测试被分成两个部分，Confirmatory 测试和 Investigative 测试。 1 下面，我们来讲讲迭代的测试的这两个方面。
图 3. 敏捷测试生命周期
Confirmative 测试就是对 build 的有效性和关键的功能是否正确进行验证，测试人员依据测试用例和测试脚本的完整测试是工作的重心。原文中的 Confirmative 测试包含了开发人员的单元测试（必不可少的重要开发活动）和被称之为 Agile Acceptance Testing 的测试部分，这段时间的测试任务用来保障迭代的必须输出的质量。基本的功能、非功能的任务，但凡是在迭代开始时制定的计划中承诺的高优先级需求，哪怕是很繁琐的细节工作都要被充分的测试和验证。
Investigative 测试是对 Confirmative 测试的补充和是更广泛的测试活动，测试团队在完成 Confirmative 测试后的时间用来做这部分测试，它包含功能测试，文档测试和系统测试以及和其他产品、环境之间产生的必然的 Integration 测试，还有个非常有趣的测试活动叫做 Exploratory 测试，笔者认为这部分测试是测试人员创造性的采用多种不同途径去尝试测试产品。就好比“猴子敲键盘”一样，测试员使用各种手段来考验 build 和产品的稳定和正确性等。
图 4. 敏捷测试的 Incremental Testing
我们在敏捷项目开发的过程中使用了定制的测试流程，我们同样有相同的两部分测试，即 Confirmative 和 Investigative 两部分。不同的是，我们原则的将这两部分测试都放在当前迭代的计划内完成。原因是，敏捷测试团队针对当前迭代的任务计划本应服务于当前的产品，过去的迭代产物，或者因为需求变更不再适用，又或者因为未解决的质量缺陷使得实际测试效果不佳。而同时，因为 Product Owner 和 STAKEHOLDER 的期望是团队能够高效的完成当前迭代的任务，完成更高优先级的工作，每个迭代的考核亦非常清晰。为了完成服从当前的高优先级任务，计划，也为了 STAKEHOLDER 更好的关注和帮助当前问题的及时解决，测试人员对以往 Build 的测试应应合理的计入先前迭代的任务而不是当前迭代计划。倘若真要测试以往的产品而不是最新的，敏捷测试的管理也将变得有些困难，同时测试团队所关注的问题也只能是过时的，只能成为团队的低优先级的问题。这不是与团队整体的目标背离吗？因此，我们建议测试团队使用我们改进后的敏捷增量测试模型，即在当前迭代仅仅完成当前迭代的计划，而所有测试都需要围绕最新的产品 Build 进行。
