從一開(kāi)始，測試就要關(guān)注需求。往往在討論設計時(shí)，開(kāi)發(fā)和需求很容易忽略了測試成員，他們潛意識里覺(jué)得這不關(guān)測試什么事�？墒�，測試也要熟悉業(yè)務(wù)，熟悉功能，熟悉各種設計，而且測試需要站在用戶(hù)的角度來(lái)去考量他們的設計是否有不合理的地方，并提出自己的建議。這些工作，測試成員需要主動(dòng)，積極參加，多提建設性意見(jiàn)，這樣可能會(huì )讓開(kāi)發(fā)慢慢發(fā)現測試成員的重要性。
其次，溝通最頻繁應該還是關(guān)于bug的討論。下面列出幾個(gè)遇到的溝通問(wèn)題，及我的解決辦法。
1、“這個(gè)bug我這邊重現不了啊~~~”
解決辦法：這種問(wèn)題首先要自省，bug描述里面是否沒(méi)有說(shuō)清楚。Bug應該簡(jiǎn)明扼要，重點(diǎn)突出。如果描述存在歧義，一定要總結并盡快改進(jìn)。有時(shí)會(huì )遇到概率性的bug，要告訴開(kāi)發(fā)概率是多少，盡可能多的提供重現的條件。
2、“這個(gè)不是代碼問(wèn)題，需求這么定義的”
解決辦法：需求也是人定的，如果覺(jué)得有異議，可以找需求人員詢(xún)問(wèn)清楚，為什么這樣定義，把自己的想法告訴他們，看他們怎么決定。如果被需求說(shuō)服了當然是最好的，如果自己還是不同意需求的看法，需求又不同意我的提議，那只能聽(tīng)他的，畢竟權力在他那里。但是我們可以保留交流的記錄，證明曾經(jīng)在這里發(fā)生過(guò)歧義。
3、“這塊是別人負責的，我負責的部分沒(méi)有問(wèn)題”
解決辦法：如果bug是由開(kāi)發(fā)的項目經(jīng)理來(lái)分發(fā)到程序員，那就是項目經(jīng)理來(lái)面對這樣的問(wèn)題，而不是測試。當然，項目經(jīng)理當然有項目經(jīng)理的處理辦法�？墒�，測試遇到這樣的問(wèn)題怎么辦呢，把負責相關(guān)內容的開(kāi)發(fā)都邀請到一個(gè)討論組里，讓他們自己討論，這樣更清楚，不必在測試這里中轉。如果他們都覺(jué)得代碼沒(méi)問(wèn)題，而我也有強有力的截圖和真相，那就只有上交給上級領(lǐng)導，讓他們來(lái)決定怎么解決。
4、“有問(wèn)題嗎？”（也就是開(kāi)發(fā)不認為這是個(gè)問(wèn)題）
解決辦法：測試人員一定比開(kāi)發(fā)要敏感，對bug的容忍度也要低一些。特別是一些不符合用戶(hù)習慣的bug，開(kāi)發(fā)總覺(jué)得無(wú)大礙。比如，一個(gè)列表默認的寬度太小了，導致初次打開(kāi)，有一些內容被隱藏在后面，但是這個(gè)寬度可以手動(dòng)調節。開(kāi)發(fā)覺(jué)得問(wèn)題很小，不影響功能，而且也有解決辦法，所以不認為是bug。這個(gè)時(shí)候，就要發(fā)揮測試的本事了，嘴甜一點(diǎn)，說(shuō)說(shuō)好話(huà)，態(tài)度柔和一些。因為既然是小問(wèn)題，解決起來(lái)一定不難，耐心地催開(kāi)發(fā)的改過(guò)來(lái)就好。催一次不行催兩次，記住態(tài)度一定要好。
5、“用戶(hù)不會(huì )像你這樣操作的！”
解決辦法：用戶(hù)怎么操作，誰(shuí)都預料不到。我們不可能覆蓋所有可能性，但是大多數用戶(hù)會(huì )出現的操作，我們當然要測試。慢慢地把開(kāi)發(fā)從代碼的世界里帶出來(lái)，帶到用戶(hù)的世界里，讓他換個(gè)角度思考問(wèn)題，畢竟軟件開(kāi)發(fā)不是為了實(shí)現功能，是要滿(mǎn)足用戶(hù)需求的。如果最后還是沒(méi)能說(shuō)服他，第一向上級反映，第二做好溝通的記錄，將來(lái)備份在測試報告里。
除了bug上的問(wèn)題，還有測試安排上的問(wèn)題，有時(shí)候小功能沒(méi)有做好，或者某個(gè)文檔、圖片沒(méi)有上傳，等小功能做好了文檔上傳之后，很可能開(kāi)發(fā)忘記告訴測試。所以，平時(shí)的工作中，一定要主動(dòng)記錄問(wèn)題，主動(dòng)溝通和督促，并反復確認，不要怕麻煩。
總結起來(lái)，測試在工作上要主動(dòng)詢(xún)問(wèn)，態(tài)度上不能輕易妥協(xié)，習慣上要善于記錄細節，方法上軟硬兼施。
