關於質量保障部（測試）人員的測試管理及KPI工作的思考與討論
大家好，首先 我是一名研發。
因為研發管理不可避免的和測試打交道，會深入到測試管理的種種利弊中，所以今天因為一個問題和測試爭論很久。
故事
故事是這樣的：今天團隊的一名新人截圖告訴我說，測試提的bug，他標記外部原因後給測試，測試又打回來，並回復「請修改狀態為已解決」。
新人就表示了不理解，因為bug的本身是因為研發中需求變更導致產生的歷史錯誤數據干擾，上線後不會有這個情況，嚴格的說也確實不應該是研發的開發bug。
但是測試缺認為，雖然你是歷史數據，但是我確實發現了問題，你標註外部原因，是對我工作的否定。
經過溝通，確認了問題的核心是，測試對BUG數量，BUG等級，BUG有效率進行了績效管理和考核，而《外部原因》這個狀態的bug不會算在有效BUG統計中。
也就是說，開發和測試對這個BUG的狀態共識並不一致。
思考
通過這個故事，我開始思考，這個認知和防守是正確的嗎，對於測試的績效管理，應該如何呢？
bug數量能代表工作努力，能力強嗎？
bug級別高能代表工作技能更強嗎？
bug有效率該怎樣定義呢？
除了bug，測試還應該從哪方便進行KPI考核呢？
定義
探討這個問題，我覺得首先要定義清楚兩個個事情：
1、BUG其實是要分兩種類型的。
即 生產BUG 和 測試BUG。
這兩個問題應該單獨管理並分開討論。很多公司對於這兩種問題從工具到認知都是分開處理的。
2、定義一個名詞《真實bug》，也就是開發完成交付後，測試拿到的研發成功他客觀真實存在的真實bug數目。
這個不等於測試提交的bug數目。
生產bug越少，測試bug越接近真實bug。
測試bug完全等於真實bug時，生產無bug。
什麼是質量保障工程師
我們再來明確下一名質量保障工程師的定義，測試人員都喜歡叫自己質量保障工程師，部門叫質量保障部，那麼顧名思義，測試 就是進行質量保障的。
而保障的質量，當然是上線的質量，而不是開發後，那是開發的事，測試能決定嗎？
所以一名合格的測試，首先要保障上線後的bug數目小於預期。上線後能夠儘可能的沒有bug。
也就是說，測試工作的究極目標，就是要上線後沒有bug，至於需求分析、用例編寫、測試、回歸，溝通，管理，這些過程，都是為了實現最終目標的手段和方法，那麼這個過程中產生的bug數目，即測試bug，還有意義嗎？什麼才是有意義的呢？
傳統kpi的參數分析
1、bug的數量和bug的級別
我認為，測試過程中的bug數目，bug等級，統統沒有任何意義。因為各個需求複雜度不同，各個需求開發人員不同，開發周期不同，開發質量不同，這些會決定真是存在的BUG總數就不同。
比如需求A ，到交付時，真實BUG數目是100個，測試測了60個，其他40個上線了，這算成功嗎？
比如需求B，到交付時，真實BUG數目是10個，測試測了10個，其他0個上線，這算失敗嗎？
結論：比較兩個分別負責需求A和B的人員 產生的bug數量和bug級別，沒有任何意義。因為你也不清楚真實bug數目，並且無法預估。
2、bug的有效率
有效率的定義應該是 bug是否是有效的，所謂有效，那其實就是 bug是否是bug，這個當然是有意義的。但是其實對於中高級以上的測試，既然提出了bug，很少是使用方式，或者執行流程造成的不是bug的無效bug，所以這兒數值，能力達到一定程度，變化並不會特別大。
另外這個值其實從統計學上，仍然具有缺陷，即數據量樣本越大，也就是越大的需求，越複雜的需求，出現無效bug的概率越高，有效率月低，所以並不能完全說明什麼。
結論：bug有效率，有一定程度的意義，kpi佔比可以較低。
應該怎麼做？
大家發現，所以一個質量保障工程師（測試），最重大的產出都不具備考核價值，那麼我們應該如何考核測試的KPI呢？
根據上文的例子，我們很容易發現，其實關鍵的問題是需求A開發完成後，他的真實BUG數目是不可預估的，高質量的開發和設計過後，充裕 的時間過後，他的真實存在的bug可能很少，甚至不存在。
相反，低級工程師、不了解業務的人員開發，時間過渡緊迫加班趕工，等諸多因素可能讓真實bug較多。
在這種情況下，我們要保障的是 儘可能的發現真實bug，儘可能的讓自己發現的bug數目接近或者等於 真實bug數目。
所以，我們為此付出的努力，工作方式，流程，才是我們考核的更重要的部分。
1生產bug預期達成比
回到最初關於 「質量保障的定義」，很簡單，我們首先要衡量的是一名合格的工程師有沒有達到保障質量的目標，即如果上文提到的《生產bug》超出預期，那麼工作其實是不合格的。
但是bug預期是一個較為抽象難以量化的東西，只能根據用例複雜度和需求複雜度等具體的需求表述，根據以往經驗和團隊能力配比，以及時間投入相關，由產品、研發、測試共同制定一個儘可能客觀的預期bug數目標準。
比如一個10人/日的需求 ，bug預期是3 ，計算預期達成比。
所以在KPI考核中，生產bug的數目可以佔到績效佔比的很大程度.
2、用例編寫
詳細的用例會覆蓋客戶的各種實用場景，保證在測試過程中儘可能的發現所有的真實bug，而優秀的用例編寫又能讓測試用最少的時間，完成測試。所以符合規範的、考慮全面的，有邏輯條例的用例編寫，是kpi考核的關鍵參數。
這條其實會和很多人認為的bug級別有關聯，有些管理者認為能夠發現高級、嚴重bug的工程師是優秀的，實際上，如果程序真實bug沒有嚴重bug，你又何談發現呢？但是不管有沒有，你的用例應該覆蓋的到嚴重bug，也能考慮到各種複雜場景，這個才是更重要的。
3、bug描述與定義
發現了BUG如何第一時間周知相應開發，如何清晰的表達清楚bug內容，如果簡介的描述出bug復現的場景。
如何總結出導致bug的真實操作原因和背景。這些是一個測試人員能力高低的重要標準。
優秀的工程師對於非必現問題的定位高效，排除無效操作，去除掉障眼法，找出真正必現的使用流程，問題的本質，大大提高了bug的解決周期。
舉個例子 初級工程師「點擊下單報錯」
高級工程師「在選擇多規格產品，有優惠的情況下，選擇下單報錯」
4、BUG生命周期跟蹤與推進
對每一個BUG的產生、經過、結果都有良好的溝通，並了解問題的真正原因，記錄歸納並協助其他團隊總結分析。
5、需求審核
作為整個研發中心的一員，在需求評審階段給出合理性建議，提出需求遺漏的問題或者邏輯錯誤或者質量風險，都是一名高級工程師必備的能力。也是有效降低後期真實bug數目。
6、測試報告
定期整理需求測試報告，分類、總結，風險預估。有效的保障整個需求能夠持續，安全順利的進行是高級工程師重要的考核方向，給開發團隊和產品團隊做kpi數據支撐以及需求總結。
7、工作效率管理
如何有設立自己工作的時間計劃、優先順序安排，以及排期後準時達成，時間預期排期的準確性等情況。
總結：
上文有些東西是不好量化的，但是不能因為不好量化，就去量化沒有意義的量化，用bug數目考核。
上文只是從有沒有好處的角度分析bug數目。並沒有說統計壞處，這個大家可能都有經驗。不提也罷。
反是保障測試中發現的bug儘可能接近 真實bug的有效手段和方式 ，是值得考核和提升的。
最後：
經過這個事，詳細的思考總結了下測試工作內容及績效管理，對自己是一個記錄和成長，也希望對大家有幫助，引起討論，更希望大家給些意見。
推薦閱讀：