敏捷测试 - 看板
可以使用看板概念有效地管理敏捷测试活动。以下内容确保测试在迭代/冲刺内及时完成，从而专注于交付优质产品。
可测试且有效调整大小的用户故事可在指定的时间限制内完成开发和测试。
WIP（在制品）限制允许一次专注于有限数量的用户故事。
看板以可视化方式表示工作流程，有助于跟踪测试活动和瓶颈（如果有）。
看板团队协作概念允许在发现瓶颈时立即解决，而无需等待时间。
提前准备测试用例、在开发过程中维护测试套件并获得客户反馈有助于消除迭代/冲刺中的缺陷。
完成（DoD）的定义被称为完成完成，意思是只有在测试完成后，故事才会达到完成状态。
产品开发中的测试活动
在产品开发中，可以使用功能看板来跟踪发布。特定版本的功能被分配给功能看板，该看板以可视化方式跟踪功能开发状态。
版本中的功能被分解为故事，并使用敏捷方法在版本内开发。
以下敏捷测试活动可确保每个版本以及所有版本结束时的高质量交付 −
测试人员参与用户故事创建，从而确保 −
通过用户故事和作为用户故事一部分的非功能性需求捕获系统的所有可能行为。
用户故事是可测试的。
用户故事的大小允许在迭代内完成开发和测试（DoneDone）。
可视化任务看板 −
描述任务的状态和进度
瓶颈一出现就立即识别
有助于测量周期时间，然后进行优化
团队协作有助于−
整个团队对优质产品的责任
在瓶颈出现时立即解决，节省等待时间
在所有活动中贡献每一项专业知识
专注于持续集成测试的持续集成
测试自动化，节省测试工作量和时间
使用之前编写的测试用例进行缺陷预防，以供开发和指导开发人员了解系统不同行为的预期 −
WIP 限制一次关注有限数量的用户故事
随着开发的进展进行持续测试，以确保在迭代中修复缺陷 −
确保测试覆盖率
保持低未解决缺陷数
故事探索
故事探索是敏捷团队内部的沟通，当产品所有者将故事提交给开发部门进行验收时，探索对故事的理解。
产品所有者根据系统预期的功能提出故事。开发人员在将每个故事标记为已准备好验收之前，会对每个故事进行更多探索。测试人员还从测试的角度参与沟通，以使其尽可能可测试。
故事的最终确定基于产品负责人、开发人员和测试人员之间的持续沟通。
估计
估计发生在发布计划和每个迭代计划中。
在发布计划中，测试人员提供 −
- 有关需要哪些测试活动的信息
- 相同的工作量估计
在迭代计划中，测试人员参与决定迭代中可以包含哪些故事以及故事数量。该决定取决于测试工作量和测试进度估计。故事评估也反映了测试评估。
在看板中，只有当故事开发、测试并标记为完整且无缺陷时，完成才算完成。
因此，测试评估在故事评估中起着重要作用。
故事规划
故事规划在故事评估并分配给当前迭代后开始。
故事规划包括以下测试任务 −
- 准备测试数据
- 扩展验收测试
- 执行手动测试
- 进行探索性测试会话
- 自动化持续集成测试
除了这些测试任务之外，可能还需要其他任务，例如 −
- 性能测试
- 回归测试
- 相关持续集成测试的更新
故事进展
故事进展揭示了开发人员和测试人员之间持续沟通所需的额外测试。在开发人员需要更清晰地了解实施情况的情况下，测试人员会执行探索性测试。
持续测试在故事进展期间执行，包括持续集成测试。整个团队都参与测试活动。
故事验收
故事验收发生在故事达到完成状态时。即故事开发和测试并表示完成。
当与故事通过或测试自动化级别相关的所有测试都得到满足时，故事测试就完成了。
