初级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类问题是最影响测试工做开展的：一、出现严重错误形成应用程序核心功能不可用；二、核心功能出现明显的错误，或者根本没实现。仔细看看这不就是“Bug严重性”里面1-Block和2-Major的定义么，是否是咱们只要使用“Bug严重性”这个概念，就足够了，根本不须要初级Bug这样的新概念。

总结一下这两年在“初级Bug”上的工做，我以为初级Bug在概念设计上是挺好的，可是在逻辑设计上存在较大的缺陷，由于始终没法准确断定“很容易发现”的具体逻辑，每一个人理解都不一样；而引出初级Bug的原始需求，其实和Bug严重性的概念也是很吻合的，因此建议你们根据本身的须要，选择是否使用初级Bug的度量分析。Bug严重性这种经典的Bug概念，其实仍是很靠谱的。