从缺陷率到质效工作本质

打造高效高响应系统

讨论来自一个社区朋友。

小A:“晓南老师,我带着问题来了。通常测试报告中【缺陷率】这个指标,我们有没有参考的指标,比如某个模块缺陷率为多少合适,还是说这个模块跟以往的build进行环比呢?”

晓南:“横向对比指标绝对值没啥太大意义,变化趋势比较有意义,所以推荐跟这个模块历史数据对比。因为不同模块业务不同,复杂度也不同。”

小A:“也就是说,第一个版本的缺陷率拿出来,跟其他项目进行比较的结果没有实际的参考意义;我也更加认同看趋势,做环比。”

晓南:“是的,环比更有意义,横向对比基本没啥意义。或者这么说吧,横向比较只能定基线值,最差不能低于多少,至于达标后的各自高低,就没有可比性了。”

小A:“这句话好像解决了我的疑惑。”

晓南:“嗯,不能说绝对没意义,如果有一点意义的话,那就是定基准了。”

小A:“原来是有点动摇的想法,现在更加清楚了;通常来说这个基线值如何定制,是有行业的规范还是公司内部的标准?我好像查不到这方面的资料,只有CMMI的一个千行代码标准。”

晓南:“没有行业规范,各个公司可能不太一样,根据自己的研发能力定基线就行了。我们可以选取研发胜任力相对平均的团队值作为基线参考。”

小A:“听君一席话,胜读十年书。”

缺陷率迷思

千行代码缺陷率被废弃

千行代码缺陷率 = Bug数量 / 千行代码数

这是一个经典指标,以前在研发侧经常用来衡量代码质量,近年被逐渐弃用。

原因是这个指标有负面的引导,似乎不鼓励写高质量的简洁代码,而稀释代码或造轮子则能带来比较好看的数据,这与指标设置的初衷“提升代码质量”相悖。

因此,该指标不建议横向比较,不建议作为绩效指标。但可以作为代码质量指导基线,或作为工程师的自我修养,用于自我评估和改进。

附上在CMMI里对千行代码缺陷率的标准,不难看出缺陷率还是以一个满足该等级的基线值存在的,也就是说它不能用来衡量代码质量有多好,但可以用来衡量代码质量最差不能低于什么水平。

缺陷率无法体现软件质量

缺陷率 = 失败的用例数 / 执行的用例总数

从字面意义上理解,这个指标看着像是衡量软件质量的。但放入研发体系内思考,通常在不同版本间,执行的用例总数是变化的,失败的用例数也取决于用例执行者的判断,而失败的用例又不一定会以缺陷的形式来跟踪。所以这个指标很难有确定的标准,那么它还是有意义的吗?

我认为是有意义的,意义在于它揭示了测试设计的质量,即经过设计的测试用例能否有效发现缺陷。 从这个维度上讲,这个指标恐怕叫“用例有效率”更恰当一点。

不管是千行代码缺陷率,还是测试统计的缺陷率,统计时难免会陷入数据的迷思。片面追求数据好看,对团队的副作用很大,结果可能是既不经济、也没成效,平白做了很多无用功。思考质效工作如何经济又高效,有助于避开局部优化的泥沼。

质效管理投资回报

不是指标的锅,而是思路偏差

由上面的讨论容易得出以下结论:

第一,从度量引导团队改进的意义角度来看:指标数量绝对值 < 指标的环比(无任何时间间隔,连续周期内的变化),应更多关注团队指标的变化趋势,以及思考是什么原因引起的变化,该如何改进;

第二,团队内的任何投资,都需要考虑投入产出比 ROI,为了得到结果而付出巨大的代价,本身就是一种失效。 尤其当资源被投入到“质效提升或管理”这类成本高见效慢的活动时,考虑是否经济尤为重要。

质效管理效率金字塔

为了获得更高的投资回报,不得不思考团队可能采取的投资和收益之间的关系,以及可能的影响因素:成本、反馈周期、效率等互相制约的程度。

在软件研发活动中,有些事属于决定做什么和怎么做的定义范畴,如需求方案、技术架构、测试策略等;而有些事情属于落地实施范畴,如:工序拆解和研发、测试和运维。

当决定做研发治理时,在不同层次发力,所需成本、见效周期/观察期、治理效果也不尽相同。

  • 在定义阶段发力,成本低、见效期长,但治理效果最好,问题根因也往往会追溯到此
  • 在实施阶段发力,成本高、见效期短,但治理效率偏低,数据好看但治标不治本

