敏捷测试 - 看板


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

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

  • WIP(工作中)限制允许一次专注于有限数量的用户故事。

  • 看板以直观方式表示工作流程,有助于跟踪测试活动和瓶颈(如果有)。

  • 看板团队协作概念可以在识别瓶颈时解决它们,而无需等待时间。

  • 预先准备测试用例,随着开发的进展维护测试套件并获取客户反馈有助于消除迭代/冲刺中的缺陷。

  • 完成的定义 (DoD) 被称为“完成-完成”,因为故事只有在测试也完成后才达到完成状态。

产品开发中的测试活动

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

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

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

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

    • 系统所有可能的Behave都通过用户故事和属于用户故事一部分的非功能性需求来捕获。

    • 用户故事是可测试的。

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

  • 视觉任务看板 -

    • 描述任务的状态和进度

    • 瓶颈出现时立即被识别

    • 有助于测量循环时间,然后进行优化

  • 团队协作有助于 -

    • 整个团队对产品质量负责

    • 当瓶颈发生时予以解决,节省等待时间

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

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

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

  • 通过之前编写的测试用例来预防缺陷,并指导开发人员了解系统不同Behave的预期 -

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

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

    • 确保测试覆盖率

    • 保持较低的开放缺陷数量

故事探索

故事探索是敏捷团队内部的沟通,当产品负责人传递故事以供开发接受时,探索故事理解。

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

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

预估

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

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

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

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

在看板中,只有当故事被开发、测试并标记为完整且无缺陷时,“完成”才算完成。

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

故事策划

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

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

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

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

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

故事进展

故事进展揭示了开发人员和测试人员之间持续沟通所需要的额外测试。在开发人员需要更清晰地实施的情况下,测试人员会执行探索性测试。

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

故事接受

当故事达到“完成”状态时,就会发生故事接受。即,故事已经开发、测试并表明已完成。

当与故事相关的所有测试通过或测试自动化级别都得到满足时,故事测试就完成了。