敏捷测试 - 跟踪活动
测试状态可以通过 − 进行传达
- 在每日站立会议期间
- 使用标准测试管理工具
- 通过信使
由测试通过状态确定的测试状态对于决定任务是否"完成"至关重要。完成意味着任务的所有测试都通过了。
测试进度
可以使用 − 跟踪测试进度
- Scrum 板（敏捷任务板）
- 燃尽图
- 自动化测试结果
测试进度也会直接影响开发进度。这是因为只有在达到验收标准后，用户故事才能移至完成状态。反过来，这又由测试状态决定，因为验收标准是由测试状态来判断的。
如果测试进度有任何延迟或阻碍，整个团队都会讨论并合作解决。
在敏捷项目中，变化经常发生。当发生许多变化时，我们可以预期测试状态、测试进度和产品质量会不断发展。敏捷测试人员需要将这些信息传达给团队，以便在正确的时间做出适当的决策，确保每次迭代都能成功完成。
当发生变化时，它们可能会影响以前迭代中现有的功能。在这种情况下，必须更新手动和自动测试，以有效处理回归风险。回归测试也是必要的。
产品质量
产品质量指标包括 −
- 测试通过/失败
- 发现/修复的缺陷
- 测试覆盖率
- 测试通过/失败率
- 缺陷发现率
- 缺陷密度
自动收集和报告产品质量指标有助于 −
- 保持透明度。
- 在正确的时间收集所有相关和必需的指标。
- 立即报告，无通信延迟。
- 允许测试人员专注于测试。
- 过滤指标的滥用。
确保整体产品质量，敏捷团队需要获得客户反馈，了解产品是否符合客户期望。这需要在每次迭代结束时进行，反馈将成为后续迭代的输入。
关键成功因素
在敏捷项目中，如果敏捷测试成功，就可以交付高质量的产品。
敏捷测试的成功需要考虑以下几点 −
敏捷测试基于先测试和持续测试方法。因此，基于最后测试方法构建的传统测试工具可能不适合。因此，在敏捷项目中选择测试工具时，需要验证是否与敏捷测试保持一致。
通过在开发生命周期的早期阶段实现测试自动化来减少总测试时间。
敏捷测试人员需要保持自己的节奏以与开发发布计划保持一致。因此，需要以产品质量为目标，随时对测试活动进行适当的规划、跟踪和重新规划。
手动测试占项目测试的 80%。因此，需要具备专业知识的测试人员成为敏捷团队的一部分。
这些具备专业知识的测试人员在整个开发生命周期中的参与，使整个团队专注于满足客户期望的高质量产品。
定义用户故事，强调最终用户期望的产品行为。
根据客户期望在用户故事级别/任务级别确定验收标准。
测试活动的工作量和持续时间估计。
规划测试活动。
与开发团队保持一致，以确保通过前期测试设计生成符合要求的代码。
首先进行测试并持续测试，以确保在预期时间内达到完成状态并满足验收标准。
确保在开发团队的各个级别进行测试sprint。
在每个 sprint 结束时进行回归测试。
收集和分析对项目成功有用的产品指标。
分析缺陷以确定哪些需要在当前 Sprint 中修复，哪些可以推迟到后续 Sprint。
关注从客户角度来看重要的事情。
Lisa Crispin 定义了敏捷测试成功的七个关键因素 −
全团队方法 − 在这种方法中，开发人员培训测试人员，测试人员培训其他团队成员。这有助于每个人了解项目中的每个任务，从而最大限度地发挥协作和贡献的作用。测试人员与客户的协作也是在一开始就设定好他们的期望并将验收标准转化为通过测试所需的重要因素。
敏捷测试思维 − 测试人员积极主动地不断提高质量，并与团队其他成员不断协作。
自动化回归测试 − 为可测试性而设计并通过测试推动开发。从简单开始，让团队选择工具。随时准备提供建议。
提供和获得反馈 − 由于这是敏捷的核心价值，因此整个团队都应该接受反馈。由于测试人员是专家反馈提供者，因此需要关注相关和必要的信息。作为回报，在获得反馈时应该适应测试用例的更改和测试。
构建核心敏捷实践的基础 −专注于编码的同时进行测试、持续集成、协作测试环境、逐步工作、接受变更、保持协同作用。
与客户协作 − 引出示例、理解和检查与产品行为映射的需求、设置验收标准、获取反馈。
纵观全局 − 使用真实世界的测试数据和示例通过面向业务的测试和示例推动开发，并考虑对其他领域的影响。
