Review自上次测试周期后集成到构建中的工作项。重点识别那些先前未实现或失败的，但现在预期符合了满足条件的需求。

选择构建所完成的工作项相关的测试脚本。

理想情况下，每个测试周期应该执行所有的测试脚本，但是某些类型的测试包含在每个测试周期中的话过于耗时。对于手工或耗时的测试，包括测试脚本，将基于迭代目标提供对解决方案成熟度最有用的反馈。

策划测试套件来简化每次构建选择测试的过程（参见指南：Test Suite）。

根据测试脚本一步步执行其中步骤。

对于自动化测试脚本，开始执行测试。自动化测试脚本应该在测试套件中按正确的序列运行，并在测试日志中收集结果。

对于手工执行的测试脚本，建立其预置条件，按步骤执行，并在测试日志中记录结果，然后执行清除步骤。

在显眼的地点公布测试结果，使其能够被整个团队所访问，例如白板或Wiki。

为每个失败的测试脚本，分析测试日志识别测试失败的原因。首先，在构建中预期通过的测试却失败了，这可能意味着新交付的工作项未能符合满足的条件。然后，以前通过的测试脚本现在却失败了，可能意味着构建存在回归问题。

• 如果测试失败是因为解决方案没有满足测试用例的符合条件，那么在工作项列表中记录问题。在工作项中，清晰的描述观察到的行为、预期的行为以及重现问题的步骤。注意最初发现此问题的测试。
• 如果测试失败是因为系统的某个变更（例如接口变化），但其实现仍旧是满足测试用例中的符合条件，那么更新测试脚本使其通过新的实现。
• 如果测试失败是因为测试脚本不正确或预期失败却通过，那么更新测试脚本使其正确的实现测试用例的符合条件。如果测试用例或需求无效，创建变更申请修改此需求的满足条件。

最好是尽快且持续的更新测试脚本。如果是琐碎微小的测试脚本变更，在分析测试结果的同时更新测试。如果变更不是一个琐碎微小的任务，那么将其提交到工作项列表中，使其和其它任务一起进行优先级排序。

总结并向团队提供反馈，该构建是否良好的满足了迭代中计划的需求。主要从通过的测试的方面来衡量进展。

在整体趋势的上下文环境中解释此测试周期的结果：

• 该构建选择了多少测试，以及它们的状态（通过、失败、阻塞、未运行，等等）？
• 有多少问题被增加到工作项列表中，以及它们的状态和严重级别？
• 哪些测试脚本被阻塞或跳过，其主要原因是什么（如已知的问题）？