很多時候，測試人員把缺陷描述不清楚或者缺陷有歧義，開發人員看不懂，不明白具體的意思，加上開發人員任務重時間緊，很容易產生逆反心里，這就讓開發人員對測試人員有看法，以后遞交的缺陷認可度就大大降低了。還有就是要減少隨機測試，一定要保證遞交的缺陷能夠重復出現，最好要有截圖、圖片或者用數碼相機照下來，讓開發人員認識到這個問題確實存在，并且更具說服力。
d). 做好版本配置管理工作，保證測試環境的準確性：軟件測試環境搭建
很多同事發現的缺陷，只有在測試環境下重現，而在開發環境下不能夠重現。這樣的缺陷開發人員往往是看不到的，他們很容易得出結論，說測試人員遞交無效的缺陷而被拒絕，大部分情況發現是版本弄錯啦��！我們唯一能做的就是做好源代碼的配置管理工作，保證測試環境版本的正確性和獨立性，自己編譯自己部署測試環境。只有這樣，才會減少無效缺陷的遞交，避免“費勁周折”說服開發人員修改缺陷。
4. 正確分析測試中的軟件缺陷：
a). 為遞交的每個缺陷準備幾條充足的理由：
一般情況下，我們提到一個Bug時，開發人員都會說出很多可以不修改缺陷的理由，盡量搪塞住我們的口，要求我們關掉缺陷或者置為無效或者延期到下一個版本。如果你很牛，你可以為自己遞交的每個缺陷準備很充足的理由去說服開發人員；如果你不是太強，那就可以求助部門同事，集中測試部門團隊的力量，想一些好的、站得住腳理由，詳細介紹給研發人員聽，只要我們遞交的Bug，每個都具說服力的話，我想他們也會盡快修改的。這種方法還真是不錯，大家不妨試一試。
b). 詳細分析缺陷給項目帶來的各種可能影響或缺陷風險：
比如說，我們遞交一個缺陷，如果研發的覺的這個缺陷可以修改或可以不修改時。我們一定要給研發分析修改這個缺陷的必要性，不修改，對客戶帶來哪種可能影響或存在哪些風險。要在修改缺陷的代價與修復成本的關系上去衡量。相信，當我們對缺陷分析的很詳細時，研發人員一定會修改Bug的。
5. 做一個聰明的測試工程師：
a). 注意和研發人員的溝通技巧：
如果測試人員沒有做過開發工作，理解也許就比較片面。有的測試人員，對待問題沒有耐心，性情比較急，也是常有的事。如果沒有較好的溝通技巧，也許就是幾句話的功夫，就和同事爭吵了起來，弄得大家都比較尷尬。個人建議：談話時，要注意溝通技巧，要有換位思維的方式，做事情對事不對人，處理事情一定要有一顆寬容的心。只有這樣，才能夠很好的說服研發去修改Bug。
b). 和研發人員搞好私人關系，做研發的聽眾：
比較明智的測試人員，一定要學會傾聽研發人員的心生。很多時候，開發人員碰到工作困難的時候，很希望和人傾述，如果測試人員是他的聽眾，那么你們的關系一定會不錯。搞好了私人關系，工作中你遞交的缺陷，他們就不會那么斤斤計較了，畢竟關系是基礎，關系好了好說話呀，在中國就是如此。如果私人關系好了，說服研發修改Bug就是很容易的事情。不過得提醒一句：不能因為關系好就把Open的缺陷給關了。
6. 抓住時機，不要錯過千載難逢的好機會：
a). 求助公司上層領導：
很多時候，測試到后期，開發人員把缺陷也修改的差不多了，公司領導（比如說老總、總監、項目經理或開發經理）就會隨時來測試部門，找測試經理或負責人了解項目測試的具體情況。如果有一些問題都是爭議問題，作為測試Leader的你不妨給領導聊聊，把更高層的人拉進來為測試部門說話，為測試部門撐腰，但是凡事都有一個度，不能太過分，否則很傷同事的和氣。
b). 要求客戶代表援助：
很多GUI的缺陷或可改可不該的缺陷，可能作為客戶使用不是很方便。我們可以和客戶代表聊聊這樣的缺陷，如果客戶代表同意這樣做，那沒問題，可以不修改；如果客戶不同意，他自然會直接找項目經理或高層人員協調解決這個問題，這就不用我們測試人員操心了。因為客戶就是上帝，這招不錯吧�。�！
我目前想到的就這么多，希望同行指正�。�！
文章來源于領測軟件測試網 http://www.kjueaiud.com/
