軟體測試工作中的溝通問題

　　軟體測試不單單是件技術活，而是一門綜合藝術，其中就包括溝通的藝術。溝通貫穿於整個專案開發的過程。

　　從一開始，軟體測試就要關注需求。往往在討論設計時，開發和需求很容易忽略了軟體測試成員，他們潛意識裡覺得這不關軟體測試什麼事。可是，軟體測試也要熟悉業務，熟悉功能，熟悉各種設計，而且軟體測試需要站在使用者的角度來去考量他們的設計是否有不合理的地方，並提出自己的建議。這些工作，軟體測試成員需要主動，積極參加，多提建設性意見，這樣可能會讓開發慢慢發現軟體測試成員的重要性。

　　其次，溝通最頻繁應該還是關於bug的討論。下面列出幾個遇到的溝通問題，及我的解決辦法。

　　1、“這個bug我這邊重現不了啊~~~”

　　解決辦法：這種問題首先要自省，bug描述裡面是否沒有說清楚。Bug應該簡明扼要，重點突出。如果描述存在歧義，一定要總結並儘快改進。有時會遇到概率性的bug，要告訴開發概率是多少，儘可能多的提供重現的條件。

　　2、“這個不是程式碼問題，需求這麼定義的”

　　解決辦法：需求也是人定的，如果覺得有異議，可以找需求人員詢問清楚，為什麼這樣定義，把自己的想法告訴他們，看他們怎麼決定。如果被需求說服了當然是最好的，如果自己還是不同意需求的看法，需求又不同意我的提議，那隻能聽他的，畢竟權力在他那裡。但是我們可以保留交流的記錄，證明曾經在這裡發生過歧義。

　　3、“這塊是別人負責的，我負責的部分沒有問題”

　　解決辦法：如果bug是由開發的專案經理來分發到程式設計師，那就是專案經理來面對這樣的問題，而不是軟體測試。當然，專案經理當然有專案經理的處理辦法。可是，軟體測試遇到這樣的問題怎麼辦呢，把負責相關內容的開發都邀請到一個討論組裡，讓他們自己討論，這樣更清楚，不必在軟體測試這裡中轉。如果他們都覺得程式碼沒問題，而我也有強有力的截圖和真相，那就只有上交給上級領導，讓他們來決定怎麼解決。

　　4、“有問題嗎？”（也就是開發不認為這是個問題）

　　解決辦法：軟體測試人員一定比開發要敏感，對bug的容忍度也要低一些。特別是一些不符合使用者習慣的bug，開發總覺得無大礙。比如，一個列表預設的寬度太小了，導致初次開啟，有一些內容被隱藏在後面，但是這個寬度可以手動調節。開發覺得問題很小，不影響功能，而且也有解決辦法，所以不認為是bug。這個時候，就要發揮軟體測試的本事了，嘴甜一點，說說好話，態度柔和一些。因為既然是小問題，解決起來一定不難，耐心地催開發的改過來就好。催一次不行催兩次，記住態度一定要好。

　　5、“使用者不會像你這樣操作的！”

　　解決辦法：使用者怎麼操作，誰都預料不到。我們不可能覆蓋所有可能性，但是大多數使用者會出現的操作，我們當然要軟體測試。慢慢地把開發從程式碼的世界裡帶出來，帶到使用者的世界裡，讓他換個角度思考問題，畢竟軟體開發不是為了實現功能，是要滿足使用者需求的。如果最後還是沒能說服他，第一向上級反映，第二做好溝通的記錄，將來備份在軟體測試報告裡。

　　除了bug上的問題，還有軟體測試安排上的問題，有時候小功能沒有做好，或者某個文件、圖片沒有上傳，等小功能做好了文件上傳之後，很可能開發忘記告訴軟體測試。所以，平時的工作中，一定要主動記錄問題，主動溝通和督促，並反覆確認，不要怕麻煩。

　　總結起來，軟體測試在工作上要主動詢問，態度上不能輕易妥協，習慣上要善於記錄細節，方法上軟硬兼施。

[@more@]本文出自51Testing軟體測試網：http://www.51testing.com/html/index.html

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/11323760/viewspace-1060555/，如需轉載，請註明出處，否則將追究法律責任。