从缺陷率到质效工作的本质 | IDCF

DevOps

共 3028字,需浏览 7分钟

 ·

2021-08-06 02:17

来源:圆小豆的美梦工场
作者:于晓南

讨论来自一个社区朋友。


一、缺陷率迷思



1.1 千行代码缺陷率被废弃

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

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

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

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

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

1.2 缺陷率无法体现软件质量

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

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

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

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


二、质效管理投资回报



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

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

  • 第一,从度量引导团队改进的意义角度来看:指标数量绝对值 < 指标的环比(无任何时间间隔,连续周期内的变化),应更多关注团队指标的变化趋势,以及思考是什么原因引起的变化,该如何改进;
  • 第二,团队内的任何投资,都需要考虑投入产出比 ROI,为了得到结果而付出巨大的代价,本身就是一种失效。尤其当资源被投入到“质效提升或管理”这类成本高见效慢的活动时,考虑是否经济尤为重要。
2.2 质效管理效率金字塔
为了获得更高的投资回报,不得不思考团队可能采取的投资和收益之间的关系,以及可能的影响因素:成本、反馈周期、效率等互相制约的程度。
(质效管理效率金字塔)
在软件研发活动中,有些事属于决定做什么和怎么做的定义范畴,如需求方案、技术架构、测试策略等;而有些事情属于落地实施范畴,如:工序拆解和研发、测试和运维。
当决定做研发治理时,在不同层次发力,所需成本、见效周期/观察期、治理效果也不尽相同。
  • 在定义阶段发力,成本低、见效期长,但治理效果最好,问题根因也往往会追溯到此;
  • 在实施阶段发力,成本高、见效期短,但治理效率偏低,数据好看但治标不治本。
因此,当我们追求不同的提升或治理目标时,所采取的策略也不尽相同。
假设团队处在新组建期,软件也处在MVP或0-1阶段,此时从底层思考比较好,在做前把问题定义清楚,架构和策略都想清楚,定义好后续实施阶段的各种门禁和标准,会为后续研发过程的顺利进行打造良好的基础。
假设团队较大,处于稳定期,软件也处在增强和维护期,软件的质量反馈出团队的潜在问题较多,此时比较短平快的方式是先抓实施层面,让团队快速看到效果,从而建立信心。
通过实施层面反馈的问题,进一步根因分析,可能会发现在定义阶段需要进行测试策略的重塑。在团队调整的接受度和灵活性都较好时,再进行底层的改造,持续的观察和改进,就比较容易看到效果。

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



3.1 系统是有机整体
系统是若干部分相互联系、相互作用,形成的具有某些功能的整体。系统动力学认为系统中的因、果回馈关系环环相扣,系统结构决定系统功能。举个例子,“三体”即为一个系统,在这个系统中,三个天体间的万有引力相互影响,相互制约,对外呈现一个动态系统。
在系统思考中,是以开了挂的全局眼光审视整个系统,而不仅仅是寻求局部最优解。雪崩时,没有一片雪花是无辜的,也没有一片雪花能够幸免。系统整体功能不好,牵涉其中的每个人都是受害者,也都是加害者。
因此在讨论系统时,我们既要研究系统中的各个组成元素,又要各元素之间相互影响的关系。
3.2 系统思考看待系统问题
为了更好地说明质效工作需要系统的看待问题,我们举一个常见的例子。在质量领域,有一个老生常谈的问题:自动化测试的投入产出比。由此衍生更多的问题:自动化测试难开展、难维护、难持续。以往在看待这个问题时,可能的思路是:测试人员的自动化能力较低,或者时间紧任务急没资源。
在采用系统思考看待这个问题时,就不会只是盯着测试人员做改进,而是思考整个研发系统在自动化测试上的瓶颈所在,追求的也是整个研发系统在自动化测试上面的投资回报率。
现在来推演一下,当要做决策时,我们追求高投资回报。而投资回报取决于成本和收益,成本越高投资回报率越低。那么,都有哪些因素影响自动化测试的成本呢? 
影响自动化测试成本的因素:
  • 软件本身的可测性:当软件可测性较低时,自动化成本就会飞升,甚至根本不具备可自动化的条件。而这个因素的可控性受制于软件的架构设计,在软件成熟期不具备可改进的灵活性。因此建议在做架构设计时就充分考虑软件可测性,否则后续的自动化测试会难以开展。
  • 人员能力:这里不仅仅指自动化测试的编码能力,更要求测试人员具备一定的测试设计能力。能够充分理解测试分层,不同层的测试服务于什么目标,解决什么问题,以及测试的框架选型等能力。
  • 资源配置:指团队的研发节奏,能否有余力进行充分的自动化测试。
  • 环境依赖:自动化测试如果不能持续运行,就会失去尽早暴露缺陷的时机,而持续运行依赖于能排除干扰的稳定环境。
  • 工具链割裂:指团队的工具链体系是否支持自动化测试持续集成,或者不同层级的自动化测试工具是否具备一致性。这在一定程度上影响自动化测试的可维护性。
3.3 质效工作的本质
基于以上的讨论,当思考如何提升自动化测试投资回报率时,我们就有了更多可能的改进方向。抽象一下,当思考质效工作本身时,我们需要打造的是一个高效高响应的系统。系统中包含各种元素:干系人、策略、实践、流程、资源、工具……各个元素之间又相互影响,相互制约。当需要作出决策时,充分分析系统中的各元素及其之间的关系,有助于我们得出全局优化方案。
下图为系统中涉及的元素集合:
接下来选取观察元素,思考相互关系,有机的组建一个系统。一个典型的系统思考应用就是冰玉老师的《一页纸测试策略》,如图:
基于这样一个决策系统,我们就很容易对齐质量领域下的预期和优先级,从而更好的促使团队进行改进。
帮助团队设计和实施一个高效的、高响应力的质效系统,正是质效管理者的价值体现。
IDCF DevOps黑客马拉松,独创端到端DevOps体验,精益创业+敏捷开发+DevOps流水线的完美结合,2021年仅有的3场公开课,数千人参与并一致五星推荐的金牌训练营,追求卓越的你一定不能错过!
9月11-12日,上海站,企业组队参赛&个人参赛均可,一年等一回,错过等一年,赶紧上车~👇


浏览 41
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报