我们要打破“质量可以绝对衡量”的迷思，学习如何将质量指标视为一种信号而非有局限的目标。

霓虹灯显示着数字和图表，旁边是一个大型的粉色霓虹放大镜，上面写着“QA迷思”。

让我们来破除一些QA迷思。

第一个迷思：质量是可以被衡量的。

每个人都想衡量质量，但认为质量可以绝对衡量的想法是一种迷思，一个误区。

想象一下，你试图衡量一次家庭公路旅行的质量。什么因素能让这次公路旅行为全家人带来无可争议的成功？你会发现很难找到可以给出明确答案的衡量标准。

当然，这并不意味着我们不应该使用现有的工具和衡量标准来分析和改进质量。它只是意味着我们需要对质量衡量所告诉我们的结果内容有更广泛的理解，并知道如何使用这些质量信息。

“质量”的定义为我们提供了一个大致的工作方向

如果没有对“质量”有一个清晰、共同的理解，那么最终的目标就会充满歧义。这对于像质量控制（QC）和质量保证（QA）这样复杂的话题来说尤为重要。

ISO 9000将质量定义为“一组固有特性满足要求的程度”。这意味着产品的质量在于它如何满足以“要求”形式表达的客户需求和期望。

ISO 25000为软件质量提供了更具体的定义：“在规定的条件下使用时，软件产品满足明确和隐含需求的能力”。这侧重于软件在客户环境中满足客户明确和隐含需求的能力。

结合这些观点，我们可以得出一个统一的定义：“质量是期望与产出之间的匹配程度”。

质量是主观的

只有当我们IT人员首先了解客户的需求和期望，并能够生产出我们所理解的东西时，我们才能实现质量。如果客户使用我们的软件并感到满意，这应该意味着我们成功地理解了他们并生产出了他们想要的东西。

正因为质量是非常主观的，所以科学界在衡量和量化质量方面一直存在困难。只有当人们觉得某个产品或服务令他们满意或帮助他们解决了问题时，他们才会认为这个产品或服务是高质量的。

既然已经接受了质量是非常主观的这一事实，那么是否还有可能完全衡量它呢？

让我们回到家庭公路旅行的例子。你是司机，有一个目的地（项目完成）和计划的停靠点（项目里程碑）。假设你完成了所有计划的停靠点并到达了目的地。那么这应该会是一次高质量的公路旅行，对吧？但事实并非如此，因为质量并不是通过到达目的地来衡量的，而是通过沿途的体验来衡量的。假设有一位乘客食物中毒了，或者你因为轮胎瘪了而困在路上好几个小时，或者原计划的一个停靠点的酒店取消了你的预订，导致你们不得不在车里睡了一晚。你还会认为这是一次高质量的公路旅行吗？

质量深受人们主观感知的影响

产品的整体质量最终是由人们的感知来决定的，而感知是无法完全衡量的。你无法进入客户的头脑，了解他们对你的产品的看法。

然而，有多种方法可以验证客户是否满意：

• 采用“自食其果”（dogfooding）的做法，即让员工成为产品的首批客户，从而让他们更深入地了解客户；
• 组织客户调查和走访小组，以获取产品的直接反馈；
• 提出质量的代理指标，如净推荐值（Net Promoter Score, NPS）、客户满意度（Customer Satisfaction Score, CSAT）和客户努力度（Customer Effort Score, CES）。

当某事物难以直接测量或测量成本高昂、甚至不可能时，就会使用代理指标。代理指标仅与预期状态相关，而不是直接测量它。

如果净推荐值（NPS）下降，可能是质量没有变化，但现在NPS是在一个不同文化的市场环境中测量的。同样，客户满意度（CSAT）和客户努力度（CES）仅与质量相关，因为人们的回答往往受到各种回答偏差（比如人们在调查中不诚实）的显著影响。可以说，通常当质量下降时，NPS、CSAT和CES也会下降，但并非总是如此。

虽然从客户的角度来看，质量无法完全衡量，但代理指标仍然具有一定的价值：它们可以作为进一步分析的信号。

