如何用量化數(shù)據(jù)來激勵測試工程師

第第頁如何用量化數(shù)據(jù)來激勵測試工程師？如何用量化數(shù)據(jù)來激勵測試工程師？

發(fā)表于：2023-04-22來源：：點擊數(shù)：標(biāo)簽：工程師測試何用激勵量化

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

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

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

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

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）缺陷數(shù)量

P1_Bug_Number：嚴(yán)重的（critical）缺陷數(shù)量

P2_Bug_Number：一般的（major/normal）缺陷數(shù)量

P3_Bug_Number：次要的（minor）缺陷數(shù)量

Wd:技術(shù)難度系數(shù)，如Database,EnterpriseServer,Java難度系數(shù)大，發(fā)現(xiàn)Bug不容易，Wd可以定在1.5–5.0

Ws:穩(wěn)定性系數(shù)，全新模塊，Bug比較多，發(fā)現(xiàn)缺陷比較容易；版本越高，越穩(wěn)定。Ws可以定在0.5–1.0，假如以version10.0為1.0,Version1.0=1/100,Version2.0=4/10,Version2.0=9/100,…,,Version8.0=64/100,Version8.0=