敏捷测试 – Scrum

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

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

协作用户故事创建

测试人员参与用户故事创建。测试人员对系统可能的行为提出他们的想法。这有助于客户和/或最终用户了解真实环境中的系统，从而明确他们实际想要的结果。这会导致更快地冻结需求，并且还降低了以后需求发生变化的可能性。

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

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

发布计划

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

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

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

冲刺计划

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

测试人员应该 –

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

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

测试分析

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

测试

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

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

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

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

• 在冲刺结束时，客户和/或最终用户进行用户验收测试并向 scrum 团队提供反馈。这形成了下一个冲刺的输入。

• 收集和维护测试结果。

自动化测试

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

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

测试活动自动化

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

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

回归测试

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

配置管理

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

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

敏捷测试实践

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

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

• 增量测试设计– 随着 Sprint 的进展和用户故事的增加，开发测试用例。

敏捷指标

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

为 Scrum 开发建议了几个指标。重要的指标是 –

• 成功 Sprint 的比率– （成功 Sprint 的数量 / Sprint 的总数）* 100。一个成功的 Sprint 是一个团队能够兑现其承诺的 Sprint。

• 速度– 团队的速度基于团队在冲刺期间获得的故事点数。故事点数是在估算期间计算的用户故事的度量。

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

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

• Sprint Burndown – 剩余 Vs 的工作（以故事点数或以小时为单位）。理想情况下需要保留的工作（根据估计）。

  • 如果它更多，那么这意味着团队承担了比他们能做的更多的工作。

  • 如果小于，则表示团队没有准确估算。

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

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

冲刺回顾

在 Sprint Retrospectives 中，所有团队成员都将参加。他们分享 –

• 顺利的事情
• 指标
• 改进的余地
• 申请的行动项目