鏈接：https://www.zhihu.com/question/42151352/answer/106933562
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
如果軟件上線后出現了重大的Bug，產品的各個角色肯定都有壓力，這種情況下，首先需要有人來組織這個Bug的責任認定和后續改進，這個角色一般是PM，不過，對於有一些團隊，也可以由最關心質量的測試團隊來發起。如果沒人發起，建議測試團隊一定要主動地去發起這類總結，因為這個也是產品質量保證的重要環節。
線上Bug的討論一般有如下這些內容：
1、Bug的產生原因，仔細地分析Bug為什么會產生，這個環節很重要，因為這個環節弄清楚以后，責任認定就清楚了。
2、Bug的責任認定，一般來說，除了那些責任真的很清晰的Bug之外，很多Bug都是開發、測試、策划、項目經理共責的，為了團隊的團結，也沒有必要去討論哪個團隊負主要責任。
3、Bug影響范圍，分析這個Bug對於用戶造成的影響。
4、改進措施，在改進措施這一項中，可以把以后如何避免類似Bug的措施寫進去，並在任務系統建立任務，指定專門的人跟進。
那再來說下項目組實際Bug的責任認定吧：
1、如果測試時間還是比較充足，測試用例有寫，但是還是漏測的，那就是測試的責任。
2、如果測試時間不充足，測試用例有寫，但是因為時間不足而降低回歸測試范圍，導致漏測的，那一般是項目組各個角色共責的。
3、如果有開發修改了功能沒有通知測試人員，導致線上漏測的，那就是開發的責任。
4、如果策划人員在回歸測試階段還提了需求變更，在測試人員明確告知風險的情況下還堅持要上需求變更的，那就是策划的責任。
具體問題具體分析。
如果是測試同學沒有覆蓋到的場景，產品同學沒有想到的場景，開發同學代碼沒有cover的場景，那么所有人都有責任。
就我經驗來看呢。上線之后出現的問題大部分是：環境問題。
什么配置信息丟了，這個配置信息忘記配了，還有域名沖突等等。
不過，不管遇到什么問題，溝通和流程化的上線規范其實是最最關鍵的。
但是，很多互聯網公司，其實大部分不是這樣的。測試背鍋俠，好像叫的就是這么順口。
不過在我待的公司(准確的說應該是我所在的那個測試組)，我們的測試老大很厲害。很多問題都會把情況說明，比如：
1.這個問題產生的情況原因，需要測試同學了解清楚。嚴重的問題可能會領導們一起開個會，討論解決辦法。
2.環境問題，我的測試領導會主動去推研發同學，制定相關聯的流程規范，怎么盡量去避免此類問題發生。
3.不確定性問題，概率問題。會后期進行復現，可能借助的工具除了自動化測試工具。然后如果該問題大面積出現(還是概率問題)，那么會組織相關同學進行解決。
所以，測試同學應該拿出自己的觀點和態度。當然，其實最重要的還是你的領導是如何對其他團隊說明這件事情的。
我們公司的bug定責是這樣一種規范：
出現bug，那么分析bug是不是這次的測試用例沒有覆蓋到這個點。
1，如果有覆蓋到但是沒執行，那就是測試背；（這種類型導致的鍋比較沉）
2，如果沒有覆蓋到，那么會分析為什么沒有覆蓋到，因為在確定測試范圍的時候，會把這次的功能和關聯的功能一起划定到這個范圍內（這個鍋就是領導的了，領導請接好）
3，如果范圍有覆蓋到，但是用例沒有覆蓋到，那么這個鍋就是編寫測試用例人員的鍋了。（這種類型的鍋會輕一些，畢竟人非聖賢孰能無過）；
4，如果有開發改動沒有知會測試導致的；（這鍋，開發請接好）
寫到最后：其實誰的鍋不重要，重要的是我們要學會多進行復盤，對已有導致的問題進行分析，總結，之后避免再次觸犯，或者減少觸犯的幾率，這才是我們最終的目標，畢竟開發和測試是相互協作，共同相輔相成的，還是要保持良好的關系，培養每個員工自省的能力，而不是相互推諉，互相甩鍋！！！
具體問題具體分析，舉幾個例子：
1、假設是軟件版本更新，開發人員在進行影響分析時漏掉了可能會影響的一個功能，而測試也沒有測到這個功能，恰恰這個功能上線出了問題，那沒說的，開發的責任；
2、軟件開發延期導致原本兩輪的測試變為一輪測試，測試不充分導致出現BUG，這應該是整個項目組的責任；
3、軟件按時提交測試，BUG出現在測試覆蓋范圍內，那么就是測試的責任；
4、測試BUG較多，測試部門要求延期上線，結果客戶或者領導壓下來，說必須按時上線，你說這是誰的問題？