初級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概念，其實仍是很靠譜的。