所謂的“背鍋”場景？
線上出了問題，首先第一想到的是測試人員沒測好，進而出現了以下追責的對話：
1、為什么這么淺顯的bug沒發現？
2、這個bug這么嚴重，你怎么不提出來呢？
我提了的，但XX說不影響不改/XX說不影響延期了……
那為什么你沒找我確認？
3、這么嚴重的bug，你都沒發現？
無意間出現過，但后面無法復現，就沒提……
4、這個兼容性問題怎么沒發現，沒測試嗎？
需求沒說要做瀏覽器兼容，且時間不夠。
那為什么你報告里面怎么沒有寫出來？
... ...
如何避免“背鍋”？
1、過硬的專業技能--讓自己具備不可替代性
——必備的測試技能
必備的測試技能包括測試流程、bug管理流程、計划/用例/報告編寫、linux、數據庫、計算機網絡知識、相關測試工具使用等；並學會定位問題、分析問題
——測試童鞋要比產品懂開發
盡可能了解開發代碼實現邏輯，可以先從項目環境、項目的數據庫表結構、接口了解；欲速不達，后期，可以學習一門編程語言進階自動化測試；
可以提要求給開發團隊，要他們花幾個小時講解下代碼設計及結構，但可能開發會拒絕“沒必要講，講了你們也聽不懂”，這個時候就需要你們測試負責人說話有分量、不講不行；
不排除開發講的比較空洞，我們也難以理解，所以最好自行整理一些問題問他，例如可以問開發對於一些異常情況如何處理，這樣有益於測試團隊更好地設計測試用例，同時也可把一些需求不清楚的在開發過程中討論清楚，不需等到提測再做確認
——測試童鞋要比開發懂產品
了解產品業務的每個實現細節，任何模棱兩可的都必須跟產品得到唯一確認，這樣我們在跟開發溝通的時候才能更好做到有理有據；最好是保證開發、測試、產品三方的理解一致
2、推動良好的流程管理
——項目開發流程
了解整體項目開發流程，測試負責人要及時溝通項目負責人推動項目開發周期，主要一個是提前避免測試時間被開發周期、產品頻繁改需求而壓縮
任何需求的變更都必須有文檔歸檔，並確保測試、開發理解一致
——測試流程
熟悉測試流程，除了個人能力提升之外，對於測試團隊的能力不一，測試負責人最好組織對於用例進行評審，確保用例覆蓋完整性；
進行預測環節（避免開發不自測），預測不通過直接打回開發修改，這樣不需浪費多余的測試成本；
且測試過程測試人員需做好測試歸檔包括測試用例，測試報告，bug等
——bug管理流程
要催着開發改bug，如果發現提交的bug2天都沒改，直接在項目群@開發提醒；
開發修改bug狀態時最好要開發添加備注，這樣有利於測試人員的bug跟進，特別是對於拒絕bug、延期bug、無法重現bug要清楚怎么跟進；
影響上線的bug一定要整理給測試/項目負責人進行拍板確認，除了在每天的工作匯報中提及；最終的測試報告也必須整理到位
——提測發布流程
避免開發頻繁提交測試版本，等每一輪測試完畢才接收提測任務
3、必要的個人素質
——責任心，時刻以解決問題為第一要務
測試案例未覆蓋完整，那只能測試自己背鍋了；
測試案例有覆蓋，但是測試步驟非常規或環境原因未測試到，這里的鍋可以嘗試甩出去，這里需要有一個說話有分量的測試老大，說明這種測試情況難以預料，但會總結反思到下一次的版本測試中；
不是案例覆蓋問題，盡可能配合開發復現測試，不是自己的問題不主動攻擊開發組或產品
——溝通能力
溝通時把問題梳理好,然后再闡述問題；
凡事跟產品、開發口頭溝通確認的事情，必須QQ溝通或郵件留存證據；
測試人員每天發日報時及時匯報項目風險（阻斷問題、測試難點、與開發溝通難點等）給測試負責人/項目負責人，如果測試負責人/項目負責人沒有反應，那可能他沒看到，一定要當面溝通確認；
做好以上幾個方面，相信“鍋”就離你遠了，如果還甩不開“鍋”，那估計只能辭職了~~~
~~更多關於“背鍋”的經歷及“甩鍋”的建議歡迎大家留言，也歡迎右上角加群討論~~