因此,当我们追求不同的提升或治理目标时,所采取的策略也应做不同的组合。

假设团队处在新组建期,软件也处在MVP或0-1阶段,此时从底层思考比较好,在做前把问题定义清楚,架构和策略都想清楚,定义好后续实施阶段的各种门禁和标准,会为后续研发过程的顺利进行打造良好的基础。

假设团队较大,处于稳定期,软件也处在增强和维护期,软件的质量反馈出团队的潜在问题较多,此时比较短平快的方式是先抓实施层面,让团队快速看到效果,从而建立信心。通过实施层面反馈的问题,进一步根因分析,可能会发现在定义阶段需要进行测试策略的重塑。在团队调整的接受度和灵活性都较好时,再进行底层的改造,持续的观察和改进,就比较容易看到效果。

质效工作本质是打造高效高响应系统

系统是有机整体

系统是若干部分相互联系、相互作用,形成的具有某些功能的整体。系统动力学认为系统中的因、果回馈关系环环相扣,系统结构决定系统功能。 举个例子,“三体”即为一个系统,在这个系统中,三个天体间的万有引力相互影响,相互制约,对外呈现一个动态系统。

在系统思考中,是以开了挂的全局眼光审视整个系统,而不仅仅是寻求局部最优解。雪崩时,没有一片雪花是无辜的,也没有一片雪花能够幸免。系统整体功能不好,牵涉其中的每个人都是受害者,也都是加害者。

因此在讨论系统时,我们既要研究系统中的各个组成元素,又要各元素之间相互影响的关系。

系统思考看待系统问题

为了更好的说明质效工作需要系统的看待问题,我们举一个常见的例子。在质量领域,有一个老生常谈的问题:自动化测试的投入产出比。由此衍生更多的问题:自动化测试难开展、难维护、难持续。以往在看待这个问题时,可能的思路是:测试人员的自动化能力较低,或者时间紧任务急没资源。

在采用系统思考看待这个问题时,就不会只是盯着测试人员做改进,而是思考整个研发系统在自动化测试上的瓶颈所在,追求的也是整个研发系统在自动化测试上面的投资回报率。

现在来推演一下,当要做决策时,我们追求高投资回报。而投资回报取决于成本和收益,成本越高投资回报率越低。那么,都有哪些因素影响自动化测试的成本呢?

影响自动化测试成本的因素:

1. 软件本身的可测性: 当软件可测性较低时,自动化成本就会飞升,甚至根本不具备可自动化的条件。而这个因素的可控性受制于软件的架构设计,在软件成熟期不具备可改进的灵活性。因此建议在做架构设计时就充分考虑软件可测性,否则后续的自动化测试会难以开展。

2. 人员能力: 这里不仅仅指自动化测试的编码能力,更要求测试人员具备一定的测试设计能力。能够充分理解测试分层,不同层的测试服务于什么目标,解决什么问题,以及测试的框架选型等能力。

3. 资源配置: 指团队的研发节奏,能否有余力进行充分的自动化测试。

4. 环境依赖: 自动化测试如果不能持续运行,就会失去尽早暴露缺陷的时机,而持续运行依赖于能排除干扰的稳定环境。

5. 工具链割裂: 指团队的工具链体系是否支持自动化测试持续集成,或者不同层级的自动化测试工具是否具备一致性。这在一定程度上影响自动化测试的可维护性。

质效工作的本质

基于以上的讨论,当思考如何提升自动化测试投资回报率时,我们就有了更多可能的改进方向。抽象一下,当思考质效工作本身时,我们需要打造的是一个高效高响应的系统。 系统中包含各种元素:干系人、策略、实践、流程、资源、工具……各个元素之间又相互影响,相互制约。当需要作出决策时,充分分析系统中的各元素及其之间的关系,有助于我们得出全局优化方案。

下图为系统中涉及的元素集合:

接下来选取观察元素,思考相互关系,有机的组建一个系统。一个典型的系统思考应用就是冰玉老师的《一页纸测试策略》,如图:

基于这样一个决策系统,我们就很容易对齐质量领域下的预期和优先级,从而更好的促使团队进行改进。

而帮助团队设计和实施一个高效的、高响应力的质效系统,正是质效管理者的价值体现。

推荐阅读:

  1. 《全生命周期的质量度量》
  2. 《全生命周期的质量度量之定量分析》
  3. 《全生命周期的质量度量之定性分析》
  4. 《全生命周期的质量度量之全局优化》
  5. 《测试左移:需求相关的质量保障》
  6. 《验收标准到底是不是测试用例?》