大家星期五，朋友们！ 6月底，我们将在
质量检查专家课程中成立一个新小组，这将是今天出版的重点。
您可以通过许多指标来衡量测试人员团队的有效性。 其中之一是拒绝的缺陷率，或者拒绝的错误报告数除以接收到的报告总数。 您必须要考虑的是，如果被拒绝的报告数量为零，那很好，但这并不是那么简单。 让我们看看被拒绝的错误的类型，看看它们如何影响被拒绝的错误率，并为您的团队计算正确的比率。
拒绝错误分为三类：
让我们从错误本身开始。
不可复制的错误
有两种不可复制的错误。 首先是一个很难重现的错误。 这可能是由于几个参数的交互而导致的错误，其中一些您甚至都不知道。
假设您连续进行了几次测试，并且其中一个测试将配置参数从默认值A更改为其他值B。仅当配置参数包含值B并且输入值为C时，才会发生错误。尝试重现该错误，很可能您希望从一个已知状态开始以初始化系统（或可能执行全新安装）。 因为配置参数现在再次包含默认值A，所以不会发生错误。
这种不可复制的错误的另一种形式是，当测试确实发现缺陷时，但是回放信息中没有数据：一个步骤，一个特定的输入值或对错误的理解仅发生在特定的过程中。 结果，重现该错误的尝试不会导致任何后果。
但是，在上述两种情况下，产品本身确实存在缺陷。
第二种不可再现的错误是由于错误不存在而无法重复时。 测试人员可能注意到了一些东西，但是误解了，或者用于测试的系统可能存在一些问题，例如硬件组件故障，驱动程序不兼容或访问设置不正确。 尝试在正确配置的系统上重现该错误失败。
这两种类型的错误通常在错误报告系统中标记为“已拒绝-无法复制”。
错误错误
如果测试人员确定产品应以某种方式运行，并在行为未达到其预期的情况时报告错误，则会发生此类错误。 但是，对要求的更详细研究表明，测试人员的期望是错误的，并且产品实际上可以正常运行。 也就是说，被测产品工作正常，而对要求不够熟悉的测试人员犯了一个错误。
此类错误通常在错误报告系统中标记为“已拒绝-不是错误”或“已被体系结构拒绝”（也就是说，行为与体系结构一致）。
错误重复
重复错误是已经报告过的错误，而下一个在之后报告了。 仅当其外观的“症状”相同时，错误才是重复的。 而且，如果错误的根本原因相同，但是事实证明“症状”不同，则这不是错误的重复！
这些错误通常在错误报告系统中标记为“已拒绝-复制/重复”。
被拒绝的错误如何影响团队
显然，不正确的错误是测试人员浪费时间来重现错误并报告错误，对错误进行排序的人员花费在阅读和理解错误以及开发人员试图重现不可复制的错误上的时间。修复（和故障）不需要此修复的东西。
除了拒绝的错误率或RDR可以衡量测试人员团队效率低下的事实外，他还谈到了测试人员的专业水平。 由于报告中缺少必要的信息而无法重现的错误表明，测试人员不是一丝不苟的，并且没有进行足够的工作以使用上述步骤来重现此错误。 此外，对于不经常出现的错误，测试人员通常不会注意到报告中的回放频率较低。
错误错误的出现表明测试人员没有完全理解产品要求。 重复错误表明测试人员没有在本地错误数据库中执行最小搜索以检查它是否较早发生。 或者，这意味着报告此错误的专家不是第一个在名称中包含正确关键字以方便搜索其他同事的专家。
反过来，如果事实证明我发现的错误被拒绝，那我很愤慨，因为我被认为是外行。 一方面，这意味着我将捍卫发现的错误。 当我的报告被拒绝时，我将进行以下操作：
- 我再次检查错误是否在系统中重现，如果错过了某些内容，请添加播放步骤；
- 如果我对需求的误解是由不明确的需求或不正确的文档引起的，我将坚持将该错误标记为文档错误，并且仅在更正文档后才将其关闭；
- 如果我认为满足要求时产品的行为不正确，那么我将与架构师和开发人员讨论这些要求，并尝试说服他们需要更新这些要求（最后，我代表客户的意见！）；
- 如果错误被重复拒绝，我将确保没有以相同的方式标记该错误，或者确保该错误不会“根据相同的情况”出现。
另一方面，拒绝错误的可能性使我保持谨慎。 如果我不确定自己是否已发现错误，则在报告之前，我将花费更多时间进行检查。 我经常问同事我是否正确解释了需求，或者我检查错误是否在其他人的系统上重现。
关于完全不存在被拒绝的错误的意见
测试团队应监控并努力降低RDR的水平。 唯一的问题是，什么RDR应该被认为是好的？
乍看之下，似乎0％是最佳结果，但我对此表示强烈反对。 我相信当RDR保持在健康水平时，这是正常的，因为如果RDR接近零，那么测试团队显然会遭受比RDR太高的严重问题。
测试团队必须付出巨大的努力才能实现极低的RDR。 将分析每个被拒绝的错误，以了解发生了什么问题，并且每个报告被拒绝的错误的测试人员都必须解释实际发生的情况以及将来如何避免这种情况。 结果，测试人员将报告他们绝对确定的错误。
如果他们发现他们认为会损害产品可用性的行为，则他们宁愿将这种行为视为理所当然，而不是证明他们发现了实际上并非基于要求的错误的错误。 如果他们有证据表明发生了错误，但是没有重现该错误的好方法，则他们宁愿不报告该错误。 他们真的不想让自己难过。 如果他们遇到轻率的错误，他们可能会决定根本不报告该错误，因为次要错误并不总是会修复它，那么为什么要冒险冒险并担心发现的错误将被拒绝？
简而言之，争取极低的RDR会在测试团队中产生压力和不健康的行为，还会增加某些错误被忽视的可能性。
我们需要测试人员，他们不仅要报告明显的错误，还要警告项目中的任何可疑行为。 我们认为，高度重视确保错误不会消失的测试人员，即使以重复报告为代价，也比花几个小时检查报告中是否已报告错误的测试人员好，他们担心他们复制。 我们希望测试人员通过质疑系统架构师或需求规范的措辞来感到自在，即使这意味着他们的某些错误将被标记为拒绝。
我们需要不害怕时常犯错误的测试人员。 这意味着需要平衡，因此一些小的RDR被认为是可以接受的。
寻找最佳剔除缺陷系数
我的经验法则是RDR应该为15％。 此价值基于我在测试人员团队中的经验，该团队从各个方面来看都是一支优秀而有效的团队。 是我们的RDR在几个项目中相继进行，而另一个团队在同一项目中并与我们并行工作，尽管它对产品的了解较少并且被认为效率不高，但RDR却达到了30％ 。
除了我的内心感觉，我认为这种含义没有任何道理。 这绝对是不科学的。 我不会与以10％或20％为目标的团队争论，但我认为忍受30％或设定5％的目标已经是一个问题。
最后，这是测试人员团队必须根据产品的功能，团队的专业知识水平，开发模型，开发团队的经验等来做出的决定。 我强烈建议您注意RDR，并考虑是否需要对其进行处理。 如果太高或太低，则应采取适当的措施。
按照传统，我们正在等待您的评论，并邀请您参加将于6月14日举行的
免费网络研讨会 。 待会见！