敏捷测试 - 看板

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

• 可测试且大小合适的用户故事能够在指定的时间限制内完成开发和测试。

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

• 看板可以直观地展现工作流程，有助于跟踪测试活动和任何瓶颈。

• 看板团队协作概念允许在发现瓶颈时立即解决，无需等待时间。

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

• 完成定义 (DoD) 被认为是“真正完成”，这意味着只有在测试完成后，故事才算完成。

产品开发中的测试活动

在产品开发中，可以使用功能看板跟踪版本。特定版本的特性分配给功能看板，该看板直观地跟踪特性的开发状态。

版本中的特性被分解成故事，并使用敏捷方法在版本中开发。

以下敏捷测试活动确保每次发布以及所有发布结束时的质量交付：

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

  • 通过用户故事和用户故事中包含的非功能性需求来捕获系统的所有可能行为。

  • 用户故事是可测试的。

  • 用户故事的大小允许在迭代内完成开发和测试（真正完成）。

• 可视化任务看板：

  • 描述任务的状态和进度

  • 立即识别出现的瓶颈

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

• 团队协作有助于：

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

  • 在出现瓶颈时立即解决，节省等待时间

  • 每个专业领域对所有活动的贡献

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

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

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

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

• 在开发过程中进行持续测试，以确保在迭代中修复缺陷：

  • 确保测试覆盖率

  • 保持未解决缺陷数量较低

故事探索

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

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

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

估算

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

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

• 所需测试活动的信息
• 相应的努力估算

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

在看板中，只有当故事被开发和测试并标记为无缺陷完成时，才能实现“真正完成”。

因此，测试估算在故事估算中扮演着重要角色。

故事计划

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

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

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

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

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

故事进展

故事进展揭示了开发人员和测试人员之间持续沟通所导致的额外测试需求。在开发人员需要更多关于实现的清晰度的情况下，测试人员会进行探索性测试。

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

故事验收

当故事达到“真正完成”状态时，故事验收就完成了，即故事已开发和测试并标记为已完成。

当与故事相关的所有测试通过或达到测试自动化级别时，则认为故事测试已完成。