和開發溝通bug之常見遇到回覆

和開發溝通bug之常見遇到回覆

走心原創第19期

從一開始，測試就要關注需求。每每在討論設計時，開發和需求很容易忽略了測試成員，他們潛意識裏以爲這不關測試什麼事。但是，測試也要熟悉業務，熟悉功能，熟悉各類設計，並且測試須要站在用戶的角度來去考量他們的設計是否有不合理的地方，並提出本身的建議。這些工做，測試成員須要主動，積極參加，多提建設性意見，這樣可能會讓開發慢慢發現測試成員的重要性。
其次，溝通最頻繁應該仍是關於bug的討論。下面列出幾個遇到的溝通問題，及個人解決辦法。
一、「這個bug我這邊重現不了啊~~~」
解決辦法：這種問題首先要自省，bug描述裏面是否沒有說清楚。Bug應該簡明扼要，重點突出。若是描述存在歧義，必定要總結並儘快改進。有時會遇到機率性的bug，要告訴開發機率是多少，儘量多的提供重現的條件。
二、「這個不是代碼問題，需求這麼定義的」
解決辦法：需求也是人定的，若是以爲有異議，能夠找需求人員詢問清楚，爲何這樣定義，把本身的想法告訴他們，看他們怎麼決定。若是被需求說服了固然是最好的，若是本身仍是不一樣意需求的見解，需求又不一樣意個人提議，那隻能聽他的，畢竟權力在他那裏。可是咱們能夠保留交流的記錄，證實曾經在這裏發生過歧義。
三、「這塊是別人負責的，我負責的部分沒有問題」
解決辦法：若是bug是由開發的項目經理來分發到程序員，那就是項目經理來面對這樣的問題，而不是測試。固然，項目經理固然有項目經理的處理辦法。但是，測試遇到這樣的問題怎麼辦呢，把負責相關內容的開發都邀請到一個討論組裏，讓他們本身討論，這樣更清楚，沒必要在測試這裏中轉。若是他們都以爲代碼沒問題，而我也有強有力的截圖和真相，那就只有上交給上級領導，讓他們來決定怎麼解決。
四、「有問題嗎？」（也就是開發不認爲這是個問題）
　　解決辦法：測試人員必定比開發要敏感，對bug的容忍度也要低一些。特別是一些不符合用戶習慣的bug，開發總以爲無大礙。好比，一個列表默認的寬度過小了，致使初次打開，有一些內容被隱藏在後面，可是這個寬度能夠手動調節。開發以爲問題很小，不影響功能，並且也有解決辦法，因此不認爲是bug。這個時候，就要發揮測試的本事了，嘴甜一點，說說好話，態度柔和一些。由於既然是小問題，解決起來必定不難，耐心地催開發的改過來就好。催一次不行催兩次，記住態度必定要好。
五、「用戶不會像你這樣操做的！」
　　解決辦法：用戶怎麼操做，誰都預料不到。咱們不可能覆蓋全部可能性，可是大多數用戶會出現的操做，咱們固然要測試。慢慢地把開發從代碼的世界裏帶出來，帶到用戶的世界裏，讓他換個角度思考問題，畢竟軟件開發不是爲了實現功能，是要知足用戶需求的。若是最後仍是沒能說服他，第一貫上級反映，第二作好溝通的記錄，未來備份在測試報告裏。
　　除了bug上的問題，還有測試安排上的問題，有時候小功能沒有作好，或者某個文檔、圖片沒有上傳，等小功能作好了文檔上傳以後，極可能開發忘記告訴測試。因此，平時的工做中，必定要主動記錄問題，主動溝通和督促，並反覆確認，不要怕麻煩。
　　總結起來，測試在工做上要主動詢問，態度上不能輕易妥協，習慣上要善於記錄細節，方法上軟硬兼施。

• End -
  做者：腦洞大大的吃貨獅子座，喜歡專研技術，勤於總結概括,用文字結交朋友，擅長與生活相愛相殺，樂於分享的一個技術狂人。
  軟 件 測 試 君
  聽 說 看 了 這 個 號 可 以 幹 掉 領 導· 猜你喜歡的文章 ·