继续以家庭公路旅行为例，假设你的目的地是加利福尼亚州的旧金山。旅行的质量取决于你的家人对这次旅行的感知——而且没有确定的方法来衡量他们的感知。在旅行之前，你们可能已经同意沿途参观特定的景点，并且以不超过每小时90英里的速度行驶，这些都作为旅行质量的代理指标。

如果你只依赖代理指标，你可能会认为以合理的速度行驶并在每个停靠点停留5分钟就足够了。但是，如果你的家人因为在计划的停靠点被催促得感到沮丧，或者你播放了每个人都讨厌的音乐，并且在整个旅程中忽略了他们所有的请求和抱怨，那么你的家人不太可能将这次旅行视为高质量的体验。

现在，让我们想象一下在旅行过程中收集家人的反馈。在某些时候，你要求家人对公路旅行体验的质量进行1-5分的评分。随着旅程的继续，尽管你保持在每小时90英里以下的速度，并在所有计划的观光点停留，但评分却逐渐下降。两个代理指标（速度和计划中的停靠点）告诉你你正在达到质量标准，而另一个指标（反馈评分）却告诉你并非如此。

代理指标中的值并不是为了最终确定质量，而是作为进一步分析的信号：

• 如果你驾驶时速低于90英里，但注意到一些家庭成员看起来恶心不适，你应该分析当前的情况。你是否转弯太猛？刹车是否过于突然？时速低于90英里是否仍然过快？
• 如果你发现在行驶过程中反馈分数正在下降，你应该调查原因。你的家人是否对每个观光景点的停留时间不满意？他们是否需要更多的零食？音乐是否可以改进？

内部质量指标与员工感知

到目前为止，我们一直在从客户的角度或“外部质量”来讨论质量问题。但产品也有“内部质量”，正如Martin Fowler所探讨的那样：“保持代码持续修改的难易程度。”

内部质量关乎开发的可持续性。每位工程师都曾遇到过“混乱的代码”或“糟糕的架构”，这时对代码进行任何修改都变得异常困难。工程师认为代码“不好”或“质量低”的原因有很多，但这种感知也非常主观。

没有一个通用的指标能显示代码是“好”还是“坏”，因为所有工程师的技能、对代码库的了解以及他们的观点都是不同的。当然，也存在一些“糟糕”代码的普遍迹象，比如模块或函数的圈复杂度过高。但是，在某些情况下，降低圈复杂度是不可能的，比如在构建有限状态机时。无论如何，所有“糟糕”代码的迹象仍然取决于开发团队的解读，而任何人为的解读本质上都是主观的。

例如，有人可能会认为测试覆盖率百分比是代码质量的一个好的客观指标，但在某些情况下，即使测试覆盖率百分比在下降，内部质量却可能在提高。这种情况可能发生在低价值的极不稳定的测试被从代码库中移除时，或者当一个可靠的第三方库取代了自定义构建的模块时。

与外部质量一样，所有内部质量指标也都是代理指标，它们仅与内部质量相关联。再次强调，代理指标的价值主要在于作为进一步分析的信号。

现在我们需要从司机、乘客和汽车体验的角度来谈谈这次公路旅行。作为司机，你必须观察速度表、查看地图并满足所有乘客的要求，即使这些要求是不合理的。你如此专注于外部质量（即家人对这次旅行的感受），以至于忽略了其他质量迹象。假设你的两位家庭成员坚持要你驾车穿越沙漠。你知道你的车并不适合在这种恶劣的驾驶条件下行驶，但你的乘客（即客户）想看到沙漠，所以你驶离了铺好的道路，忽略了轮胎磨损的迹象和发动机发出的奇怪声音。为了把乘客送到他们想去的地方，你甚至可能会强忍极度疲劳继续驾驶。

也许你的家人在一段时间内会感到高兴，并将这次公路旅行视为高质量，但当你专注于外部质量（即家人的感受）时，却忽视了内部质量（即车辆的性能和你的感受），这最终会导致车辆（和你）出现故障。

