測試人員怎么避免背黑鍋？

　　作為一個“質量保障”的角色，這個問題肯定會遇到，那么我就淺談一下自己的看法吧。

　　談到這個話題，也許很多人下意識會想到如何“甩鍋”，想着如何把責任撇清。其實就我個人經歷而言，這個方法雖然必不可少，但用的時候需慎之又慎，而且切不可常用。

因為一旦出現了質量事故，無論解釋的多么天花亂墜，都於事無補，反而容易讓人覺得你這個人不可信、不可交。說的越多，越讓領導反感，覺得你在找借口，沒責任心！

　　如果真這么干了，那方向可能就錯了。

　　我個人覺得可以從下面這七方面來考慮：

1. 測試前進行充分溝通，測試范圍和風險
   1. 跟開發詳細確認需求，確認的時候注意方法，比如對方講完了之后重復對方的意思來確認，回頭還可以用郵件的方式讓對方再次確認。
   2. 有郵件的方式把測試范圍發送項目干系人。一方面讓收件人確認自己的理解是否正確，一方面收件人也會在發現信息錯誤時進行修正。
   3. 把風險告知測試經理（或者項目經理），包括質量風險和進度風險。　　
2. 版本發布后進行冒煙測試
   1. 確認版本是否具有可測性，這點很重要。
   2. 避免出現因為版本問題導致的測試延期--這個鍋不能背。
   3. 如果版本質量下降，影響測試，應該立即匯報，並將版本駁回，讓開發重新打包。　　
3. 測試執行過程中遇到影響進度的問題立即上報
   1. 一般性的bug是無所謂的，但是一旦出現致命或者嚴重bug，並且會（或可能會）導致測試無法進行的問題，應立即上報，避免信息不對稱。
   2. 如果遇到問題不上報，最后即使你“出色”的完成了測試任務，在領導心中，你的工作也是沒有做到位的。　　
4. 測試報告中提供有說服力的數據
   1. 測試報告避免華而不實。要有足夠說服力的數據來支撐自己的測試結論。比如說認為這個版本不能上線，那可以列舉出O/C圖，列舉出缺陷狀態-嚴重性透視圖，有時候還要加一些自己的分析，比如這個版本bug井噴，原因是什么，這些原因是否還可能導致其他方面的風險等等。
5. 盡可能把發現的問題全部記錄在案
   1. 很多時候，我們會覺得發現了問題告訴研發就可以了，理所當然的認為他們會修改的。----這種做法不是不可以，但得分公司情況、也得分時機。比如在項目需要緊急上線時可以這么做，避免走流程的時間浪費。但是我們不可以太相信人的記憶力---特別是我們這一行，長期加班，那么效率和精神狀態就比較差，可能導致他忘了，或者改bug改的不徹底，或者這個bug這一次改了，過一段時間又發現，或者過一段時間我們想找一下這個bug都找不到。。。。　　
   2. 總之，如果哪天上線以后暴露出了我們發現過的問題，我們要有證據、要有話說。
6. 不要過於執著成為“守門員”
   1. 很多公司里面，測試人員執著的想要“話語權”，似乎這樣才能體現測試人員的價值。--我覺得這不可取。
   2. 說白了，我們就是一群尋找信息的人，一群為項目提供信息的人。我們是服務者，而不是控制者，如果混淆了這個概念，開發和測試的關系一定不融洽，一個不融洽的團隊，我很難相信它會產出高質量的產品。----當然我說的不融洽並不是指團隊里都是一群老好人，沒有爭執。　　
7. 小心成為過程改進小組
   1. 很多人想通過一些過程改進來推進質量的提升。想法沒錯，但是做起來常常有各種問題。
   2. 最大的問題就是想法沒錯，甚至很好，但就是推進不下去。
   3. 強行推進的時候，甚至可能會有人拖后腿，通過一些惡心的手段，讓你看起來很傻X。
   4. 遇到這個情況，要么找項目經理或者產品經理來推進改革，要么獲得高層的支持。否則。。。

 

 

 　　　　　　 (0 0)
 +------oOO---(_)------------+
 | 　　　 　　　　　　　　 　 |
 |             『歡迎關注』     　 |
 | 　  　　張老師的小黑屋　    |
 +--------------------oOO-----+
　　　　　　|__|__|
　　　　　　  ||  ||
　　　　　 ooO   Ooo