被逃逸的缺陷百分比是否是测试仪性能的良好KPI？

#1 楼

以我个人的观点，我认为这种理论是有缺陷的。

正如您所说，有太多变量在起作用：平等对待所有错误，但事实并非如此。有些错误更为严重，而有些仅仅是表面上的。如果他们真的想解决已逃脱的缺陷的百分比，那么他们最好找到一种方法来根据关键程度正确，准确地对错误进行加权。
这种方法将鼓励测试人员专注于数量而不是质量。与发现一个阻止程序相比，发现两个外观上的错误给测试人员带来了更多的好处。
这种方法将鼓励测试人员专注于用户体验测试/ UI测试，因为客户更有可能找到与用户体验相关的错误/ UI。非面向客户的测试可能不会得到足够的重视或努力。
对于每个测试项目，其上下文都是不同的。假设某产品被推向市场，却没有分配大量的测试时间，而客户又回来了很多错误，因此错误逃逸率很高，这是测试人员的错还是管理问题？ />我个人非常不喜欢这种方法。

正如Shadow所指出的那样，我相信以下是一种更好但较慢的方法来衡量测试人员的绩效/贡献。

在继续进行下一步之前，需要解决一些问题：


我们无法捕获所有错误，因此只能通过查看有多少错误逃逸到了测试程序中来衡量测试人员的性能生产代码不是可行的度量。
对于给定的软件项目，加班会变得很成熟，例如随着时间的流逝，为该项目发现的错误数量将减少。

那么，我们如何衡量测试人员的性能呢？在给定测试人员加入给定项目之前。
在维护准确的软件质量记录的同时，检查该测试人员捕获的错误的严重性。很难定量地评估软件质量，但是有一些迹象可供我们参考，例如： '幸福。
间歇出现的错误减少。
测试自动化捕获的错误增加（由该测试人员开发，如果适用的话）。并向开发人员提供简洁的错误说明。
该测试人员是否可以优先考虑测试区域并正确分配时间/精力。
开发人员是否对该测试人员提供了积极的反馈。


总而言之，由于测试员的工作很复杂并且需要跨技术或非技术的多个领域的技能，因此没有可以直接而准确地衡量测试员绩效的精简数字。因此，在确定测试人员是否为优秀测试人员之前，将需要较长的时间并考虑多个参考。

#2 楼

简短而简单的答案：否

稍​​有细微差别的答案：可以，但是您必须非常小心

真正的解释：和其他大多数测试人员一样绩效KPI，逃逸的缺陷取决于太多其他人的活动，无法作为简单的衡量标准来维持生存。与打字员每分钟的单词数或标准测试的准确性不同，还有许多其他因素导致逃逸的缺陷，包括但不限于：



缺陷的严重性和影响-一个逃脱者完全阻止了客户，这远比几个次要且容易解决的小问题要严重得多。软件和增强功能越复杂，丢失某些内容的可能性就越大。使用逃逸的缺陷百分比会给使用复杂增强功能的测试人员带来损失。

缺陷的位置-根据代码的性质，在某些类型的软件中查找缺陷比在其他类型的软件中查找缺陷要容易得多。测试人员不应受到惩罚，因为他们正在开发的软件更容易出现细微的，难以发现的缺陷。

测试时间-这是不言而喻的，没有简单的软件可以被完全测试（而且没有人愿意）。如果测试团队由于延迟交付和不可更改的期限而缺乏合理的时间来测试功能，则该功能将发布更多错误。测试人员对此没有错。

开发人员-一些开发人员编写的错误比其他开发人员更多。测试人员无法控制他们测试的代码，并且测试有很多错误的人比测试问题较少的人遗漏的百分比更高，尤其是因为掩盖错误的可能性更高。

