技术文章

QA 指标的价值是什么？花精力去衡量、分析、审查然后根据结果采取行动还有意义吗？随着敏捷软件开发方法的流行和广泛采用，质量保证指标的类型和需求也发生了变化。QA 指标曾经衡量执行的测试数量以及通过或失败的测试数量，但这些指标不再为您提供提高 QA 测试质量或版本软件质量的重要价值。

顶级QA 指标提供真正的业务价值，并刺激变革，通过提高软件应用程序版本的质量来改善客户体验。听起来很简单，测量一些东西，检查结果，并使用结果来不断提高您的测试和应用程序质量。

质量保证指标的问题是它们很难量化，因为它们很大程度上是主观的。此外，测量 QA 指标是资源密集型的。然而，为了了解 QA 测试和开发团队流程的有效性，指标非常重要。毕竟，如果不衡量自己的起点，就不可能取得进步。敏捷团队实践持续改进。如果不衡量质量保证和开发团队指标，团队就没有改进的基准。 

这句格言适用于每个软件开发组织和团队。如果 QA 指标揭示的问题持续被忽视，应用程序质量就不会提高。忽视问题并不会让它们消失。除非采取行动，否则最好的 QA 指标不会提高软件质量。测量和行动为组织和软件开发团队提供商业价值。

本指南提供了前 5 个 QA 指标的列表，这些指标提供了可以持续提高软件应用程序质量的有价值的指标数据。

QA 指标 #1 – 用户情绪

衡量应用程序质量的首要指标是用户情绪或应用程序的用户体验质量。在客户支持电话、调查以及与产品经理或其他直接与客户合作的人员对话期间捕获和分析客户反馈。了解客户如何使用新功能或增强功能也可能表明在未来的冲刺工作中需要改进的其他领域。制定计划来满足客户的需求，并使应用程序能够有效支持用户工作流程需求。

用户情绪指标通过有效衡量感知的应用程序质量、可用性、稳定性和品牌价值水平来增加整个企业的价值。您可以使用客户访谈、在线或现场调查或使用客户输入测试会话来衡量用户情绪。客户输入会话吸引客户参与，并让他们直接提供有关用户体验的直观性和质量的输入。 

质量保证指标 #2 – 生产中发现的缺陷

发布后在生产中报告的缺陷是第二大 QA 指标，它提供了有价值的指标数据，可以持续提高软件应用程序的质量。该指标通常称为缺陷逃逸或缺陷泄漏，对于理解缺陷如何最终出现在生产版本中至关重要。分析生产中发现的缺陷表明以下一项或多项团队或组织职能中存在差距：

• 需求变更或范围蔓延

• 在相关故事中添加或删除的未记录的功能

• 添加的新功能没有记录故事或要求

• 应用程序特定领域缺乏测试用例的深度或广度

• 后端处理或集成连接功能无效或未覆盖

• 测试速度和测试覆盖率不平衡

• 测试环境与生产环境基础设施差异

没有人想要修补程序。生产的修补程序压力很大，时间紧迫，而且往往很仓促。修补程序也往往会导致其他缺陷，并且在版本上的测试执行完成后。不幸的是，为了保留和提供更高质量的客户体验，需要进行修补程序。客户对于企业保持活跃和成功至关重要。没有客户想要使用该应用程序，就没有业务，也没有软件开发团队。

生产中发现的缺陷实际上是通过计算客户或支持团队记录的缺陷数量来衡量的。另一种衡量方法是计算发布后创建的修补程序或补丁版本的数量。 

QA 指标 #3 – 测试用例覆盖率

前 5 个 QA 指标列表中排名第三的是测试用例覆盖率。测量测试用例覆盖率意味着分析测试中使用的测试用例的质量和内容。测量测试覆盖率可确保一个或多个测试用例涵盖所有故事、需求和验收标准。许多软件组织错误地将测试覆盖率与执行的测试数量等同起来。执行的测试数量仅用于营销目的；它没有任何作用来表明测试的有效性或针对需求的覆盖范围。

