敏捷测试-Scrum

Scrum 提倡整体团队方法，即每个团队成员都必须参与每个项目活动。Scrum 团队是自组织的，对项目可交付成果负责。决策权留给团队，以便在正确的时间采取适当的行动，而不会造成任何时间延误。这种方法还鼓励正确利用团队才能，而不是仅限于一项活动。测试人员还参与所有项目和开发活动，贡献他们的测试专业知识。

整个团队在测试策略、测试计划、测试规范、测试执行、测试评估和测试结果报告方面共同努力。

协作用户故事创建

测试人员参与用户故事创建。测试人员就系统可能的Behave提出他们的想法。这有助于客户和/或最终用户了解真实环境中的系统，从而清楚地了解他们真正想要的结果。这会导致需求更快地冻结，并减少以后需求发生变化的可能性。

测试人员还为客户同意的每个场景制定验收标准。

测试人员有助于创建可测试的用户故事。

发布计划

发布计划是针对整个项目完成的。然而，Scrum 框架涉及迭代决策，因为在执行冲刺的适当过程中会获得更多信息。因此，项目开始时的发布计划会议不需要为整个项目制定详细的发布计划。当相关信息可用时，它可以不断更新。

每个冲刺结束都不需要发布。发布可以在一组冲刺之后进行。发布的主要标准是为客户提供业务价值。团队以发布计划作为输入来决定冲刺长度。

发布计划是发布测试方法和测试计划的基础。测试人员估计测试工作量并计划发布测试。当发布计划发生变化时，测试人员必须处理变化，考虑到更大的发布环境，获得足够的测试基础。测试人员还提供所有冲刺结束时所需的测试工作。

冲刺计划

冲刺计划是在每个冲刺开始时完成的。冲刺待办事项是使用从产品待办事项中选取的用户故事创建的，以便在特定冲刺中实施。

测试人员应该 -

  • 确定为冲刺选择的用户故事的可测试性
  • 创建验收测试
  • 定义测试级别
  • 识别测试自动化

测试人员使用冲刺中测试工作量和持续时间的估计来更新测试计划。这确保了在限时冲刺期间为所需测试提供时间，并确保测试工作的责任。

测试分析

当冲刺开始时，开发人员对设计和实现进行故事分析，测试人员对冲刺待办事项中的故事进行测试分析。测试人员创建所需的测试用例 - 手动测试和自动测试。

测试

Scrum 团队的所有成员都应该参与测试。

  • 开发人员在为用户故事开发代码时执行单元测试。在编写代码之前，在每个冲刺中创建单元测试。单元测试用例源自低级设计规范。

  • 测试人员执行用户故事的功能性和非功能性特征。

  • 测试人员用他们的测试专业知识指导 Scrum 团队中的其他成员，以便整个团队对产品质量承担集体责任。

  • 在冲刺结束时，客户和/或最终用户执行用户验收测试并向 Scrum 团队提供反馈。这将作为下一个冲刺的输入。

  • 收集并维护测试结果。

自动化测试

自动化测试在 Scrum 团队中非常重要。测试人员投入时间创建、执行、监控和维护自动化测试和结果。由于 Scrum 项目中随时可能发生更改，因此测试人员需要适应更改功能的测试以及所涉及的回归测试。自动化测试有助于管理与变更相关的测试工作。各级自动化测试有助于实现持续集成。自动化测试的运行速度比手动测试快得多，而且无需额外工作。

手动测试更侧重于探索性测试、产品漏洞、缺陷预测。

测试活动自动化

测试活动的自动化减少了重复工作的负担，从而节省了成本。自动化

  • 测试数据生成
  • 测试数据加载
  • 将部署构建到测试环境中
  • 测试环境管理
  • 数据输出比较

回归测试

在冲刺中，测试人员测试该冲刺中新增/修改的代码。然而，测试人员还需要确保在早期冲刺中开发和测试的代码也可以与新代码一起工作。因此，回归测试在 Scrum 中非常重要。自动回归测试在持续集成中运行。

配置管理

Scrum 项目中使用了使用自动化构建和测试框架的配置管理系统。这允许在新代码签入配置管理系统时重复运行静态分析和单元测试。它还管理新代码与系统的持续集成。自动回归测试在持续集成期间运行。

手动测试用例、自动化测试、测试数据、测试计划、测试策略和其他测试工件需要进行版本控制，并需要确保相关的访问权限。这可以通过在配置管理系统中维护测试工件来完成。

敏捷测试实践

Scrum 团队中的测试人员可以遵循以下敏捷实践 -

  • 配对- 两个团队成员坐在一起协作工作。这两个人可以是两名测试人员，也可以是一名测试人员和一名开发人员。

  • 增量测试设计- 随着冲刺的逐步进展和用户故事的增加，测试用例被开发。

敏捷指标

在软件开发过程中，指标的收集和分析有助于改进流程，从而实现更好的生产力、交付质量和客户满意度。在基于 Scrum 的开发中，这是可能的，并且测试人员必须关注他们需要的指标。

针对 Scrum 开发提出了几个指标。重要的指标是 -

  • 成功 Sprint 的比率- (成功 Sprint 的数量 / Sprint 的总数) * 100。成功的冲刺是团队能够履行其承诺的冲刺。

  • 速度- 团队的速度基于团队在冲刺期间获得的故事点数量。故事点是评估过程中计算的用户故事的衡量标准。

  • 焦点因素- （速度/团队的工作能力）/100。焦点因素是团队努力完成故事的百分比。

  • 估计准确度- （估计工作量/实际工作量）/100。估计准确性是团队准确估计工作量的能力。

  • Sprint Burndown - 剩余工作与剩余工作（以故事点或小时为单位）需要保持理想状态的工作（根据估计）。

    • 如果更多，则意味着团队承担的工作超出了他们的能力。

    • 如果较少，则意味着团队没有准确估计。

  • 缺陷计数- Sprint 中的缺陷数量。缺陷计数是软件中相对于积压的缺陷数量。

  • 缺陷的严重性- 缺陷可以根据其严重程度分为轻微、主要和严重。测试人员可以定义分类。

冲刺回顾

在 Sprint 回顾中，所有团队成员都将参与。他们分享 -

  • 那些进展顺利的事情
  • 指标
  • 改进范围
  • 要应用的行动项目