一听到初级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概念，其实还是很靠谱的。
