质量度量之全局优化

在前文中我们讨论了软件全生命周期的质量度量，以及度量的两种方式：定性分析和定量分析。本文我们主要讨论质量能力的体现，以及由此引申出的度量范围和策略。

局部优化伤害全局利益

这不是Bug，这是特性

就一个问题是不是Bug而产生的争议。

• 测试：“这就是Bug，明显和预期结果不符。”
• 开发：“需求没说，所以没实现，这是新特性。”
• 测试：“这明显跟使用逻辑相悖，Bug都提了，你就改一下呗。”
• 开发：“提错了删掉，改是不可能改的，要做的话拿需求来。”

度量的方式：开发人员以代码引入缺陷数来衡量代码质量，测试人员以发现的缺陷数来衡量测试效率。本应合作的双方却因为度量不合理导致了利益冲突，不打才怪。

一个愿报，一个愿改

开发和测试也不是总吵架，在这个故事里就合作的很愉快。

• 测试：“这Bug在商品页和订单页都有，相似问题，我写在一个Bug里得了。”
• 开发：“别啊，这是不同的服务页面，拆开报两个Bug吧。”
• 测试：“得嘞。”
• 项目经理：“这俩Bug看上去一样啊，为啥分开报了？”
• 开发：“只是表现一样，两边都得改。”
• 项目经理：“好的。”

度量的方式：开发人员以修复缺陷数来衡量工作量，测试人员以发现缺陷数衡量测试效率。这种情况双方倒是真心合作，但是否为质量提升带来了正向效果？又有多少Bug的存在只是为了凑数？那就不得而知了。

为了恰饭，放弃操守

开发之间友好的技艺切磋。

• 小菜鸟：“大佬，你的千行代码缺陷率怎么如此之低，求赐教啊，过年要喝西北风了。”
• 老油条：“哎千行代码缺陷率怎么算？”
• 小菜鸟：“千行代码缺陷率 = Bug数量/ (代码行数/1000)”
• 老油条：“小学数学，C=A/B，想让C小应该怎么做？”
• 小菜鸟：“……我懂了，多谢前辈指点。”
• 老油条：“好说，不足为外人道也。为了恰饭放弃操守，唉，非久留之地也。”

度量的方式：开发人员以千行代码缺陷率来度量绩效。上有政策下有对策，设计失效的度量方式无异于饮鸩止渴。

在讨论度量何以失效之前，先了解一下质量能力到底是谁的能力？当我们谈到度量质量的时候到底在度量什么？度量的结果服务于谁？

质量是团队整体的能力

陈述两种观点，你认同哪一种呢？

1. 质量是质量部门或测试人员的能力，测试得好，质量自然就好，质量差是测试的责任。
2. 质量是团队整体的能力，质量改进非一朝一夕之功，需要团队全员持续不断的努力。

我们来从度量的角度解释一下两种认知的不同。

认同第一种，就会认为质量是测试部门的职责，那质量的度量应该这样设计：帮助发现更多缺陷，提升测试效率，控制逃逸到生产环境的缺陷数。在这种语境下，非测试相关的度量不在讨论范围内，如需求变更率、上线后的代码回滚数，可能更多的是项目经理或运维人员所关注的数据。

认同第二种，会认为质量是团队整体的职责，相应的，质量的度量应有遵循这样的规则：减少引入的缺陷，关注团队整体的效能提升，关注团队关键事件对整体质量能力的影响。在这种语境下，只有跟团队整体的质量或效能有关的度量，都在讨论范围内，度量的广度相当大。

乍看之下，认同第一种观点的度量方式貌似更有针对性，度量周期短，改进见效快，似乎比较理想，这也是大部分质量度量会采取的方式。然而，这样度量真的奏效吗？质量真的因为我们的度量有所提升吗？假设质量是测试人员或测试部门的能力，那换一个能力超强的测试团队来，我们的产品是不是就没有缺陷呢？显然不是，所以质量不是某个人或者某个角色的能力，而是团队整体的能力。那些产品质量有严重问题的团队，如果我们深入到整个产品研发过程中去，会发现不仅测试有问题，哪哪儿都有问题，只不过测试是最后一个阶段，问题集中暴露了而已。

所以我们达成共识，质量是团队整体的能力。在前面的三个故事中，度量之所以失效，是因为思考问题的角度是割裂的，设计指标的时候，开发的指标就是开发的指标，没有考虑这个指标的指定，对测试环节或是团队整体的影响。这样设计出来的指标，很容易看到局部的短暂优化，但对整体的质量提升弊大于利，毫无帮助。

全局优化助力团队提升

以缺陷为例，当我们以割裂的视角来设计度量时，就会选取出让团队分裂的指标“缺陷提交数”，进而会将缺陷提交数在不同团队之间进行横向比较，造成进一步的割裂。当我们以全局视角来设计度量时，不同产品间的技术复杂度和业务复杂度不同，客观条件也不同，不同团队之间的横向比较毫无意义。所以我们可以采取一些转化方法，让大家的度量可以统一，并选取有正向激励的度量方法，从而提升团队整体的质量能力。

还是以缺陷为例，以下三个阶段生动形象的体现了截然不同的管理思路：

从上到下的转变，体现了团队对个人的尊重和信任程度，就像回顾会宣誓的那样：“无论发生了什么，……，我们理解并坚信：每个人对自己的工作都已全力以赴。” 当我们真正关注到人，就不会问出“这个Bug怎么都测不出来”这样的问题。

值得思考的是，我们真正想要的是什么？是平滑的上线、顺畅的功能、良好的使用体验，还是想要报更多的缺陷？当我们想要报出更多的缺陷时，那我们也真正能得到更多的缺陷。（手动狗头）

有小伙伴又有疑问：如果不衡量缺陷数，测试的工作量怎么体现呢？毕竟老板还是喜欢看数据的。我们可以采取一些更正面的指标来体现，如：为用户节省了多少时间、避免产生了多大的经济损失、为客户节约了多少成本等，在一定条件下这些都是可以量化的，相信老板更喜欢这样的数据。以往，度量的重点都是定量分析，我们也应该逐步的做好向上管理，把度量的重心从关注数据和工具的定量分析，慢慢向关注团队能力和个人成长的定性分析转移，在这个过程中，能力和文化就会逐渐内建起来。