质量管理:层层卡点,一次把事情做对

今天我们来聊一聊质量管理的话题。

说到质量,很多人会说:“工期太紧了,能按期提测就不错了,Bug 多一点也正常。质量好不好?不好说。如何提升?不知道,QA 会保证的呀。”

我见过的大部分程序员,对自己的代码质量要求还是很高的。不过但是,一旦遇到赶工压力,尤其是在 Deadline 之前,就很可能会把完成度很低的代码交出去,心想“反正有人给我检查,到时候再说吧”。但是,这个时候,这些代码就好比是一台“行走的 Bug 制造机”,后患无穷。

我曾经在一个技术债特别严重的部门中,面向各级程序员做过一轮抽样的访谈调研。调研的结果是,程序员们只有 27.2% 的时间在做真正产生价值的编码工作。但是,他们会花 20.7% 的时间,进行需求质量和代码质量问题所引发的 Bug 修复、返工和紧急上线工作。

质量成本分为两类:一类是事前防止失败的一致性成本;一类是事后处理失败的非一致性成本,包括内部 Bug 引发的返工成本,以及外部 Bug 导致的用户侧成本。

近些年来,越来越多的公司在严格控制测试人员的比例,鼓励开发人员通过各类技术手段从上游保障质量,就是因为越发地认识到:事后检查处理的代价其实是最高的。

实际上,质量是规划、设计、建造出来的,不是检查出来的。预防高于检查,预防错误的成本通常比在检查中发现并纠正错误的成本低得多。

我们都知道,一次性把事情做对的成本是最低的。而一次性把事情做对就意味着,我们要有意识地提升预防类工作的占比,从根本上降低内部 Bug 率和外部 Bug 率。在这个质量改进的过程中,开发人员是绝对的关键力量,而非测试人员。

那么

文章出处登录后可见!

已经登录?立即刷新

共计人评分,平均

到目前为止还没有投票!成为第一位评论此文章。

(0)
扎眼的阳光的头像扎眼的阳光普通用户
上一篇 2023年12月8日
下一篇 2023年12月8日

相关推荐