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