別再做“背鍋俠”！軟體測試工程師被開發吐槽，如何應對？

作為一名軟體測試工程師，我們的角色可以算是“戰場上的後勤”，戰役的勝敗和所有團隊人員都息息相關。但是難免碰到戰役失敗後，很多團隊互相推脫的局面，而測試人員就是所有團隊中的弱勢群體，自然是首當其衝的背鍋俠！相信你在做測試時肯定聽過下面這些話吧：

“哪有這麼多測試時間，你加快點測就完了”

“這麼明顯的bug居然沒測出來，這關我們開發什麼事”

“出現這麼多bug，你當時怎麼測的啊”

“仔細核對下需求，這個不是bug”

“這麼低階的bug你都測不出來嗎？，你到底怎麼做測試的？”

“這麼明顯的bug都沒測出來就讓我們上線了”

“研發時間不夠，你壓縮一下測試時間”

“你測出問題要第一時間和我們反應啊，誰會每時每刻盯著禪道去看剛提的bug啊”

我相信很多測試猿聽到這些話都會被氣的直哆嗦，脾氣爆一點的恨不得立馬吵架，幹架。所以研發團隊裡誰最受傷，我說測試第二，誰敢說第一？

但是在生氣之餘，我們得反思一下自己是否有地方需要改進，儘量減少精神內耗的發生。你要相信世間之事總有應對之法，如果你工作感覺很累，那肯定有什麼地方需要改變了。就像我之前提到的，測試人員除了需要埋頭苦幹的“智商”，更需要點“情商”在所有團隊成員之間斡旋，既要將測試工作做好，也要保障自己的利益。我從事測試八年之久，形形色色的研發人員見得太多了，發生的摩擦次數當然也比走過的橋多，但我始終相信方法總比困難多，今天就給大夥分享一下個人心得。

下面列出幾個比較常遇到的溝通問題，結合具體情景，給出具體對策：

“哪個使用者像你這麼操作？”

相信很多測試小夥伴老被開發這樣吐槽，但是如果我們真的順著開發去測試了，那我們測試存在的意義何在？

解決方式：

開發一般只注重需求的實現即可，而測試人員要始終站在使用者的角度思考問題，在測試過程中，我們不妨將使用者想象成一名“老人”。老人可能對於很多淺顯易懂的功能都是不會用的，所以我們測試時對易用性就要特別關心。但是使用者具體對哪裡陌生，用起來費事，我們不可能完全知道，所以只能儘可能地去覆蓋到位。當然我們也不必過分擔心，畢竟使用者也是成年人，且對該系統比外行人會更瞭解。

但是一開始開發肯定還是一根筋地把需求實現就完事了，所以我們得在平時就給他們灌輸使用者至上的理念，讓他們多想想使用者的難點，也是給他們自己後期減少麻煩，何樂而不為？我相信開發在你強大的PUA攻勢下，肯定會有所改變，雙方溝通的多了，也習慣了雙方的工作方式和思維模式，那麼下一次出現這個問題的時候，會更快更好的解決。即使開發不耐煩，測試也要多多提出來這類的問題，這是幫助開發進步的一個方式。

總之：一切站在使用者的角度看問題。達成共識很多問題就不會是問題了。

（如果你中了頭彩遇到個硬茬，說啥他都不聽，那你可以第一向領導反映，第二做好溝通的記錄，將來秋後算賬也是維護自己利益的好證據。）

“你這提的bug根本無法復現”

解決方式：

如果你經常遇到開發說這樣的話，那麼你得好好檢討一下自己了。首先檢查自己提交的bug描述是否簡潔，正確，易懂，重點是否突出，復現步驟是否精準，復現的機率；

如果你覺得你自己已經做到了這點，開發還是說這種話，那麼你可以跟他當面溝通，看看是哪裡還需要改進，哪有有什麼誤會；

如果你發現自己做的已經足夠好，開發還是丟擲這樣的話，那麼你可能需要將具體的bug給到相關人員，特別是上級去看了，以證清白了！

“需求沒規定的怎麼能算bug”

我以前遇到過一個bug，在一個OA系統登入介面上，註冊時用的大A開頭的使用者名稱註冊的，結果用小a輸入依舊可以登入，這就是典型的未作大小寫區分導致的。提了bug給開發，開發卻回到：“使用者沒有要求做大小寫區分，所以這不用管”，這可能是客戶預設的應該有的功能，只是未寫到需求中，開發就以此為藉口。諸如此類的bug會有很多，所以這就很考驗測試人員的經驗和堅持。

解決方式：

