作為一名軟體測試工程師，日常工作中最常打交道的肯定就是開發和産品經理。有溝通就會問題，有問題難免會有争執。那麼你肯定聽過這些話：
“這麼弱智的bug你都測不出來嗎？”
“為啥這個功能還沒測完就上線了？”
“研發時間不夠，你壓縮一下測試時間”
“這個bug和開發沒關系，注意看需求”
聽到這些話，分分鐘高血壓，要說誰是超級背鍋俠，那測試肯定當仁不讓（要求追加“背鍋費”）
問題的關鍵來了：作為測試的核心不是看人家的代碼寫的錯不錯，本質上要更關注需求。在開需求評審會的時候，開發和産品往往很容易忽略了測試，他們下意識會認為和下遊沒有關系。可是，熟悉業務，熟悉功能，熟悉各種設計是整個研發團隊都需要達成資訊共同的，而且測試需要站在使用者的角度來去考慮他們的設計是否有不合理的地方，并提出自己的建議。上面說的工作，需要測試去主動，積極參加，多提建設性意見，讓其他崗位的人認識到測試的重要性。其次，除了需求評審會溝通之外最頻繁應該還是關于bug的讨論。下面列出幾個比較常遇到的溝通問題，僅供大家參考。
“這有問題嗎？”
（對方研發或者産品不認為是自己的問題）解決方式：在看待bug上，測試人員一定比開發要敏感，對bug的容忍度也要低一些。特别是一些不符合使用者習慣的bug，産品總覺得無大礙。比如，一個彈窗預設的寬度太小了，導緻初次打開，有一些内容被隐藏在後面，但是這個寬度可以手動調節。開發覺得問題很小，不影響功能（開發往往隻看重功能是否實作），而且也有解決辦法，是以不認為是bug。這個時候，需求能定的可以打需求決定，需求不明确的，要好好跟開發溝通，可以讓他在有時間的時候處理，不需要急着馬上處理。
“這個bug我無法重制”
解決方式：先檢查自己送出的bug描述，看看是否準确，bug重制步驟是否沒有說清楚。bug應該簡明扼要，重點突出。如果描述存在讓人誤解的表意，最好改過之前再給對方，如果還是無法解決就當面溝通，事後根據溝通内容來表述内容。遇到機率性的bug，一定要告訴開發機率是多少，盡可能多的提供重制條件。
“這不是代碼問題，需求就這麼定的”
解決方式：需求也是人定的，如果覺得有異議，可以找需求人員了解清楚，為什麼這麼定，然後把自己的想法告訴他們，看他們怎麼決定。如果被需求說服了當然是最好的，如果自己還是不同意需求的看法，需求又不同意我的提議，那隻能聽他的，畢竟權力在他那裡。不過我們可以把溝通結果備注在這個bug下，以後也能有證可查。
“使用者不會像你這樣操作的”
解決方式：測試過程中，我們可以要把客戶想象成“兒童”，使用者會如何操作，我們無法列出所有的操作選項，隻有盡可能的去覆寫到位。不過也不用過分擔心，畢竟使用者都是成年人。開發的思考角度其實僅在于功能是否實作，而測試人員需要考慮的更多，是以也了解開發會說這樣的話，但是為了更好的産品體驗，多多提出來這類的問題，也是幫助開發進步的一個方式。雙方溝通的多了，也習慣了雙方的工作方式和思維模式，那麼下一次出現這個問題的時候，會更快更好的解決。總之：一切站在使用者的角度看問題。達成這樣的共識，很多問題就不會是問題了。（但是最後還是沒能說服他，第一向上司反映，第二做好溝通的記錄，将來備注在測試報告裡。）
“這塊是别人負責的，我負責的部分沒有問題”
解決方式：如果bug是由開發的項目經理來分發到程式員，那就是項目經理來面對這樣的問題，而不是測試。當然，項目經理當然有項目經理的處理辦法。可是，測試遇到這樣的問題怎麼辦呢，把負責相關内容的開發都邀請到一個讨論組裡，讓他們自己讨論，這樣更清楚，不必在測試這裡中轉。如果他們都覺得代碼沒問題，而我也有強有力的截圖和真相，那就隻有上交給上級上司，讓他們來決定怎麼解決。
除了bug上的問題，還有測試安排上的問題，有時候小功能沒有做好，或者某個文檔、圖檔沒有上傳，等到了小功能做好了文檔上傳之後，很可能開發會忘記告訴測試。是以，平時的工作中，一定要主動記錄問題，主動溝通和督促，并反複确認，不要怕麻煩。
總結起來，測試在工作上要主動詢問，态度上不能輕易妥協，習慣上要善于記錄細節，方法上軟硬兼施，這樣才能在職業生涯上一步一個腳印。
關注我，讓你的測試之路更簡單~~~~