每一段時間, 就會有人開始討論QA的performance要如何評量, 有些人會提出以下的index
- 所執行的測試個案個數
- 測試涵蓋度
這些index的缺點, 是缺乏考慮整個環境或是項目的狀況, 容易會忽略一些會影響的變量. 作者認為如果沒有根據context就來衡量個人的績效, 是一件愚蠢的事情.
例如有些狡猾的
測試人員, 可能會采取一些策略來達到你的index的標準, 但是卻危害了整個團隊的質量.舉各例子來說: 如果manager說要評量engineer每周所找到的bug數, 并且訂定每周的標準是10個bugs. 這時候會發生什么事, 每周engineers會想辦法找到10個bugs, 但是對于多找的bugs, 有些engineers可能會考慮放到下周再提報出來, 這樣才能確保下周他比較容易達到pass的criteria. 這代表bug report是無法反映實時的狀況, 很能是慢一周. 所以你有可能會誤解這時候狀況不嚴重, 導致你會因為錯誤的數據而做出不當的決策.
為什么會這樣呢? 主要是因為有些短視的人, 想要用簡單的方法, 去解決困難的問題. 可是這個人績效問題, 真的是沒有簡單的公式就可以衡量出來的. 而且有些衡量是很主觀的, 并且也外受到一些外在因素的影響, 像是所處的
工作環境, 或是使用的工具, 或是你本身的個性, 或是老板是否善于鼓勵員工...等等, 這些因素都會讓相同的人, 產生不同的結果.
另一個我常見的問題, 那是訂定不切實際的目標. 像是"找出主要的bugs", 試問你如何界定他是主要的bug? 并且主要的bug是否代表就是重要的bug呢?
Over-promise和under-deliver也是個嚴重的問題, 沒有根據自己的能力來訂出適當的目標. 另一個相關的就是, manager給所有人都是相同的pass criteria, 既然每個人的能力不同, 你就必須要給每個人設定不同的標準.
作者建議測試人員試著要和你的經理, 去
學習如何訂定SMART的衡量標準. 因為每個人能力不同, 項目環境不同, 沒有一體適用的標準. 此外也要記得align managers, product teams或是company的goal. (當然啊, 最后這點是比較爭議的, 因為你的career path不一定和公司一樣)