測試管理之績效考核

?

編寫背景：

工作所在的部門啟用了新的績效考核制度，也開始了我參與對測試人員的工作進行績效考核這一管理活動，第一次的考核結果讓我有很多的感想，因此今天把它記錄下來，也許突然有一天回頭看這一感想，又會是另外一份心情。

?

?

思考：給測試人員進行績效考核的目的是什么？

經過思考，我總結的答案是：

1、? 為了了解工作情況，如：工作進度、工作狀態。

2、? 對每個人的工作進行評比，夸獎好的，批評差的。這個看起來有點像在學校上學時候的考試。

?

思考：有了這樣的績效考核目的，要用什么樣的方式、方法去實現呢？

怎么樣的績效考核方式是最有效的呢？

對于現在的我，在現在這個小公司要想做好這個績效考核，真是要好好思考。

1、? 不同的工種，不能用同一種考核方式。如：測試人員的考核方式就不能和開發人員的考核方式相同。

2、? 不同工種的考核結果是沒有可比性的。如：測試人員的考核結果和開發人員的考核結果進行對比是沒有意義的。

以上這兩點不知道我的領導是否認同，還需要等到下一次考核的時候和他溝通溝通。

?

這是工作以來，第一次站在一個管理角色去思考、去做績效考核這個工作。這第一次的考核工作讓我不知道用什么語言來描述我的感受。

考核的結果是：測試組整體的分數都比開發的低，從排名和等級劃分上可以說是包尾了。從分數上看，我的第一感覺是：難受。第二感覺是：生氣。在和領導進行一系列溝通后，在回家的路上一直在思考、分析著這個結果，問題出在那里呢？問題出在那里呢？？？？？冷靜的思考后，自己安慰自己，原因應該是這些吧：

1、? 這次開發人員和測試人員使用的工作考核方式是同一種考核方式。

2、? 這次把開發人員的考核分數拿來和測試人員的進行排名對比。

很顯然，一直這樣下去，測試人員的工作即使在怎么努力、分數超過開發人員的機率會很低很低，這樣的對比規則，對測試人員來說，很不公平。這樣的對比規則，很沒有意義。更讓我郁悶的是，面對這樣的現象，我想不到很好的解決方法，目前只能鼓勵測試人員加強自己的綜合能力，自己給自己爭氣，對我來說，在測試人員的管理工作上，無形中出現了一個困難，只能是樂觀面對了。

唉，工作種類不一樣，放在一起作對比，永遠說不清。

測試人員的工作，開發能作么？開發人員能寫好測試需求、測試計劃、測試用例、測試分析報告文檔么，先不說寫好，先說會寫么？開發人員知道怎么樣去執行測試么？知道發現 bug 應該怎么有效正確的去描述么？怎么快速有效的發現程序的問題么？能把握好整個軟件測試的質量和進度么？測試，說的簡單，真正做好沒有這么簡單。就拿黑盒測試舉例，測試項有：業務流程測試、功能測試、安全性測試、性能測試、數據測試、用戶友好性測試、配測試、兼容性測試。這些測試項所使用的測試方法、測試點，都能想全了、想到重點了么，想到了還只是第一步，真正要去執行測試的時候，測試環境的搭建、測試用例的編寫與執行、 bug 的描述以及錯誤等級的正確劃分、 bug 的回歸、用測試工具進行測試，對測試工具正確有效使用的把握，這些對開發人員來說，會做么，能做好么？測試工作也有很大的工作壓力，面對一個不熟悉的軟件，面對一個什么說明文檔都沒有的大軟件，要在最短的時間內，最有效的完成測試，要保證產品在發布后，不出現嚴重的問題，想盡一切辦法的發現嚴重問題。這種對軟件質量上的責任壓力是很重的，還有其它我就不舉例了。

開發人員的工作，測試能作么？測試能看懂開發人員的代碼么？測試能寫代碼測試開發人員的程序么？測試能明白理解開發人員是怎么開發的么？測試能明白開發人員所說的工作術語么？測試能看明白開發人員的開發成果么？開發人員的工作也有很大的壓力，要在最短的時間內編寫出質量高的代碼，實現功能，還要進行一遍又一遍的調試，需求一變，又要修改代碼，自測時，發現問題，要進行調試找原因和解決方法，容易么？不容易。測試人員發現的問題，還要去找原因要想最好的解決方法。容易么？不容易。

我很同情那些把測試和開發放在一起作對比行為的人，因為他們對這兩個工作中的其中之一理解有所欠缺從而導致這樣的結果。說了那么多，好像扯遠了。

?

最后，我得出這么個結論：這樣的績效考核方式，對測試人員來說，起不到激勵作用。如果碰到不能正確心態去理解的測試人員，反而會起反作用，很打擊工作積極性。因此領導在問我意見的時候，在不適合的說話時間、說話場合我只能說“無所謂”，心不甘情不愿的無所謂！！！！！！！！！！！！！！