使用看板概念可以有效地管理敏捷测试活动。以下内容确保测试能够在迭代/冲刺中及时完成，从而专注于交付高质量的产品。

• 可测试且有效大小的用户故事可以在指定的时间限制内进行开发和测试。

• WIP(进行中)限制允许一次只关注有限数量的用户故事。

• 可视化代表工作流程的看板板有助于跟踪测试活动和瓶颈(如果有)。

• 看板团队协作概念使瓶颈得以解决，而无需等待时间。

• 预先准备好测试用例，在开发过程中维护测试套件并获得客户反馈，有助于消除迭代/冲刺中的缺陷。

• 完成的定义(DoD)在某种意义上说是“完成”，即故事只有在测试也完成之后才达到完成状态。

产品开发中的测试活动

在产品开发中，可以使用功能看板来跟踪发布。将特定版本的功能分配给Feature Kanban板，以可视方式跟踪功能开发状态。

版本中的功能分为故事，并使用敏捷方法在版本内进行开发。

以下敏捷测试活动可确保每个版本以及所有版本结束时的质量交付-

• 测试人员参与用户故事的创建，从而确保-

  • 系统的所有可能行为都是通过用户故事和属于用户故事的非功能需求捕获的。

  • 用户故事是可测试的。

  • 用户故事的大小允许在迭代中完成开发和测试(DoneDone)。

• 视觉任务看板-

  • 描述任务的状态和进度

  • 瓶颈会在出现时立即识别

  • 便于测量周期时间，然后可以对其进行优化

• 团队合作有助于-

  • 整个优质产品团队的责任

  • 解决瓶颈的发生时间，节省等待时间

  • 每项专业知识在所有活动中的贡献

• 专注于持续集成测试的持续集成

• 自动测试以节省测试工作量和时间

• 通过较早编写给开发人员的测试用例预防缺陷，并指导开发人员系统的不同行为所预期的结果-

  • WIP限制，一次仅关注有限数量的用户故事

• 随着开发的进行不断进行测试，以确保迭代中的缺陷修复-

  • 确保测试范围

  • 保持开放缺陷计数低

故事探索

故事探索是敏捷团队内部的交流，目的是在产品所有者将故事传递给开发接受时探索故事的理解。

产品负责人根据系统预期的功能提出故事。在将每个故事标记为可以接受之前，开发人员会对其进行更多的探索。测试人员还从测试角度参与通信，以使其尽可能可测试。

故事的定稿基于产品负责人，开发人员和测试人员之间不断的沟通。

估算值

估计发生在发布计划和每个迭代计划中。

在发布计划中，测试人员提供-

• 有关需要进行哪些测试活动的信息
• 相同的工作量估算

在迭代计划中，测试人员有助于确定迭代中可以包含哪些故事以及可以包含多少个故事。该决定取决于测试工作量和测试时间表估计。故事评估也反映了测试评估。

在看板中，只有开发并测试了故事并将其标记为没有缺陷的完整内容，才可以完成“完成”。

因此，测试估计在故事估计中起主要作用。

故事策划

故事计划在估计故事并将其分配给当前迭代之后开始。

故事计划包括以下测试任务-

• 准备测试数据
• 扩展验收测试
• 执行手动测试
• 进行探索性测试会议
• 自动进行持续集成测试

除了这些测试任务，还可能需要其他任务，例如-

• 性能测试
• 回归测试
• 相关持续集成测试的更新

故事进展

Story Progression揭示了开发人员和测试人员之间不断沟通所导致的其他测试。在开发人员需要更清晰地实现的情况下，测试人员将进行探索性测试。

连续测试在Story Progress中进行，包括持续集成测试。整个团队都参与测试活动。

故事接受

当故事达到“完成”状态时，发生故事接受。即，故事已开发，测试并发出完整的信号。

当满足与故事通过或测试自动化水平相关的所有测试时，故事测试即告完成。