设计/需求-即使在最敏捷的环境中，客户也不会将增强请求报告为错误，这是很常见的，因为该软件没有完成他们期望的工作（或者没有达到他们的期望，但没有达到他们的期望）。客户得到他们想要的东西，观察到的东西被构建并看到大量的演示是正常的，只是发现当他们尝试使用它时，它实际上并不能满足他们的需求，原因是在此期间没有人知道开发过程。这是因为软件开发（和测试）是一个严重的问题。没有“正确”的答案，也没有采取任何最佳方法。一个不知道有一个或多个新开发人员正在使用该软件的测试人员并不知道他们需要更仔细地进行测试。即使他们知道，与熟悉该软件的开发人员编写的代码相比，异常情况或意外交互的可能性仍然更高。

我建议您看一下这些问题的答案，以获得有关KPI一般危险的更多信息：

什么是软件质量保证的良好KPI？质量检查的目标是减少年度错误？

如何评估质量检查员工的绩效？

测试人员的绩效指标/指标

#3 楼

我们有几个很好的答案，例如张瑜，凯特·保尔克（Kate Paulk），om

让我加2美分：它”。

关于工作场所的讨论很多。关于如何使用错误的度量标准会歪曲团队之间的合作并使团队合作变得不可能的问题。只是用于衡量质量检查绩效的一项指标。其他是：


反馈的时间延迟（及时响应），错误测试花费的时间（我们需要快速通过它们），
按照流程进行操作并记录在案
客户对产品的满意程度

还有很多，很多都不容易衡量。质量是一项团队运动。如果管理层将尝试在测试人员与任何其他团队（开发人员，分析师/工程师，系统管理员，开发人员，客户等）之间建立对抗性关系，那么他们应承受的灾难将不可避免地随之而来。

” prod”是可能且容易的-如果需要花费无限的时间来测试所有内容（并在修复了所有错误后重新测试），并且我们不需要客户的资金，因此我们从不发货。否则，将发布视为“足够好”且对付费客户满意的商业决定。

当然，如果我们进行更多测试，我们将发现更多错误。客户会等待还是使用具有错误代码但具有更理想功能的竞争对手转到竞争对手？

这就是为什么停止测试和发布是一项商业决定的原因。当然，如果只有PROD中的错误是他们需要遵循的唯一指标，那么测试人员就需要更多的时间进行测试。因此，如果企业决定超越测试人员并发布产品，为什么测试人员应该负责？

测试人员向管理层提供当前版本的质量状态信息，并且管理层决定在产品中严重错误的风险降低到可接受水平时决定发布。

#4 楼

每当衡量绩效时，您都在定义好或坏的绩效。

当然，专业人士希望按照他或她的标准进行专业工作，但专业人士也希望获得管理层的批准，奖金，晋升，不被解雇等。
生产系统中没有bug是渴望但也完全不可能实现的理想目标。一个好的测试人员，尤其是一个好的测试经理，应该理解“完全不可能”的部分，并就成本有效的测试级别和过程向管理层提出建议。管理层真正需要的是可接受的错误级别和对系统质量的可接受的信心，从而获得可接受的开发和测试总成本。没有影响是值得怀疑的。您是否要鼓励开发人员/测试团队修复十二个较小的UI问题或一个导致神秘崩溃的大隐患？整个开发过程，以及生产系统中错误的估算成本。最好的KPI必须是一个比率。
许多非常关键的错误都与规范的基本误解有关。俗话说“建立我需要的东西，不是我想要的东西，当然不是我告诉你的东西。”当出现此类错误时，始终是“这是错误修复还是规范更改？”答案几乎是找不到的。围绕这种事情建立KPI会鼓励指责。 （除非规格是合同的一部分，否则它将变成“按设计工作是对'不工作'的委婉说法。”

#5 楼

我们必须对其进行定义并且存在不同的意见，这并不是客观的克雷蒂亚主义。

通常，您应该避免使用这种措施来衡量质量保证人员。
不使用此方法的原因：


可以计算数字，并且随着时间的推移经常使用数字。专注于
应用程序代码质量通常会影响错误发生率，包括细微和隐藏的错误发生率。已通过测试发现的错误进行了证明
团队认为测试人员正在增加价值，以防止错误进入生产环境
在新领域采取了测试计划，以增加测试的价值
知识和与其他人的关系团队成员和团队
领域知识和判断使用哪种测试的能力

