初级Bug率,随时受不了

一听到初级Bug这个名字,很多开发工程师都会觉得很头痛,还有那个“初级Bug率”,让人随时受不了。

初级Bug这个概念,在多数缺陷跟踪工具中,是不存在的,可以说是淘宝研发部的特色。初级Bug对应Bug的一个属性:“Bug深度”,这个属性有三个选项:1很容易发现、2正常发现、3很难发现,其中“很容易发现”的Bug就是初级Bug。深度代表了发现Bug需要的成本和技术含量,初级Bug就是那些非常明显,通过简单的操作就能发现的Bug。

从初级Bug这个概念被提出,到现在大约有2年时间。最初的时候,在一次开发经理的周会上,研发部VP提出,开发工程师必须要提高代码质量,不要一提交测试,马上就被测试工程师找出一堆很低级的Bug。“低级Bug”这个概念因此诞生了,低级Bug的占比,也从此成为各个开发团队进行考核的一个重要KPI。

接下来,缺陷跟踪工具里很快添加了“Bug深度”这个属性,测试工程师在提Bug时也开始选择。一个月后,第一份低级Bug率的报告发了出来。当时这份报告引起了很大的争议,问题的焦点是:低级Bug到底是怎么认定的,怎么才算“很容易发现”,如果是测试工程师操作的步骤,那究竟是多少“步”以内呢?还有一个要命的问题是,“低级Bug”这个概念与生俱来就有一种让人不爽的感觉,简直是一种人身攻击,带有贬义的感情色彩。

为了解决大家的疑惑,我们做了很多沟通和说明,发邮件,写沉淀,可是效果并不理想,时至今日,还有人在问我,低级Bug是怎么判断的。如果一个概念无法让别人很简单的理解,那么可能这个概念本身就是存在缺陷的。另一方面,低级Bug这个概念确实很刺耳,后来我改成了初级Bug,稍微缓和了一些,听起来没那么难听了。细心的同志会注意到这个名称的转变。

随着时间推移,开发团队对于初级Bug这个概念,慢慢没那么抵触了,但是出现了一个更棘手的问题。每次的初级Bug率的报告,会按照不同的开发组进行分组统计,比如A产品线和B产品线,会比较谁的比例更高,但是这两个产品线对初级Bug的认定,可能是不一样的。这样虽然两条线的Bug质量差不多,但是其中一条线的数据会很难看,开发工程师觉得不公平。A产品线的测试工程师,很认真的选择“Bug深度”,这样初级Bug率会“偏高”,B线的测试根本不选,或者每次都选“2正常发现”,谁也不得罪。A线的开发就会对测试吐苦水:你们干嘛这么较真啊,你看B线的测试都不选,自己人何苦为难自己人呢?

在这种“劣币驱逐良币”的效应下,A线的测试工程师慢慢也妥协了。于是很多产品线的初级Bug率,都“自动”回落到正常值以下了。这里我完全没有责怪的意思,一个制度如果推行不好,首先问责的应该是制度的设计者。当然也有部分产品线的初级Bug率较高,说明Bug质量真的是出了很大的问题,能通过这个KPI识别出来,也算是起了点作用,不过大部分产品线横向比较的意义已经失去了。

这时我们再回头看看最初,研发部VP所提出的“开发要提高代码质量”的初衷。开发把代码提交测试以后,出现2类问题是最影响测试工作开展的:1、出现严重错误造成应用程序核心功能不可用;2、核心功能出现明显的错误,或者根本没实现。仔细看看这不就是“Bug严重性”里面1-Block和2-Major的定义么,是不是我们只要使用“Bug严重性”这个概念,就足够了,根本不需要初级Bug这样的新概念。

总结一下这两年在“初级Bug”上的工作,我觉得初级Bug在概念设计上是挺好的,但是在逻辑设计上存在较大的缺陷,因为始终无法准确判定“很容易发现”的具体逻辑,每个人理解都不同;而引出初级Bug的原始需求,其实和Bug严重性的概念也是很吻合的,所以建议大家根据自己的需要,选择是否使用初级Bug的度量分析。Bug严重性这种经典的Bug概念,其实还是很靠谱的。

上一篇:nginx+gunicorn


下一篇:在 Apache Ant中设置Proxy服务器