1.軟件測試人員對bug都非常熟悉。

2.測試人員經常抱怨自己就是背鍋的，產品上線出bug，一定會有人說測試沒測出來，做好背鍋準備吧

2.產品上線真就是測試人員背鍋嗎？也需有測試人員不服氣憑什么，我就死扛我測過了，不知道為啥上線有問題，耍賴，踢皮球，說需求沒講清楚，需求變動了。。。等等各種原因。

3.需求評審，測試只需要帶耳朵去可以了，你說什么不重要，你人在就行，這就表示流程的要求達到了。這時候你跟道具沒有區別。如果真是這種情況，測試人員背鍋一點都不冤。

4.需求變更，沒有軟件項目是不變需求，產品經理可能考慮不周，可能業務方需求變更，總之需求變更肯定存在，開發和測試就勇敢面對吧，如果真是這種情況，建議需求切割，化整為零，排優先級，產品經理需求一盡量寫的細，思考的周期點，避免到測試階段才不停的確認是否需求這樣？測試人員背鍋概率也大。

5.開發人員，代碼質量，提測是否自測等，如果都沒自測問題都留到測試階段風險也就大了，來不及測試，或者測試覆蓋率低，都可能背鍋。

6.測試人員多多少少都會發現很多bug測不出來，上線才暴露出來，但是是否每個測試人員都想過也許有什么辦法可以解決這些問題。

測試左移：為什么開發在憋大招寫實現需求的時候測試不能介入?盡可能早的測試，也許能帶來一定的質量改進效果。比如說用測試樁的數據，先進行接口測試。

測試右移：preproduction環境，盡量保持與生產一樣的數據，接近與生產環境的數據更能發現問題。

優秀的團隊：軟件質量其實不是靠測試人員來保障的，軟件質量貫穿余整個軟件開發周期，需求——研發——測試——運維，每個節點都與軟件質量密不可分，質量過程管理就尤為重要，需要團隊的每個成員一同保障每個環節的軟件過程質量并治理，才能確保軟件質量。

總之，并不是說出問題了測試人員就是背鍋俠，或者開發人員就是背鍋俠，產品經理就是背鍋俠，互聯網團隊，應為線上問題處理響應能力，如果真的出現bug，立即處理，立即響應，而不是再找到底誰來背鍋？同一個團隊，共進退，共拼搏，同輸同贏。