常见问题

质量保证指标的价值是什么?是否有必要加大努力来衡量、分析、审查结果,然后根据结果采取行动?类型和需要 质量指标已经演变 随着敏捷软件开发方法的普及和广泛采用.质量保证指标曾经测量过执行测试和测试通过或失败的数量,但是这些指标不再为提高质量保证测试或发布版本的软件质量提供重要的价值。

… 顶级质量保证指标提供实际业务价值 并通过提高软件应用程序发布的质量来促进改进客户体验的变化。听起来很容易,测量一些东西,回顾结果,并利用结果不断提高你的测试和应用质量。

质量保证指标的问题是它们很难量化,因为它们在很大程度上是主观的。此外,衡量质量保证指标是资源密集型的。然而,为了获得一个关于质量保证测试和开发团队流程的有效性的想法,度量是重要的。毕竟,如果不衡量你的起点,就不可能改进。敏捷团队不断进行改进.如果不衡量质量保证和开发团队的度量标准,团队就没有一个从工作到改进的基线。 

这句格言适用于每个软件开发组织和团队。如果质量保证指标揭示的问题持续被忽略,那么应用程序质量的改进就不会发生。忽视问题并不能使它们消失。 最佳的质量保证指标 除非有行动,否则不会提高软件质量。度量和操作为组织和软件开发团队提供业务价值。

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

质量指标#1-用户情绪

衡量应用程序质量的第一个标准是用户情绪或用户体验的质量。捕捉和分析客户在客户支持电话、调查和与产品经理或其他直接与客户打交道时的反馈。了解客户如何使用新的功能或增强,也可以说明在未来的冲刺工作中需要改进的其他领域。制定一个计划,以满足客户的需求,并保持应用程序对支持用户工作流需求有用。

… 用户情绪度量 通过有效地衡量感知的应用程序质量、可用性、稳定性和品牌价值水平,在整个业务中添加价值。您可以通过客户访谈、在线或现场调查,或者使用客户输入测试会话来衡量用户情绪。客户输入会话将客户引入,并让他们直接提供关于用户体验的直观性和质量的输入。 

质量指标#2-生产中发现的缺陷

发布后的生产中报告的缺陷是数字2质量指标,提供了有价值的指标数据,可以持续地提高软件应用程序的质量。缺陷泄漏或缺陷泄漏通常被称为缺陷泄漏,该度量对于理解缺陷如何最终在生产时被释放是至关重要的。分析在生产中发现的缺陷,可以看出以下一个或多个团队或组织职能的缺口:

• 需求变化或范围蠕变

• 相关故事中添加或删除的无文件特征

• 在没有记录的故事或要求的情况下增加的新功能

• 在具体应用领域缺乏测试用例的深度或广度

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

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

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

没有人想要热修复。生产的热修复是压力大,时间敏感,经常匆忙。热修复也会导致额外的缺陷,并且在发布版上完成测试执行之后。不幸的是,热修复对于保留和提供更高质量的客户体验是必要的。客户是企业保持活跃和成功的关键。没有客户想要使用应用程序,就没有业务和软件开发团队。

在生产过程中发现的缺陷实际上是通过计算客户或支持团队记录的缺陷数量来衡量的。另一个衡量标准是计算发布后创建的热修复或补丁发布的数量。 

质量指标#3-测试用例覆盖

排名前5位的第三位是测试用例覆盖率。 测量测试用例覆盖率 分析用于测试的测试用例的质量和内容。测试覆盖率确保在一个或多个测试用例中涵盖所有的故事、要求和验收标准。许多软件组织错误地将测试覆盖率与执行的测试数等同起来。执行的测试的数量仅对营销目的有用;它不表明测试的有效性或覆盖面与需求。

衡量测试覆盖面的质量、深度和广度涉及审查测试用例并将它们映射到用户故事和接受标准。例如,以您的测试用例和使用测试管理工具链接到需求或用户故事。通常,测试管理工具支持直接链接到故事标识或需求标识或文档。如果没有,您可以选择手动映射,在描述、摘要或复制步骤中添加故事标识或需求号。手动链接更难追踪,但提供了需求连接,以便将测试用例的覆盖率与用户故事或需求进行比较,并确保所有功能可能都包含有效的测试用例。 

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

质量指标#4-短跑中的缺陷

这个列表上的标准4和5是相关的。测量短跑之间的缺陷位于第4位,因为它通过开发生命周期来衡量缺陷的寿命。在发布前代码中,缺陷保存的时间越长,最终生产版本中的缺陷就越有可能终止。

在短跑过程中的缺陷滑移通常是由过度承诺故事造成的,或者在短跑过程中没有提供所有承诺的故事。移动到完成的故事,必须包括开发和所有测试,包括单元、功能和集成测试。当故事由于短跑结束时的时间限制而没有被完全测试时,缺陷依然存在。当缺陷直到未来的短跑才被纠正时,它们的复杂性和范围就会增加。

为了测量短跑之间的缺陷,请记录从短跑到短跑的缺陷故事的缺陷标识。然后,结合正在快速跑的缺陷,添加从短跑到快速跑的特征故事。比较它们,并确定它们是否是相同或不同的症状,共享一个根本原因?如果同样的缺陷出现在生产中或数量持续增加,那么解决 作为敏捷的一部分的缺陷滑移 以及持续改进的过程。

质量指标#5-承诺与.传递故事

如前所述,质量保证指标4和5是相似的。由于这些相同的缺陷在生产后期出现的趋势,在短跑中出现的缺陷的数量会更高。测量的 承诺与提供的故事 适用于任何故事类型,包括功能增强和缺陷或缺陷修复。

测量承诺的和交付的故事提供了质量保证团队在故事相关但未充分交付时存在的代码或功能缺口的信息。集成测试可能会发现这两个层之间的缺陷,当它们是依赖的或相关的,并且没有完全同时交付。 

为了衡量承诺和。提供故事,跟踪开发团队的所有故事的进展。注意哪些故事是承诺的,哪些故事不是在短跑结束时传递的,并将它们与传递的故事进行比较。故事是相互依赖的,还是相互关联的?如果它们是存在的,那么在没有传递的情况下,支持每个故事的代码可能存在缺陷。 

测量从短跑到短跑的故事的数量和类型是一个规划问题和故事开发问题。如果滚动到未来短跑的故事数量持续增加,那么在发布中丢失功能或功能的风险就会更高。

从质量保证指标获得实际价值

在开始测量这些前五名质量指标以改进测试和一个应用程序的质量之前,请阐明质量团队的目标。在敏捷团队中,应用程序 质量是整个团队的责任 ,不仅仅是质量保证测试人员。质量保证测试的目标不是仅仅因为在大多数软件开发的时间框架中不可能找到发布中的所有缺陷。改进质量保证测试的目的是 提供保证 该应用程序符合组织规定的足够应用程序质量标准。

质量保证测试的内在质量是速度和价值之间的平衡。假设质量保证指标表明团队有速度,但质量较低,那么平衡就会失去。速度是必要的,以保持应用程序和业务相关性,以及应用程序的质量.

使用质量保证指标和衡量用户情绪、生产缺陷、测试用例覆盖、跨短跑的缺陷,以及团队承诺但未能提供的故事数量,为业务提供了一个有价值的关于应用程序质量和速度之间平衡的总体情况。测量、分析和审查,以提高应用质量,并采取行动持续改进,取得最佳效果.