敏捷测试 - Scrum

Scrum 环境中的敏捷测试

Scrum 提倡“全团队方法”，这意味着开发团队 (Development Team)（包括测试人员）的每个成员都对项目的可交付成果负责。Scrum 团队是自组织的 (self-organizing)，赋予他们快速做出决策并采取适当行动的能力。这种协作环境鼓励利用各种才能，测试人员不仅贡献其测试任务方面的专业知识，还参与各种开发和规划活动。

整个 Scrum 团队协作定义测试策略、规划测试活动、设计测试规范、执行测试、评估结果并报告质量情况。

用户故事创建与完善的协作

测试人员是用户故事 (User Story) 创建和 Backlog 完善 (Backlog Refinement) 的重要参与者。他们带来了测试视角，帮助识别潜在的歧义、边缘情况 (edge cases) 和不同的系统行为。这种协作确保用户故事被充分理解、可测试（例如，满足 INVEST 标准），并且具有清晰、明确的验收标准 (Acceptance Criteria)，通常是在“三友” (Three Amigos)（产品负责人 PO/业务分析师 BA、开发人员 Dev、测试人员 Tester）会议期间共同创建。这降低了后期需求变更的可能性。

Scrum 中的发布规划

虽然 Scrum 侧重于冲刺 (Sprint)，但发布规划 (Release Planning) 提供了更长远的视角。测试人员通过提供关于整体测试方法、估计未来功能的高级测试工作量、识别潜在风险以及规划更大范围的集成测试或非功能测试 (Non-functional Testing) 来做出贡献。发布计划是迭代的，并随着冲刺执行和反馈获得更多信息而进行调整。一个发布可能跨越多个冲刺，交付大量的业务价值。

冲刺规划

在每个冲刺开始时，Scrum 团队会进行冲刺规划 (Sprint Planning)。测试人员通过以下方式发挥关键作用：

帮助从产品待办事项列表 (Product Backlog) 中为冲刺待办事项列表 (Sprint Backlog) 选择用户故事，考虑其可测试性和任何测试依赖项。
协作定义冲刺目标 (Sprint Goal)。
将用户故事分解为任务，包括具体的测试任务（例如，“为 X 编写自动化的 API 测试”、“对 Y 功能执行探索性测试”）。
估算冲刺中测试任务所需的工作量。
确保所选故事的验收标准清晰且可测试。
识别冲刺所需的测试数据和环境设置需求。

这确保了测试活动从一开始就被集成到冲刺计划中。

冲刺期间的测试分析与设计

当开发人员开始实现用户故事时，测试人员同时进行测试分析和设计。这包括创建详细的测试用例（包括手动和自动化脚本）、准备测试数据以及设置或验证测试环境。这种并行活动确保了代码可用时测试就已准备就绪。

冲刺中的测试活动

Scrum 团队的所有成员都为质量做出贡献：

开发人员在编写代码时会编写单元测试 (Unit Tests)（通常使用 TDD）和组件测试。他们也可能贡献其他层级的自动化测试。
测试人员专注于设计和执行各种类型的测试，包括集成测试 (Integration Tests)、系统测试 (System Tests)（基于用户故事的功能性和非功能性测试）、API 测试和验收测试 (Acceptance Tests)。他们还会执行关键的探索性测试。
测试人员指导和支持其他团队成员进行测试实践和自动化，培养对质量的集体所有权。
在冲刺评审 (Sprint Review) 中，团队演示已“完成”的增量 (Increment)，并收集反馈（如适用，包括来自用户验收测试 UAT 的反馈），这些反馈可以为后续冲刺提供信息。
持续监控测试结果，并对缺陷进行管理和优先级排序以便修复，最好在同一冲刺内完成。

Scrum 中的测试自动化

测试自动化在 Scrum 中至关重要，以应对短迭代周期和频繁回归测试的需求。测试人员投入大量精力创建、执行、监控和维护自动化测试。这些测试集成到 CI/CD 管道中以提供快速反馈。自动化涵盖各种级别，包括单元测试、API/服务测试和 UI 测试，遵循测试自动化金字塔 (Test Automation Pyramid) 原则。然后将手动测试工作集中在人工智慧和探索能带来最大价值的领域，例如可用性、复杂场景和探索性测试。

测试支持活动的自动化

除了测试执行之外，自动化其他与测试相关的活动可以节省时间并减少手动工作。这包括：

测试数据生成和填充 (Seeding)。
测试环境供给和配置（基础设施即代码 Infrastructure as Code, IaC）。
自动化构建部署到测试环境。
结果报告和仪表盘生成。

回归测试

随着每个冲刺增加新功能或修改现有代码，强大的回归测试 (Regression Testing) 对于确保现有功能继续按预期工作至关重要。在 Scrum 中，回归测试高度自动化并频繁运行，通常作为每个 CI 构建的一部分，以便尽早发现回归问题。

配置与测试资产管理

Scrum 项目利用现代配置管理系统，主要是 Git，以及自动化构建和测试框架。所有测试资产——手动测试用例、自动化测试脚本、测试数据、测试计划、测试策略文档以及环境配置（例如 Dockerfiles、IaC 脚本）——都应与应用程序代码一起进行版本控制。这确保了可追溯性、协作和一致性。

Scrum 中的敏捷测试实践

Scrum 团队中的测试人员通常采用以下实践：

结对 (Pairing)：两名团队成员（例如，测试人员-开发人员、测试人员-测试人员、测试人员-产品负责人 PO）共同完成一项任务，例如编写自动化脚本、完善验收标准或执行探索性测试。
增量测试设计 (Incremental Test Design)：随着用户故事的演进并在冲刺中实现，测试用例和场景也随之增量开发。
探索性测试会话 (Exploratory Testing Sessions)：基于章程 (Charter) 的限时探索性测试，用于发现脚本化测试可能遗漏的缺陷和可用性问题。
基于风险的测试 (Risk-Based Testing)：根据不同功能相关的技术和业务风险来优先安排测试工作。

用于质量和流程改进的敏捷指标

收集和分析指标有助于 Scrum 团队改进流程和可交付成果。测试人员在跟踪和解释与质量相关的指标方面做出了重要贡献：

冲刺燃尽/燃起图 (Sprint Burndown/Burnup Charts)：可视化冲刺目标的进展。
团队速度 (Team Velocity)：（谨慎使用）衡量在冲刺期间从产品待办事项列表转化为增量的量。主要用于团队内部规划。
代码覆盖率 (Code Coverage)：自动化单元/集成测试覆盖的代码百分比。
测试自动化覆盖率：自动化测试场景占整体测试场景的百分比。
缺陷密度 (Defect Density)：每故事点 (Story Point) 或每个功能发现的缺陷数量。
缺陷逃逸率 (Defect Escape Rate)：发布后在生产环境中发现的缺陷数量。
缺陷的平均检测时间 (MTTD) / 平均解决时间 (MTTR)。
构建稳定性 / CI 构建成功率：表明开发管道 (Pipeline) 的健康状况。

应使用指标来推动改进，而不是用于个人绩效评估或团队比较。

冲刺回顾会议

在冲刺回顾会议 (Sprint Retrospectives) 中，测试人员就以下方面提供关键输入：

冲刺期间测试流程和活动的有效性。
已交付增量的质量以及任何逃逸的缺陷。
遇到的挑战（例如，测试环境稳定性、需求不明确、自动化不稳定等）。
哪些方面进展顺利并应继续保持。
与质量保证 (Quality Assurance QA) 和下个冲刺的测试相关的可操作改进项。