在知乎上看到一個很有意思的問題“軟體測試完後,還有BUG,是測試人員的問題嗎?”

相信很多測試的小夥伴也都遇到過這樣的情況，往往產品上線，只要出現bug，成為“背鍋俠”。

測試人員在工作中經常打交道的肯定是開發和產品經理，開發將程式寫出來，測試員進行測試。軟體測試完成後，產品才能生產，在這過程中，難免會遇到軟體會出現問題的情況。那麼你肯定聽過這些話：

“這麼弱智的bug你都測不出來嗎？”
“為啥這個功能還沒測完就上線了？”
“研發時間不夠，你壓縮一下測試時間”
“這個bug和開發沒關係，注意看需求”

聽到這些話，相信你分分鐘高血壓，這個鍋不知不覺就“甩”到你身了。

問題的關鍵來了，很多測試員就會出現這種疑問：軟體測試完後，還有Bug，責任全都在測試嗎？

舉個例子測試攻城獅們就會明白，不是所有的鍋都得測試背

1、假設是軟體版本更新，開發人員在進行影響分析時漏掉了可能會影響的一個功能，而測試也沒有測到這個功能，恰恰這個功能上線出了問題，那沒說的，開發的責任；

2、軟體開發延期導致原本兩輪的測試變為一輪測試，測試不充分導致出現BUG，這應該是整個專案組的責任；

3、軟體按時提交測試，BUG出現在測試覆蓋範圍內，那麼就是測試的責任；

4、測試BUG較多，測試部門要求延期上線，結果客戶或者領導壓下來，說必須按時上線，你說這是誰的問題？

所以，軟體測試完後，還有Bug，不一定都是測試的鍋，首先要清楚的知道是什麼原因導致出現的bug，所以這個時候就需要有人來組織這個Bug的責任認定和後續改進。

線上Bug的討論一般有如下這些內容：

1、Bug的產生原因，仔細地分析Bug為什麼會產生，這個環節很重要，因為這個環節弄清楚以後，責任認定就清楚了。

2、Bug的責任認定，一般來說，除了那些責任真的很清晰的Bug之外，很多Bug都是開發、測試、策劃、專案經理共責的，為了團隊的團結，也沒有必要去討論哪個團隊負主要責任。

3、Bug影響範圍，分析這個Bug對於使用者造成的影響。

4、改進措施，在改進措施這一項中，可以把以後如何避免類似Bug的措施寫進去，並在任務系統建立任務，指定專門的人跟進。

其實，說到底，還是因為職責劃分不清晰導致的“背鍋”。
那再來說下專案組實際Bug的責任認定吧：

1、如果測試時間還是比較充足，測試用例有寫，但是還是漏測的，那就是測試的責任。測試用例沒有覆蓋，測試用例覆蓋了卻沒有執行，各有不同的偏重點，前者參與評審的相關人員都有責任，後者測試組的完全責任，PM也有對應責任。

2、如果測試時間不充足，測試用例有寫，但是因為時間不足而降低迴歸測試範圍，導致漏測的，那一般是專案組各個角色共責的。

3、如果有開發修改了功能沒有通知測試人員，導致線上漏測的，那就是開發的責任。

4、如果策劃人員在迴歸測試階段還提了需求變更，在測試人員明確告知風險的情況下還堅持要上需求變更的，那就是策劃的責任。

5、需求覆蓋不到的地方，描述不清楚的地方，需求，設計和測試都要承擔一定的責任，需求的責任最重。說需求人員的責任大家都容易理解，為什麼說設計和測試還有PM都有責任，是因為需求的評審是需要設計和測試參與的，角度不同，具體這裡就不展開了。除非判斷就是需求採集中的重大缺陷，否則設計和測試都有關聯的次要責任。

6、設計過程，開發過程沒有實現，需求檢查到了，設計和開發卻沒有彌補。設計和開發的責任，PM責任最大，監管不到位。

7、交付部署中出現的問題，版本拿錯的責任，一般在於PM，配置管理員和測試經理，也有可能是因為沒有足夠明確的制度造成了混亂，這樣需要部門經理或者更高層的人員來牽頭負責。版本拿對了，安裝過程出錯，交付部署人員的責任最大，專案經理次之。

測試人員如何有效避免“背鍋”呢?

1、留出足夠的測試時間

要保證測試時間，從流程上就要做起，說明測試的重要性，我看很多測試對自己的重要程度一直沒認識到。在專案排期時，就要定夠足夠的測試時間(一般都是給一點冗餘時間，以處理突發事件)。如果說因為特殊情況導致測試時間不夠，比如開發沒有按預期提測，產品需求變更，也要勇於提出或者延期發版，或者減少功能，以保證自己測試時間。如果說這兩點都不能保證，則在測試報告中寫明，由於xxx情況，導致測試時間不足，所引起無法完全覆蓋。

2、做好資料備份。凡事不要口頭溝通。

我看有些人背鍋，明明測過了，提過bug，但是線上又出現了人家說你提的bug 呢？你說我只是和開發說了一句…呵呵，空口無憑。提bug 的時候，不要途一時之快，不寫bug口頭溝通，這樣沒事的時候你好我好大家好，出了事，你想甩鍋都沒辦法甩。包括前面測試的版本包，都備份下來。如果確實是開發後面改動引起的問題。你可以把前面的版本包拿出來驗證，如果沒問題，則可甩部分鍋給開發(這裡部分看能力，如果是我以前老大，鍋就全甩過去了)

3、寫好測試報告。

對於有風險的內容，測試報告裡一定要寫清楚，比方說前面說的時間不夠。又或者是一些情況，測試環境不好驗證。註明後，發給團隊，團隊人周知，並且是專案負責人拍版可以後再進行發版。測試報告不要隨便寫寫就算了，非常重要。

4、甩鍋給開發，產品沒關係，不要甩鍋給同是測試組員，或者手下，否則後患無窮。我就碰見過一個甩鍋給手下的老大，最後鬧的兩個人都不說話，有事就發郵件溝通。畢竟測試同學都是小夥伴，誰是我們的朋友，誰是我們的敵人，還是要分清楚的。滴水不漏的甩鍋給手下，同事，最後難免搞的自己孤家寡人。事實上，我碰見我的組員出一些問題，都會主動幫他分擔部分責任的，讓他感覺我在挺他。這樣才能保證測試團隊的凝聚力。

總結

保證軟體高質量，並非只是測試人員的責任，軟體質量體現在功能質量、結構質量和過程質量三個方面，對產品質量負責，意味著要對著三方面共同負責。當出現Bug時，對於企業來說，問題不解決，只是糾纏問題是誰的責任，公司會被這些人直接拖垮，這時候對於企業來說最重要的就是解決問題！所以對於產品質量，最理想的狀態還是做到人人都為產品質量負責，為了達到這個目標，我們需要建立一種重視質量的文化，每個人才會確確實實地對質量負責。