质量度量之全局优化

度量这回事,求仁得仁呗~

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

局部优化伤害全局利益

这不是Bug,这是特性

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

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

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

一个愿报,一个愿改

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

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

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

为了恰饭,放弃操守

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

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

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

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

质量是团队整体的能力

陈述两种观点,你认同哪一种呢?

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

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

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

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

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

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

全局优化助力团队提升

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

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

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

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

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