显然，为了满足客户而忽视内部质量也不是一个理想的方法。就像外部质量一样，内部质量也无法完全衡量。

指标是一种信号，不是有限的测量值，也不是目标

我们已经指出，内部质量和外部质量都无法完全衡量，但存在一些与之相关的代理指标。

由于相关性并不一定意味着指标值的变化总是表示质量的变化，因此代理指标的主要价值在于作为分析的信号。

如果我们发现测试覆盖率百分比在下降，我们应该分析原因。是因为我们移除了没有太多价值的冗余测试，还是因为我们开始匆忙地部署新功能而没有进行任何测试？

如果指标发生变化，我们绝不应该仅仅为了改善指标而忽略分析它们变化背后的原因。只有分析才能显示是否需要采取行动，如果需要，那么需要采取哪些行动以及在哪里采取行动。

我的一个朋友曾在一家初创公司工作，为Android平板电脑开发多媒体播放器应用程序。他们开始时使用自己的定制数据库引擎，甚至成功地用测试用例覆盖了它的40%。然而，客户不断抱怨数据有时会丢失或损坏。团队发现，这些问题大多是由于数据库引擎的问题造成的。经过广泛的研究和多次测试集成后，他们用SQLite替换了定制数据库。此后，客户不再报告问题。

改用SQLite显著提高了产品的整体质量，尽管测试覆盖率大幅下降。

但如果他们的目标不是提高质量，而是设定了达到100%测试覆盖率的目标，那么他们将面临两个选择：

1. 花数年时间为数据库编写测试，同时停止或减缓其他开发进程，这实际上会危及整个业务。
2. 无缘无故地向SQLite支付数十万美元以获取TH3（SQLite的广泛测试框架），但实际上SQLite总是使用相同的TH3框架来测试他们的发布版本。

将指标值设定为目标会导致意想不到的有害后果。当将指标设定为目标时，古德哈特定律就会发挥作用，从而产生意想不到的后果。

再回到公路旅行的话题。你从上次的经历中学到了东西，并决定为衡量公路旅行的质量设定一些指标。你制定了明确的计划，包括要游览旧金山的哪些部分，指派了专人负责整个行程的音乐，并设定了目标，即至少参观15个路边景点，并在每个景点停留至少20分钟。你已经改善了所有可衡量的指标，所以你的公路旅行无疑是“高质量”的，对吗？

很遗憾，并非如此。通过计划在旧金山进行更多的活动，你减少了整个旅行的食物预算，所以现在你的乘客对餐食选择感到不满意。在路边景点频繁且长时间的停留拖慢了你的速度，并打断了另一位乘客精心策划的音乐播放流程。而且，这次你的伴侣怀孕了，更容易晕车，并且对车内的食物气味更加敏感——他们对质量的感知发生了变化，就像顾客对质量的感知会随着时间的推移而变化一样。

质量无法完全衡量，但质量信息还是有价值的

不同的指标与产品质量的各个方面相关联，并可以提示我们分析哪里以及分析什么。

指标范围越广，分析难度越大：

• 如果你的净推荐值（NPS）在下降，你需要对你产品中的几乎所有方面进行分析：从市场变化到你的产品用户体验（UX）和设计，从性能到代码中的隐藏缺陷。
• 如果你看到客服支持请求的数量在增加，你应该与客户支持（CS）、质量保证（QA）和开发（Dev）团队讨论，以确定发生了什么问题。
• 如果你看到不稳定的测试数量在增加，你需要与平台工程师、质量保证（QA）和开发（Dev）团队会面沟通，以调查原因。
• 如果你看到从质量保证（QA）返回到开发（Dev）的反馈数量在增加，你需要与QA和Dev团队会面，分析找出原因。
• 如果你看到代码审查的平均时间在增长，你需要与开发团队一起找出原因。

