Confirmative 测试就是对 build 的有效性和关键的功能是否正确进行验证，测试人员依据测试用例和测试脚本的完整测试是工作的重心。原文中的 Confirmative 测试包含了开发人员的单元测试（必不可少的重要开发活动）和被称之为 Agile Acceptance Testing 的测试部分，这段时间的测试任务用来保障迭代的必须输出的质量。基本的功能、非功能的任务，但凡是在迭代开始时制定的计划中承诺的高优先级需求，哪怕是很繁琐的细节工作都要被充分的测试和验证。

        Investigative 测试是对 Confirmative 测试的补充和是更广泛的测试活动，测试团队在完成 Confirmative 测试后的时间用来做这部分测试，它包含功能测试，文档测试和系统测试以及和其他产品、环境之间产生的必然的 Integration 测试，还有个非常有趣的测试活动叫做 Exploratory 测试，笔者认为这部分测试是测试人员创造性的采用多种不同途径去尝试测试产品。就好比“猴子敲键盘”一样，测试员使用各种手段来考验 build 和产品的稳定和正确性等。

自定制的敏捷增量测试模型

        我们在敏捷项目开发的过程中使用了定制的测试流程，我们同样有相同的两部分测试，即 Confirmative 和 Investigative 两部分。不同的是，我们原则的将这两部分测试都放在当前迭代的计划内完成。原因是，敏捷测试团队针对当前迭代的任务计划本应服务于当前的产品，过去的迭代产物，或者因为需求变更不再适用，又或者因为未解决的质量缺陷使得实际测试效果不佳。而同时，因为 Product Owner 和 STAKEHOLDER 的期望是团队能够高效的完成当前迭代的任务，完成更高优先级的工作，每个迭代的考核亦非常清晰。为了完成服从当前的高优先级任务，计划，也为了 STAKEHOLDER 更好的关注和帮助当前问题的及时解决，测试人员对以往 Build 的测试应应合理的计入先前迭代的任务而不是当前迭代计划。倘若真要测试以往的产品而不是最新的，敏捷测试的管理也将变得有些困难，同时测试团队所关注的问题也只能是过时的，只能成为团队的低优先级的问题。这不是与团队整体的目标背离吗？因此，我们建议测试团队使用我们改进后的敏捷增量测试模型，即在当前迭代仅仅完成当前迭代的计划，而所有测试都需要围绕最新的产品 Build 进行。

        在我们新的增量测试模型中 Confirmative 测试包含对需求的静态测试，开发人员做的单元测试，以及 Build 验证测试，功能测试（仅限于对当前迭代功能）和重要的其他类型测试。通过了 Confirmative 测试的产品 Build 就可以作为在迭代结束时发布了。而为了产品拥有更好的质量，也为了完成对那些较低优先级的质量验证的需求得以确保成功的实现，我们需要针对性的做系统测试，压力，并发，安全甚至全球化的测试，这部分我们把它叫做 Investigative 测试。还需要强调的是，为了保障产品的最终稳定，为了产品不会出现在代码重构后的质量回归现象，我们将回归测试（Regression Test）放在这个阶段，用以涵盖对以往关键功能的再度验证。

静态测试

        在笔者的测试模型里，confirmative 测试增加了“静态测试”，本人认为这部分测试是对测试人员最具挑战的部分。一个好的测试人员能够第一时间找到需求分析、设计中的模棱两可，遗漏，错误的地方，能够促进团队前期工作的高效完成，将很大程度降低将来产品的质量缺陷的数量，积极影响了敏捷开发的最终输出。这部分工作是测试团队，开发、设计团队最默契合作的阶段，交流非常频繁，正是通过积极的沟通和及时的修正与团队目标“误差”使得团队更加明确其方向，更有凝聚力和也得以发挥了团队的最佳战斗力。在笔者的项目经历中，往往这个阶段会需要一个迭代周期 1/4 左右的时间。这同时也说明了静态测试在敏捷测试类型中的重要性。

        在敏捷开发过程的静态测试即项目迭代开发前期测试人员的最主要工作。值得再次强调的是，在这段时期测试人员的工作重心是认真了解需求和用例设计，并针对设计的可行性，可用性进行验证，确认设计是对需求的准确实现，最佳实现。