敏捷测试 - Scrum

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

整个团队共同制定测试策略、测试规划、测试规范、测试执行、测试评估和测试结果报告。

协作用户故事创建

测试人员参与用户故事创建。测试人员就系统的可能行为贡献他们的想法。这有助于客户和/或最终用户在真实环境中理解系统，从而明确他们真正想要的结果。这样可以更快地冻结需求，并降低以后需求发生变化的可能性。

测试人员还会针对客户同意的每种场景提出验收标准。

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

发布规划

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

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

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

冲刺规划

冲刺规划在每个冲刺开始时完成。冲刺待办事项列表是使用从产品待办事项列表中挑选出的用户故事创建的，用于在该特定冲刺中实施。

测试人员应该 −

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

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

测试分析

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

测试

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

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

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

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

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

• 收集和维护测试结果。

自动化测试

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

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

测试活动自动化

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

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

回归测试

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

配置管理

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

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

敏捷测试实践

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

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

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

敏捷指标

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

建议使用几种指标进行 Scrum 开发。重要的指标是 −

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

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

• 焦点因子 − (速度/团队的工作能力) / 100。焦点因子是团队努力的结果中完成故事的百分比。

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

• Sprint Burndown − 剩余工作量（以故事点或小时为单位）与理想情况下需要剩余的工作量（根据估计）之比。

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

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

• 缺陷计数 − Sprint 中的缺陷数量。缺陷数量是软件中缺陷的数量与积压数量之比。

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

Sprint 回顾

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

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