软件质量保证KPI：
• 活动缺陷
• 自动化测试
• 覆盖需求程度
• 高度/严重缺陷和逃逸缺陷的百分比
• 拒绝缺陷的百分比
• 测试时间
• 编写的测试
• 自动化测试
• 代码覆盖率
• 每天修复缺陷
• 通过要求
• 通过测试
• 拒绝缺陷
• 审查要求
• 已经执行的测试实例
• 严重缺陷
• 执行的测试
• 工作时间表和约束
• 缺陷关闭率
你是否评估过QA的成功？
软件质量保证是软件开发过程中至关重要的一部分。它确保软件产品符合组织中设定的质量标准。然而，虽然软件质量保证无疑是可取的，但它也可能相当昂贵。本文将回顾如何评估你的质量保证并为你的投资提供良好的回报。但是首先，让我们看看QA如何影响软件发布，以及为什么你可能需要评估QA的成功。
QA对软件发布周期的影响
发布周期包括从开发和测试到部署和跟踪的不同阶段。在竞争激烈的市场中，较长的发布周期可能是不利的。因此，组织通常希望加快发布周期。然而，对速度的关注可能会导致产品质量的下降。不过通过在软件发布管理中实施最佳实践，你可以在不牺牲质量的情况下缩短发布周期。这里有一些方法可以做到这一点。
记录你的发布计划
记录发布计划是确保每个人保持一致的好方法。发布计划应该包含你的目标、质量期望和参与者的角色。记录发布计划后，确保所有团队成员都可以根据需要访问、引用和轻松更新它们。
自动化流程
自动化手动和重复性任务是在保持质量的同时加快发布周期的好方法。QA自动化释放了宝贵的人力资源，然后你可以将其重新分配给其他高优先级任务。这些可能实现自动化的任务包括自动化回归测试、代码质量检查和安全检查。
创建一致的发布周期
在评估发布过程的状态后，创建一个定期发布计划。
这样做将有助于创建一个你的团队可以适应的常规系统。最终用户也将知道何时期待更新，并且更有可能参与最新版本。
短的发布周期通常是一个好主意，其中包含小的、频繁的更改而不是长期的更改。有一个目标发布计划将帮助你的团队在发布周期中实现当前目标的同时，朝着发布日期努力。
开发和优化你的发布基础架构
发布基础架构中隐藏的瓶颈可能会减慢部署过程。因此，你必须优化交付基础架构并实施持续测试和测试自动化等实践。
进行发布回顾
发布回顾包括回顾过去版本中的流程，以提取可以帮助你在未来版本中改进这些流程的见解。发布回顾为团队提供了一个开放的环境来分析过去的问题并创建策略以避免将来出现这些问题。
但是，为了确保你的发布周期是一致的并且顺利运行，你可能需要评估QA在软件开发中的有效性。
为什么要评估软件质量保证的成功
这对于提高测试过程的效率和成本效益至关重要。
使用指标分析当前系统可以帮助你了解哪些领域需要改进。因此，你将能够为流程的下一阶段做出明智的决定。
如果不使用度量来保证质量，衡量软件质量将是一项挑战。如果你不测量它，你怎么知道你的质量保证策略是否有效。
什么是软件测试指标以及为什么需要它们？
软件测试指标是QA团队用来评估软件开发项目质量的衡量标准。跟踪它们可以快速了解测试过程，并有助于评估QA团队的有效性。
你无法改进你无法衡量的东西。软件测试中的质量指标正是为了实现这一点——改进的QA过程。作为回报，优化QA过程有助于更有效地为测试需求做预算。
因此，他们可以为未来的项目做出明智的决定，了解需要改进的地方，并做出必要的改变。那么，什么样的指标可以帮助你做出这些决定呢？
QA指标的类型
有许多QA指标或多或少对你当前的场景（即项目的当前状态）有价值。度量值可以通过它的可操作性来定义——测量可以带来改进——以及它是否可以不断更新。
以下是一些与项目当前状态相关的指标示例：
• 平均检测时间 – 平均需要多少时间来检测问题。你发现问题越早，修复问题的成本就越低。
• 平均修复时间 –平均需要多少时间来修复一个问题。这个时间也等于当你的产品或服务不起作用而你亏损并可能危及你的声誉时的停机时间。
• 测试可靠性 –测试反馈的价值。基本上，可靠的测试在测量中是一致的，并且可以复制。
• 发现逃逸缺陷 –有多少缺陷在生产过程中没有被QA团队发现，但在发布后被发现。
你如何知道要为你的项目使用哪些指标？同样，这完全取决于哪些指标对你的项目当前状态最相关和最客观。但是，请注意，有助于评估软件或组织质量的指标与评估QA团队有效性的指标是有区别的。
更深入地说，衡量后者的一种方法是设置KPI。
如何使用KPI评估质量保证
关键性能指标，或称KPI，是衡量软件测试质量保证有效性的设定指标。
KPI通常有助于评估QA有效性。然而，它们并不适用于所有场景。以下是测量KPI最有益的一些情况：
• 你已经执行了一段时间的测试过程。当测试处于早期阶段时，KPI是无益的。但是，如果你已经实施了一段时间的测试过程，测量KPI将帮助你了解哪些领域需要改进。
• 你正计划引入新的测试流程。测量当前流程的KPI将帮助你了解新流程的目标。
• 你有一个大型测试团队。与大型QA团队合作涉及测试任务的分配和管理。衡量 KPI
将帮助你确保流程高效并让团队成员步入正轨。
最常见的KPI
以下是评估QA绩效时最常用的一些KPI：
活动缺陷
此KPI用于缺陷、未解决缺陷或已修复缺陷的数量。低数量的活动缺陷表明产品处于高质量水平。测试经理设置一个阈值，超过该阈值，团队必须立即采取行动降低缺陷。
发现、计数、分类和解决缺陷的过程称为缺陷管理。这个过程包括完善所需的信息，例如缺陷的名称和描述。一旦团队掌握到相关信息，涉及的缺陷就会被优先排序并安排解决。
自动化测试
此KPI跟踪自动化测试的百分比。自动化测试的百分比越高，检测软件中关键错误的机会就越大。测试经理应根据软件类型和计算的自动化成本确定此KPI的阈值。
自动化测试指标的一些示例包括：
• 总测试持续时间-运行所有自动化测试所需的时间。
• 单元测试覆盖率-单元测试覆盖了多少代码。
• 路径覆盖率-测试覆盖的线性独立路径的数量。
覆盖需求程度
此KPI衡量一个或多个测试用例覆盖需求的百分比。目标应该是让每个需求至少有一个测试用例会覆盖到。测试经理监控此KPI并指定当需求无法映射到测试用例时应该做什么。
需求通常在覆盖矩阵中描述——一个包含需求和相应测试用例链接的表。当需求很大或没有清晰记录时，这些矩阵很有帮助。当新团队成员必须熟悉需求时，它们也会派上用场。
使用需求覆盖矩阵允许测试经理将所有需求都放在一个资源中，所有团队成员都可以访问。它使开发人员和QA工程师的工作更有效率，并有助于确保他们考虑到所有需求。
高度/严重缺陷和逃逸缺陷的百分比
逃逸缺陷是指在测试期间逃逸检测并被最终用户发现的问题。团队应分析这些缺陷以改进流程并防止类似事件发生。
跟踪逃逸缺陷率可以促成对更好或更自动化测试的需求。它也可能表明需要放慢开发过程以进行更广泛的测试。
拒绝缺陷的百分比
此指标指的是测试人员发现但被开发人员拒绝的缺陷的百分比。如果缺陷不可重现、不正确或已经报告，则可以拒绝。
被拒绝的缺陷会浪费很多时间，降低测试团队的效率。它们还会降低测试人员的士气，因为这会让他们看起来不专业。如果被拒绝的缺陷数量很高，测试人员可能需要进一步培训或提供更新的文档。
测试时间
此KPI用于跟踪一个功能从“测试中”阶段转移到“完成”需要多长时间。因此，它有助于衡量一个功能的复杂性以及测试人员的有效性。
所有这些KPI都有助于衡量你的QA团队在不重复地识别软件产品中的缺陷方面的效率以及测试需要多少时间。当你打算从外包公司聘请QA服务时，这些KPI至关重要。
如何选择QA外包公司
外包软件QA服务可以节省时间和金钱，同时可以让你专注于核心业务。然而，你选择的供应商的质量将直接影响质量保证外包的投资回报率。
以下是评估软件质量保证公司时需要注意的一些因素。
• 测试基础设施。确保QA服务公司拥有适合你产品的测试基础设施，例如必要的软件、操作系统、硬件设备、测试工具和经过认证的测试程序。
• 产品组合。花些时间查看供应商的产品组合。批判性地检查它的历史、现有客户、使命和声誉。你会想找那些稳定发展、声誉良好的公司。
• 客户关系。寻找以合作伙伴关系为导向的公司。这些公司努力培养和保持与客户的良好客户关系。因此，你更有可能获得愉快的体验并与此类供应商建立长期关系。
• 灵活性和可扩展性。确保公司拥有灵活的业务模型，并且能够处理测试需求的变化。随着你的测试需求的发展，这种灵活性会派上用场。
• 安全性。仅考虑在网络安全、临时安全、数据库安全和知识产权保护领域提供高度安全环境的供应商。
• 文档标准。确保供应商遵守必要的QA留档标准。例如，他们应该充分记录测试结果、报告、计划、脚本和场景，并为你提供对文档的轻松访问。
这些因素对精通商业的专业人士来说似乎是显而易见的。但是如果你在选择第三方供应商时不考虑它们，你可能会损失时间和金钱，而这些时间和金钱可以投资到实际的质量保证中。
软件质量的成本
除了供应商费用或内部专家工资之外，软件质量成本是你确保软件产品质量的所有费用。了解这些成本是什么将有助于你正确地为它们制定预算。
让我们来看看不同类型的QA成本。
质量保证成本的类型
主要的软件质量保证成本包括预防成本、检测成本、内部故障成本和外部故障成本。
• 预防成本。这是一个组织为防止质量问题所做的投资。预防成本包括培训开发人员、防错、根本原因分析和改进计划。
• 检测成本。这些是软件质量控制过程的成本，旨在在软件提供给最终用户之前发现和解决缺陷。它们包括与检查和测试代码库相关的成本，以及技术支持服务成本。
• 内部故障成本。内部故障成本是在产品到达最终用户之前解决缺陷所产生的成本。它们包括浪费的时间、延迟的项目和返工有缺陷产品的成本。
• 外部故障成本。外部故障成本是指与交付低质量软件产品和服务相关的成本。它们包括退货、保修索赔、诉讼和声誉受损。
降低质量保证成本和提高投资回报率的方法
软件质量的成本会很快增加，并成为一项可观的投入。以下是一些有助于你最大限度地降低成本和最大化投资回报率的举措：
• 尽快开始测试。尽早开始测试以将QA成本保持在最低水平非常重要。早期测试减少了发布后发现关键缺陷的机会。此外，在开发后期修复缺陷的成本可能是在设计和架构阶段修复缺陷的30倍。
• 明智地自动化测试。如果你的产品稳定，自动化测试是在开发过程中节省成本的绝佳方式。即使你的软件产品是动态的，你也会从尽可能多的测试自动化中受益。测试自动化提高了效率，允许QA工程师更快地交付错误报告，以便开发团队可以更快地开始修复缺陷。自动化还使你能够拥有更好的测试覆盖率。
实施测试自动化时，避免急于立即自动化每一个测试。相反，仔细考虑贵公司的测试需求，计算测试自动化的投资回报率。
• 关注隐性成本。在为项目设置预算时，要注意测试期间可能出现的隐性成本。例如，你的产品可能具有你的测试工程师不熟悉的独特功能。为了正确测试，他们需要花时间了解产品，从而产生采用费用。
其他可能的间接费用包括测试工具的基础设施成本和维护费用。这些隐性成本可能会占用你预算的很大一部分。因此，你需要密切关注它们，并寻找减少隐性费用的方法。
• 明智地选择你的QA团队。QA团队的质量对QA的投资回报率有重大影响。因此，在选择外包软件QA需求的团队时，你需要考虑几个因素。这些可能包括他们的产品组合、声誉和测试基础设施。
• 评估你的QA成功。这样做将使你能够弄清楚如何改进你的测试过程并做出更好的决策。
除了成本之外，另一个需要考虑的问题是与第三方公司的正式协议。
如何与外包QA公司签订合同
质量保证服务级别协议或QA SLA是你与软件QA公司之间书面合同的一部分，其中规定了你对服务提供商的期望以及解决冲突的流程。
通常，这些是为了确保资源的可用性。例如，SLA可能包括如果项目规模扩大，提供者可以多快扩展团队。
为什么需要SLA
合同很简单，但是QA SLA 将帮助你确保一些结果：
• 服务质量。SLA 允许客户设定他们对服务质量的期望，并轻松衡量服务提供商的表现。因此，QA团队需要对糟糕的绩效表现负责。
• 清晰的沟通。清晰的沟通对于团队之间的成功协作至关重要。SLA有助于确保事先就沟通方法和工作时间表达成一致，从而使沟通更加顺畅。
• 最佳程序和实践的文档。当最佳实践在书面文档中明确陈述时，它们通常更有可能被遵循。SLA使服务提供商能够为其员工提供最佳实践的快速参考文档。
• 相互保护和安心。SLA 摆脱了假设，为所有相关方提供了安心。因此，你可以放心，如果出现问题，你组织的利益会得到保护。
SLA的主要组成部分
软件QA外包的服务水平协议通常由两个关键组成部分组成——QA服务和管理。
服务要素包括：
• 提供的软件质量保证服务的细节。这部分明确定义的单个服务的列表，其中包含服务描述、提供此服务的人员和对象以及何时需要单个服务。
• 服务可用性条件。这部分应定义一个工作时间表，该表会包括协议中涉及的每个实体具体到一天中的时间、一周中的时间和时区格式可用时的时间。
• 有关各方的责任。这些是每个实体在法律上有责任履行的义务。
• 成本/服务权衡。
• 服务标准。结合估计的工作量定义了什么是低和高绩效水平。
管理要素通常包括：
• 测量标准。这些是明确定义的评估工作的方法。
• 报告程序。这些包括报告类型和格式，即谁在何时以及如何报告。
• 冲突解决程序。这是一种解决客户-供应商冲突的方法，从识别分歧到定义各方解决职责。
• 更新合同的机制。这是关于如何在已签署的合同中启动和实施更改的说明。
预算成本，达成协议，现在让我们看看外包 QA 的过程是如何处理一些现实生活中的案例的。
既定目标和指标的好处在长期项目中最为明显。虽然较短的项目（产品发布前的性能和负载测试）可能会受益于“一劳永逸”的方法，但与QA团队的长期合作伙伴关系需要一致的沟通和明确的既定目标。
结论
软件开发中的质量保证对于高质量产品的开发至关重要。然而，为了确保积极的投资回报率，你需要：
• 确保你使用正确的QA指标来评估你的产品/服务。
• 设置KPI以评估QA团队的有效性。
• 如果你打算外包QA服务，请聘请合适的专家。
译者介绍
崔莹峰，51CTO社区编辑，一名70后程序员，拥有10多年工作经验，长期从事 Java 开发，架构设计，容器化等相关工作。精通Java，熟练使用Maven、Jenkins等Devops相关工具链，擅长容器化方案规划、设计和落地。
原文标题：How To Evaluate Software Quality Assurance Success: KPIs, SLAs, Release Cycles, and Costs
链接：https://dzone.com/articles/how-to-evaluate-software-quality-assurance-success?fromrel=true
