測試完,還有BUG,仍是測試的責任？這鍋咱們不背！

前言：

前幾天我和兩個作網絡運維的朋友吃飯聊天，聊着聊着談到了工做當中背鍋的經歷。

第一個朋友談到了這樣的一件事情：A客戶J業務系統中斷了十幾個小時，他公司負責X部網絡運維的同事配合J部排查故障緣由，在沒有獲得客戶容許下，私自改動了自身運維的網絡設備配置，業務恢復正常。而過後業務部門追責故障緣由，卻說是他們負責運維的設備出現問題致使的。

另外一個小夥伴的劇情更加精彩，他講到：他們公司負責B企業網絡運維項目，網絡設備貼標籤工做由第三方機房運維企業負責。某天客戶領導檢查機房網絡設備，發現部分設備標籤未貼。第三方機房運維人員當場甩鍋，說是他公司未提供標籤數據信息給他們，致使網絡設備標籤沒打。最終結果成了客戶向項目經理投訴他們現場運維工程師工做不到位。

就一句話：工做中沒背過鍋的，不足以談人生，生活已經如此艱難，再背個鍋簡直難上加難有木有。

在這裏插入圖片描述
不過有句老話說的好：吃虧是福！若是你今天是背鍋俠明天說不定就成了甩鍋俠，沒有啦，開個玩笑，我知道背鍋是聽讓人難受的，可是有時候正是一次背鍋，後面你就少踩不少坑。

正文：

我相信不少測試的小夥伴和我同樣也都遇到過這樣的狀況，每每產品上線，只要出現bug，成爲「背鍋俠」。測試人員在工做中常常打交道的確定是開發和產品經理，開發將程序寫出來，測試員進行測試。軟件測試完成後，產品才能生產，在這過程當中，不免會遇到軟件會出現問題的狀況。那麼你確定聽過這些話：

a.「這麼明顯的bug你都測不出來嗎？」

b.「爲啥這個功能還沒測完就上線了？」

c .「研發時間不夠，你壓縮一下測試時間」

d.「這個bug和開發不要緊，注意看需求」

聽到這些話，相信你分分鐘高血壓，這個鍋不知不覺就「甩」到你身了。
在這裏插入圖片描述

那麼就有個很是嚴肅的問題來了，軟件都測試完成後了，還有Bug，責任全都在測試嗎？！在這個這個。。。。，固然不是啊，下面舉了例子和你們好好講講，到最後你會發現不是全部的鍋都得測試背。
在這裏插入圖片描述
一.必定不是測試責任的狀況：

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

b：軟件開發延期致使本來兩輪的測試變爲一輪測試，測試不充分致使出現BUG，這應該是整個項目組的責任；

c：軟件按時提交測試，BUG出如今測試覆蓋範圍內，那麼就是測試的責任；

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

因此，軟件測試完後，還有Bug，不必定都是我們作測試的鍋，首先要清楚的知道是什麼緣由致使bug的產生，因此這個時候就須要有人來組織這個Bug的責任認定和後續改進。

二.線上Bug的討論通常有以下這些內容：

a、Bug的產生緣由，仔細地分析Bug爲何會產生，這個環節很重要，由於這個環節弄清楚之後，責任認定就清楚了。
b、Bug的責任認定，通常來講，除了那些責任真的很清晰的Bug以外，不少Bug都是開發、測試、策劃、項目經理共責的，爲了團隊的團結，也沒有必要去討論哪一個團隊負主要責任。

c、Bug影響範圍，分析這個Bug對於用戶形成的影響。

d、改進措施，在改進措施這一項中，能夠把之後如何避免相似Bug的措施寫進去，並在任務系統創建任務，指定專門的人跟進。

其實，說到底，仍是由於職責劃分不清晰致使的「背鍋」。

三.那再來講下項目組實際Bug的責任認定吧：

a、若是測試時間仍是比較充足，測試用例有寫，可是仍是漏測的，那就是測試的責任。

