敏捷测试 – 看板

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

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

• WIP（在制品）限制允许一次专注于有限数量的用户故事。

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

• 看板团队协作概念允许在确定瓶颈时解决瓶颈，而无需等待时间。

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

• 完成的定义 (DoD) 被称为 Done-Done，因为故事仅在测试完成后才达到完成状态。

产品开发中的测试活动

在产品开发中，可以使用功能看板来跟踪发布。特定版本的功能被分配到功能看板，用于直观地跟踪功能开发状态。

发布中的功能被分解成故事，并使用敏捷方法在发布中开发。

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

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

  • 系统的所有可能行为都是​​通过用户故事和作为用户故事一部分的非功能需求来捕获的。

  • 用户故事是可测试的。

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

• 视觉任务看板 –

  • 描述任务的状态和进度

  • 瓶颈在发生时立即被识别

  • 便于测量然后可以优化的循环时间

• 团队协作有助于 –

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

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

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

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

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

• 使用早期编写的测试用例进行缺陷预防并指导开发人员了解系统不同行为的预期 –

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

• 随着开发的进行持续测试，以确保迭代中的缺陷修复 –

  • 确保测试覆盖

  • 保持低开放缺陷数

故事探索

故事探索是敏捷团队内部的交流，用于在产品负责人传递故事以供开发接受时探索故事理解。

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

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

估计

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

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

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

在迭代计划中，测试人员有助于决定迭代中可以包含什么故事和多少故事。该决定取决于测试工作量和测试进度估计。故事估计也反映了测试估计。

在看板中，只有当一个故事被开发和测试并标记为完整且没有缺陷时，Done-Done 才会完成。

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

故事策划

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

故事规划包括以下测试任务 –

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

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

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

故事进展

Story Progression 揭示了由于开发人员和测试人员之间的持续沟通而导致的额外测试。在开发人员需要更清楚实现的情况下，测试人员执行探索性测试。

持续测试在故事进展期间执行，包括持续集成测试。整个团队都参与了测试活动。

故事接受

当故事达到 Done-Done 状态时发生故事接受。即，故事被开发和测试并表示为完成。

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