如何用量化數據來激勵測試工程師？

由于軟件測試工作需要每個成員都需要有高度的責任感、全身心投入，我們就必須通過良好的管理方法和一系列激勵措施，使測試團隊保持高昂的士氣和高度的責任感。在我寫的《軟件測試方法和技術》第12章介紹了許多有效的方法，在這里主要想詳細討論具體的量化方法。
 

從度量角度看，量化數據適合團隊績效的考核，而不宜用于個人績效的考核。但是，有時為了實行一些測試改進方法、實施某些有效的策略，需要設定游戲規則，通過這些規則進行獎勵，以促進新的方法、策略的改進。這種獎勵，看作是游戲(game)的、臨時的獎勵，而不是做年終的績效考核。

對于測試，最容易進行量化的有兩個數據：測試用例(test case)和所發現的缺陷(Bug)。test case的數量、覆蓋程度（功能覆蓋率、缺陷覆蓋率）等是比較容易量化的，而Bug的度量數據更多x些，如所發現的bug數量、描述不清楚的Bug數量、不是Bug的Bug數量、遺漏的Bug數量（被客戶發現——Remedy Tickets、或在下一個版本發現——Late Discovery Bug）等。對于Bug度量的數據，最重要的兩項是所發現的bug數量和遺漏的Bug數量，前者是測試效率和設計/代碼的 質量度量，后者是測試質量（也包括設計、代碼質量，我們堅信質量不是測出來的，而是構建出來的）的度量。遺漏的Bug數量對質量度量的更有效些，但是不能及時獲得，必須在產品發布之后才能獲得。所以，為了實現測試的效率，有時必須靠“所發現的bug數量”來度量。為了更客觀度量，考慮到bug的嚴重性、技術難度、產品類型、模塊穩定性等因素影響，不是用“所發現的bug數量”，而是用“所獲得的bug value (缺陷值)”來度量，公式被定義為：

Bug_value = （P0_Bug_Number × 1.6 + P1_Bug_Number× 1.4 + P2_Bug_Number× 0.7 + P3_Bug_Number×0.3）× Wd × Ws × Wt

其中：P0_Bug_Number：致命的（fatal）缺陷數量 

P1_Bug_Number：嚴重的（critical）缺陷數量

P2_Bug_Number：一般的（major/normal）缺陷數量

P3_Bug_Number：次要的（minor）缺陷數量

Wd: 技術難度系數，如Database, Enterprise Server, Java難度系數大，發現Bug不容易，Wd可以定在1.5 – 5.0

Ws: 穩定性系數，全新模塊，Bug比較多，發現缺陷比較容易；版本越高，越穩定。Ws可以定在0.5 – 1.0， 假如以version 10.0為1.0, Version 1.0 = 1/100, Version 2.0 = 4/10, Version 2.0 = 9/100, …, , Version 8.0 = 64/100, Version 8.0 = 81/100

Wt: 產品類型系數，可根據實際情況和歷史數據來判斷。Wt也可以和Wd合并為一個系數。

原文轉自：http://www.anti-gravitydesign.com