每项指标变化的原因可能各不相同。仅仅测量本身并不能告诉你任何具体信息，它可能只是提示你从哪里开始分析。就像自驾游的例子——第一次旅行时大家都喜欢那里的食物，所以你们保持了同样的食物选择，但第二次旅行时，食物的满意度评分却下降了。食物满意度的下降并不一定意味着食物本身有问题，它只是表明你应该对此进行调查。进一步调查发现，你的伴侣因为怀孕而对油腻食物特别敏感，对车上其他人食物气味的抱怨让家里的其他人也玩得不那么开心了。

如何使用指标和度量

请按以下步骤操作：

1. 选择指标，开始测量并进行可视化监控

在内部软件质量方面，有很多指标可供选择进行监控。诺曼·芬顿（Norman Fenton）和詹姆斯·比曼（James Bieman）在他们的书《软件度量：一种严谨且实用的方法》（Software Metrics: A Rigorous and Practical Approach）中列出了几个。以下是一些可以考虑的指标：

1. 圈复杂度（Cyclomatic complexity）度量的是程序中源代码通过线性独立路径的数量。
2. 代码覆盖率（Code coverage）度量的是自动化测试覆盖的代码百分比。
3. 缺陷密度（Defect density）度量的是每单位代码中的缺陷数量。
4. 缺陷解决时间（Defect resolution time）是修复已报告缺陷所需的平均时间。
5. 周期时间（Cycle time）是指从开发任务开始到完成所需的时间。
6. 前置时间（Lead time）是指从初始请求到功能交付所需的总时间。
7. 从质量保证（QA）到开发（Dev）的返回次数（The number of returns from QA to Dev）是指质量保证人员发现错误后，将相关工单返回给开发团队进行修改的次数。

为了获得更详细的指导，请查看我们关于缺陷管理的文章。

我们以“从质量保证（QA）到开发（Dev）的返回次数”为例。假设我们有一个传统的流程，开发人员负责开发功能，每个功能在Jira中都有一个工单。当开发人员完成工作后，他们会将Jira工单从“开发中”状态更改为“待测试”状态，以便测试人员可以接手进行测试。如果测试人员发现缺陷，他们会记录所有必要的信息，并将工单重新返回“开发中”状态，以便开发人员可以修复发现的问题。

然后，我们决定监控任务从QA返回到Dev的次数，因为我们知道任何发现的缺陷都会拖慢开发进度，而我们确实希望开发人员在将功能传递给测试人员之前确保质量。我们决定“从QA返回到Dev的工单数量”与质量之间存在某种相关性。我们认为，当测试人员开始将更多工单返回给开发人员时，这是一个很好的信号，提示我们需要分析当前情况背后的原因。

为了开始监控这个指标，我们需要将其显示出来。Jira允许我们通过JQL（Jira查询语言）、自定义字段和自动化来实现这一点。基本上，你将看到在特定时间段内（例如一周）工单从QA返回到Dev的次数。

1. 应用休哈特控制图分析度量结果

休哈特控制图（Shewhart control charts）是统计过程控制中用于监控过程随时间变化情况的工具。休哈特控制图有助于你区分正常波动（随机波动）和真正问题（表明存在错误的信号）。使用休哈特控制图，你可以更容易地理解过程是否处于受控状态，或者是否存在需要注意的波动。休哈特控制图之所以有用，是因为每个工作项都是不同的，指标值可能会自然产生一些波动。当发生自然波动时，无需进行分析或采取其他行动。

将休哈特控制图应用于跟踪“QA将任务返回给Dev的次数”的指标非常简单：

1. 获取每周QA将每个Jira工单返回给Dev的次数

2. 计算统计数据：

• 平均值（Mean）：每周返回次数的平均值
• 范围（Range）：数据集中返回次数的最高值与最低值之差
• 标准差（Standard deviation）：与平均值相比的变异量或离散程度

1. 创建控制图：

• X轴：周
• Y轴：从QA返回给Dev的次数
• 中心线（CL）：返回次数的平均值
• 控制限：计算并绘制上控制限（UCL）和下控制限（LCL）。通常，这些控制限设置在平均值上下三个标准差的位置。

1. 绘制数据：对于每一周，在图表上绘制返回次数