#6 楼

捕获默认泄漏度量很重要，但是如何捕获它；更重要

首先，不应仅将其捕获以评估测试人员的表现。

为什么捕获此度量很重要？ br />
计算缺陷泄漏对于评估团队（开发人员，测试人员和其他利益相关者）交付的产品的整体质量非常重要。
由于代码合并错误
某些要求可能未正确捕获，并在UAT期间被指出为缺陷

更多原因，请参阅泄漏缺陷的原因客户总是会报告一些缺陷。我完全同意。但是，如果项目团队有错误，该怎么办？
评估此指标并采取措施以避免该问题很重要；项目团队至少犯了一些错误。
在示例中，问题中引用了该错误；客户报告的错误的RCA应该使用5个Whys或Fishbone进行，以便找出所有主要原因。即使没有进行分析，组织将来如何采取措施避免此类情况发生？流程将如何成熟？从我的经验中，我可以向您保证，认真的分析将反映实际问题，但另一方面，没有任何分析或随意的分析会把所有内容都放在测试人员身上。因为，最容易说的是缺陷被泄漏，并且测试人员负责测试。因此，应该责怪他们。

我想在这里引用一个项目中的缺陷泄漏过高。因此，从分析客户报告的缺陷开始。并且在完成RCA后，可以得出结论，缺陷漏出率高的原因是“测试人员不足”。这一发现已与所有项目共享，以便他们可以从中学习并避免将来发生此类情况。

例如，在我工作的一家公司中，缺陷泄漏的允许限制为7％，缺陷泄漏的计算方式如下：

缺陷泄漏=（客户报告的缺陷总数/ 100 X100

我可以理解为什么分母不是“发现的缺陷总数”。将该指标应用到位2年后。

即使缺陷泄漏在极限范围内，我们仍然会继续进行并检查所有客户报告的缺陷并进行RCA。我认为这很重要，否则我们的组织将永远无法将目标从7％降低到4％。 br />
多数情况下，在记录错误时，用户并不关心分配适当的优先级和服务器性。我的意思是用户认为在功能范围内的功能，但是这些功能从来都不是与我们共享的需求的一部分。 br />
缺陷消除效率= [（内部总缺陷数/（内部+客户报告的缺陷总数）] X100



内部缺陷=文档审阅缺陷，代码审查缺陷，内部测试期间发现的缺陷
外部缺陷=内部缺陷+客户报告的缺陷

#7 楼

逃逸的缺陷百分比可以是一个公平的KPI，但有两个限制：


您可以定义度量标准中包括哪些缺陷类别

可以要求UI测试人员在不测试所有副作用或组合的情况下，验证每个控制元素对应用程序行为是否具有预期的效果。然后，如果您的测试人员错过了一个始终无法单击的按钮，则可以针对他们保留该缺陷，但是不能在特定情况下使按钮无法单击。如果您想可靠地发现第二种情况，则必须同意也应该测试哪些方案。


，给测试人员足够的时间来发现所有此类缺陷

这很简单。您要么告诉您的测试人员他们应该捕获哪些缺陷，他们告诉您他们需要多少时间，要么您告诉测试人员截止日期何时，然后他们告诉您他们将能够弥补哪些缺陷。 br />
这些限制对于使度量标准首先可以达到是必需的。如果您强加了一个团队无法实际达到的度量标准，那么它将被忽略或发挥作用。

最后，请记住，最有效的度量标准是团队购买的度量标准。在引入此类指标之前，您应该将其提交给团队，并询问它们是否有意义。

#8 楼

这是一个相关的指标，但是如果依赖它作为主要指标，则可能会歪曲性能指标。相同的缺陷可能有多种症状。仅报告症状的QC将产生多个报告，这些报告会立即显现出相同的错误，而忽略了许多很少显现出来的错误。

低概率的高客户影响（而不是高客户影响）的缺陷在这种度量标准中不过是噪音，但它们可以为企业带来灾难。