衡量测试覆盖范围的质量、深度和广度涉及审查测试用例并将其映射到用户故事和验收标准。例如，使用测试用例并使用测试管理工具链接到需求或用户故事。通常，测试管理工具支持到故事 ID 或需求 ID 或文档的直接链接。如果没有，您可以选择通过将故事 ID 或需求编号添加到描述、摘要或要重现的步骤来手动映射。手动链接更难以跟踪，但提供了需求连接，可以将测试用例覆盖率与用户故事或需求进行比较，并确保所有功能都可能被有效的测试用例覆盖。 

审查测试用例和用户故事，以确保测试用例准确涵盖所有故事和验收标准。当可追溯性存在时，团队可以确保所有功能都存在准确的测试覆盖率。然而，如果没有有效的测试用例，缺陷可能会被忽视。

QA 指标 #4 – 跨 Sprint 的缺陷

此列表中的 QA 指标 4 和 5 是相关的。衡量冲刺中的缺陷排在第四位，因为它衡量整个开发生命周期中缺陷的寿命。缺陷在预发布代码中保留的时间越长，缺陷最终出现在最终生产版本中的可能性就越大。

跨冲刺的缺陷滑移通常是由于过度提交故事或在冲刺期间未交付所有已提交的故事而引起的。完成故事必须包括开发和所有测试，包括单元测试、功能测试和集成测试。当故事由于冲刺结束时的时间限制而没有得到充分测试时，缺陷就会持续存在。当缺陷直到未来的冲刺才得到纠正时，它们的复杂性和范围往往会增加。

为了测量冲刺之间的缺陷，请记录从冲刺移动到冲刺的缺陷故事的缺陷 ID。然后，结合在冲刺中滚动的缺陷，并添加也在冲刺之间滚动的功能故事。比较它们并确定它们是否是相同或不同的症状，但具有共同的根本原因？如果生产中出现相同的缺陷或数量不断增加，则将解决缺陷滑移作为敏捷和持续改进过程的一部分。

质量保证指标 #5 – 承诺与交付的故事

如前所述，QA 指标 4 和 5 相似。根据这些相同缺陷在生产后期出现的趋势，跨冲刺发生的缺陷数量排名较高。衡量已提交故事与已交付故事适用于任何故事类型，包括功能增强和缺陷或缺陷修复。

衡量提交和交付的故事可以为 QA 团队提供有关故事相关但未完全交付时存在的代码或功能差距的信息。当两个故事相互依赖或相关且未同时完全交付时，集成测试可能会发现两个故事之间的缺陷。 

为了衡量已提交的故事与已交付的故事，请跟踪开发团队所有故事的进度。注意哪些故事在冲刺结束时已提交但未交付，并将它们与已交付的故事进行比较。这些故事是相互依赖的还是相互关联的？如果是，则可能存在缺陷，即如果未交付某个故事，则缺少支持每个故事的代码。 

测量从一个冲刺到另一个冲刺的故事的数量和类型表明存在规划问题和故事开发问题。如果滚动到未来冲刺的故事数量不断增加，那么版本中特性或功能缺失的风险就会变得更高。

从 QA 指标中获取真正的价值

在开始衡量这五个 QA 指标以改进测试和应用程序质量之前，请先明确 QA 团队的目标。在敏捷团队中，应用程序质量是整个团队的责任，而不仅仅是 QA 测试人员的责任。QA 测试的目标不是仅仅因为在大多数软件开发时间范围内不可能找到版本中的所有缺陷。改进 QA 测试的目的是确保应用程序满足组织定义的足够的应用程序质量标准。

QA 测试的内在质量是速度和价值之间的平衡。假设 QA 指标表明团队速度快但质量较低，那么平衡就失效了。为了保持应用程序和业务的相关性，速度和应用程序质量都是必要的。

使用 QA 指标并测量用户情绪、生产缺陷、测试用例覆盖率、冲刺中的缺陷以及团队承诺但未能交付的故事数量，可以为企业提供有关应用程序质量和速度之间的平衡点的有价值的整体情况。测量、分析和审查以提高应用程序质量，并采取持续改进措施以获得最佳结果。