2. 分析图表并查找表明存在问题的模式或趋势：

• 超出控制限的点表明存在潜在问题，需要进一步分析
• 连续的点位于中心线之上或之下，表明过程发生了变化，这也可能需要进一步分析

休哈特控制图有助于我们过滤掉指标值中统计上不显著的变化，从而让我们更好地了解所监控的指标是否在提示我们对潜在问题进行分析。因此，基于上述图表，我们想要调查为什么在第6周返回给Dev的任务突然减少，而在第7-8周激增，之后才恢复到平均水平。乍一看，你可能会认为第6周是一个很好的一周。但实际情况可能是第6周有一半的QA团队在休假，所以那一周返回给开发的任务较少，而第7和第8周的数据激增是因为团队在赶工。

1. 检测到激增或下降时，需要分析原因

如果我们观察到统计上显著的激增或下降，我们需要分析其原因。

原因总是因过程、人员、产品、组织结构和企业文化等因素的不同而有所不同，这些因素共同构成了一个独特的分析背景。

从QA返回给Dev的次数增加可能归因于多种原因，如：

1. 雇佣了一名新的熟练测试人员，他开始发现更多的错误。在这种情况下，无需改变什么，因为开发人员认为这是正常的，并开始更加关注质量和测试工作。即使这个指标上升，最终质量也会提高。

2. 管理层引入了针对QA寻找错误的KPI（关键绩效指标），导致即使是微小的问题也被视为缺陷，并将工单发回给开发部门。这样一来，虽然这个指标上升了，但质量可能反而会下降，同时开发人员和QA之间的关系也受到了影响。解决方案是取消这些KPI。

3. 裁员对开发团队造成了沉重打击：最有经验、因此薪酬也最高的开发人员被解雇，导致质量下降。分析表明，QA人员确实开始发现代码中更多的真实缺陷。除了等待剩余的开发人员学习或公司意识到自己的错误并聘请更有经验的开发人员之外，没有其他解决方案。

4. 新任经理开始给开发团队设定最后期限，导致他们偷工减料，急于将工单推给QA。分析表明，QA人员确实开始发现真实缺陷，但唯一的解决方案是告知新经理他正在对产品的质量造成损害。

5. 公司被更大的公司收购，被迫改变其工作方式。以前，QA人员会直接与开发人员交谈并立即一起修复错误，因此工单很少从QA传回开发部门。现在，QA人员被迫在开发完成后才开始他们的工作，导致更多工单被传回。质量保持不变，但延误风险增加。

6. 定期重新评估质量指标

正如我们所认可的，不同的指标仅与产品质量的各个方面相关，并且只能提示我们分析哪里和分析什么。有时，这种相关性可能会消失。

例如，一家银行可能决定逐渐用Java构建的新系统替换旧的Cobol代码库，该代码库具有80%的测试覆盖率。团队同意仅通过自动化测试来全面覆盖核心功能，这意味着整个重构项目将不断显示出测试覆盖率指标的总体下降。在这种情况下，没有必要不断分析测试覆盖率下降趋势背后的原因。在重构完成之前忽略此指标将是完全合理的。

重新评估指标的经验法则是简单的：如果在几次分析后，你发现指标变化与产品质量之间没有相关性，请考虑暂停对该指标的监控或用另一个指标替换它。

停止度量质量指标，开始将其仅作为信号使用

请记住，质量不是绝对可测量的。你可以为家人规划一次完美的公路旅行，完成每一个里程碑，到达预定的目的地，但最终还是可能整车都是不满意的乘客。

如果你所有的指标都显示“良好”的表现，但你的员工却在逃离公司（乘客在公路旅行中纷纷下车），那你肯定做错了什么。如果你所有的指标都显示“良好”的表现，但你的客户却选择了竞争对手的产品（家人选择了其他的度假方式），那你也做错了什么。

质量指标只能作为分析原因和改进流程的参考信号。要接受质量固有的主观性，更明智地使用指标，并采用全面质量管理（TQM）。