如果遇到這類問題，首先要參考市面上主流的產品或者系統是什麼樣的基本功能，如果和主流的有區別那就要加以注意了。其次呢如果自己無法確定是否要提這樣的bug，可以讓PM或者產品來做決定，即使他們否定了你的建議，你還是得做好記錄以防他們事後甩鍋。

“這不是程式碼問題，需求就這麼定的”

解決方式：

所有的需求都是人定的，既然是人定的，肯定會存在異議的地方。如果測試人員發現某處需求設定的不合理，是可以找需求人員瞭解清楚，為什麼這麼定，然後進一步和需求探討，再看他們怎麼決定。如果你能講得有理有據，我想先需求一般能被說服，當然很多時候是測試不太瞭解客戶需求，反而被需求說服了哈哈，這當然也是好事。

但是如果遇到有些需求比較強勢，既說不出道理，也聽不進測試的話，那這種情況你可以先找領導協商一下，如果領導也偏向於需求，那隻能作罷了，但還是那句話，你得把這個溝通結果和這個發現的bug記錄到禪道等缺陷管理工具中，以後也有證可查！

“你這個bug是其他人負責的，我這邊的都是正常的”

相信很多測試的小夥伴會經常發程式猿甩鍋的現象，如前端推後端，後端推前端。作為測試人員夾在中間反而感到尷尬，僅憑測試人員有限的開發知識又不可能準確知道具體是誰的bug，這該如何是好呢？

解決方式：

遇到此類情況如果去找PM定奪，當然是很快能解決的，但是如果次數多了就顯得我們測試很業餘了。那該怎麼辦呢？其實很簡單，只要把開發拉到一個討論組，把具體問題在討論組裡說一下，讓他們自己認領，如果還是有問題沒人認領或者互相推脫，那就只能將該bug記錄下來，並和PM第一時間反饋，這樣該bug即使出現在在客戶面前，你都是有理的。

可以到我的個人號：atstudy-js，可以免費領取一份10G軟體測試工程師面試寶典文件資料。同時我邀請你進入我們的軟體測試學習交流平臺，大家可以一起探討交流軟體測試，共同學習軟體測試技術、面試等軟體測試方方面面，瞭解測試行業的最新趨勢，助你快速進階Python自動化測試/測試開發，穩住當前職位同時走向高薪之路。

現將軟體測試人員如何避免成為“背鍋俠”總結為以下幾點：

避免“背鍋”是軟體測試人員日常工作中非常重要的一項任務。以下是一些建議：

1.明確責任和任務：

在專案初期，確保測試人員與專案團隊一起明確測試任務和責任。明確測試的範圍、目標、計劃以及各自的角色，避免在後期因為責任不清晰而產生問題。

2.參與需求評審：

積極參與需求評審，確保對需求的理解一致，避免由於需求不清晰或理解偏差導致的問題。

3.提前介入專案：

儘早介入專案，確保在需求和設計的早期階段就開始測試相關工作。這有助於早期發現和解決潛在問題。

4.詳細記錄測試過程和結果：

在測試過程中，詳細記錄測試用例、執行過程、環境配置以及測試結果。透過詳細的記錄，可以追溯問題的來源，避免因為資訊不足導致的責任爭議。

5.及時報告問題：

發現問題後，及時向開發團隊和專案管理人員報告問題。不要將問題留存在測試環節，及時溝通問題有助於避免問題擴大化。

6.合理評估測試時間：

在測試計劃中合理評估測試時間，確保有足夠的時間進行全面的測試。過於緊張的時間安排可能導致測試遺漏或質量不足。

7.建立良好的溝通渠道：

與開發團隊、產品經理和其他團隊成員建立良好的溝通渠道。開放式的溝通有助於及時瞭解專案進展和發現問題。

8.定期進行進展彙報：

定期向專案團隊和管理層彙報測試的進展情況，以及已經發現的問題和解決方案。及時的進展彙報有助於專案團隊全面瞭解測試工作。

9.主動學習和提升技能：

持續學習新的測試工具、技術和方法，提升自己的測試技能。透過不斷提升技能，能夠更好地應對各種測試挑戰。

10.參與專案總結和覆盤：

在專案結束後，參與專案總結和覆盤，分析測試中發生的問題，提出改進意見。這有助於總結經驗教訓，為下一個專案做好準備。

11.謹慎接受任務：

在接受任務時，要理性評估自身的能力和專案的風險。謹慎接受任務，避免因為無法完成任務而被迫承擔責任。

12.與團隊協作：

與團隊成員保持良好的協作關係，共同解決問題。團隊的合作和協同努力有助於專案的成功。

透過上述建議，軟體測試人員可以更好地規避責任風險，確保測試工作的質量和有效性。