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

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

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

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

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

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

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

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

測試右移：preproduction環(huán)境，盡量保持與生產(chǎn)一樣的數(shù)據(jù)，接近與生產(chǎn)環(huán)境的數(shù)據(jù)更能發(fā)現(xiàn)問題。

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

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