測試用例沒有覆蓋，測試用例覆蓋了卻沒有執行，各有不一樣的偏重點，前者參與評審的相關人員都有責任，後者測試組的徹底責任，PM也有對應責任。

b、若是測試時間不充足，測試用例有寫，可是由於時間不足而下降回歸測試範圍，致使漏測的，那通常是項目組各個角色共責的。

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

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

e、需求覆蓋不到的地方，描述不清楚的地方，需求，設計和測試都要承擔必定的責任，需求的責任最重。說需求人員的責任你們都容易理解，爲何說設計和測試還有PM都有責任，是由於需求的評審是須要設計和測試參與的，角度不一樣，具體這裏就不展開了。

除非判斷就是需求採集中的重大缺陷，不然設計和測試都有關聯的次要責任。

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

g、交付部署中出現的問題，版本拿錯的責任，通常在於PM，配置管理員和測試經理，也有多是由於沒有足夠明確的制度形成了混亂，這樣須要部門經理或者更高層的人員來牽頭負責。版本拿對了，安裝過程出錯，交付部署人員的責任最大，項目經理次之。

對於測試人員來講，測試階段若是由於時間缺乏、需求變動頻繁等緣由致使迴歸測試範圍不足的，必定要儘早跟項目組正式地發郵件溝通狀況，讓你們儘早知曉風險，這樣出現線上Bug的時候，項目組其餘人員就不會認爲測試工做沒作到位。

四.那麼重點來了測試人員如何有效避免「背鍋」呢?

a、留出足夠的測試時間

要保證測試時間，從流程上就要作起，說明測試的重要性，我看不少測試對本身的重要程度一直沒認識到。在項目排期時，就要定夠足夠的測試時間(通常都是給一點冗餘時間，以處理突發事件)。若是說由於特殊狀況致使測試時間不夠，好比開發沒有按預期提測，產品需求變動，也要敢於提出或者延期發版，或者減小功能，以保證本身測試時間。若是說這兩點都不能保證，則在測試報告中寫明，因爲xxx狀況，致使測試時間不足，所引發沒法徹底覆蓋。

b、作好數據備份。凡事不要口頭溝通。

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

c、寫好測試報告。

對於有風險的內容，測試報告裏必定要寫清楚，比方說前面說的時間不夠。又或者是一些狀況，測試環境很差驗證。註明後，發給團隊，團隊人周知，而且是項目負責人拍版能夠後再進行發版。測試報告不要隨便寫寫就算了，很是重要。

d、甩鍋給開發，產品不要緊，不要甩鍋給同是測試組員，或者手下，不然後患無窮。

我就遇見過一個甩鍋給手下的老大，最後鬧的兩我的都不說話，有事就發郵件溝通。畢竟測試同窗都是小夥伴，誰是咱們的朋友，誰是咱們的敵人，仍是要分清楚的。滴水不漏的甩鍋給手下，同事，最後不免搞的本身孤家寡人。事實上，我遇見個人組員出一些問題，都會主動幫他分擔部分責任的，讓他感受我在挺他。這樣才能保證測試團隊的凝聚力

在這裏推薦一個軟件測試交流羣，qq:642830685,羣中會不按期的分享軟件資源，測試面試題以及測試行業資訊，你們能夠在羣中積極交流技術，還有大佬爲你答疑解惑。

五.寫在最後：

不要沮喪，沒必要驚慌，作努力爬的蝸牛或堅持飛的笨鳥，咱們試着長大，一路跌跌撞撞，而後遍體鱗傷。堅持着，總有一天，你會站在最亮的地方，活成本身曾經渴望的模樣。一些事情，當你選擇放棄的時候，不是由於你不夠堅決和執着，也不是由於你懦弱，而是由於必須選擇面前給本身一個臺階。因此朋友們當你面對生活中的不快時，努力調整本身，朝着心中所念所想，加油！在這裏插入圖片描述看完文章的小夥伴們不要忘記舉起你那可愛的小手給我點個贊，你的點贊是我更文的不竭動力，筆芯。