問題描述：過程中一些會被研發認爲是無效bug，但從用戶角度出發，測試認爲該bug需要更改，此時測試如何更有效的說服研發去修改bug？bug測試
精彩回答：
1. 扭轉研發領導的思想，提高研發人員的響應速度：
a). 讓研發團隊的領導重視缺陷：
很多研發團隊的領導都是銷售出生，懂技術的很少，他們和搞技術的想法明顯不一樣。我在的第一家公司，發佈版本時很多時候，都是沒有測試結束，功能開發的差不多就把產品賣掉了，後面再對版本不斷升級，結果這個公司沒多久大概3年不到就散夥了。後面一家公司的領導是做質量管理出生的，明顯對測試的質量要求就不一樣，每次要求都特嚴，對以前測試結束標準都做了進一步的修改。如果領導對缺陷都視而不見，你說研發人員還願意花大量的力氣去修改Bug嗎？所以說，團隊的領導的想法或意識，對缺陷是否修改起到非常重要的作用。我記得以前測試高手zhuzx也在每週一問中提到過，大家也可以借鑑一下。
b). 採用常用的缺陷管理工具（QC9.0），提高缺陷的透明度：
我們公司使用缺陷管理工具（QC9.0）,測試經理任管理員，給公司高層領導、項目經理、開發經理都分配了權限，自己可以登錄系統查詢相關信息。在測試後期，特別是要發佈版本前後，領導們一有空，也隨時上去瀏覽一把，無意識給開發人員施加了較大的壓力。如果這個時候還有很多Open的缺陷，開發人員自然不敢怠慢。
c). 把開發人員的修改缺陷的響應速度，記入績效考覈內容：
由於公司總監特別關注產品質量，我們公司對缺陷修改這一點做得比較好，每次都是遞交缺陷以後，開發人員響應特別快。如果有疑問，就馬上和測試人員一對一交流，儘快修復或解決該缺陷。我們公司的口號是：“寧願花出100倍的代價，也不讓發現的缺陷留給客戶”。還有一點就是開發人員績效考覈的時候，我們測試人員要給開發人員打分，很重要的一點就是：開發人員對測試缺陷的響應速度，如果這一項很低的話，老大要找你談話的，問具體原因是什麼？呵呵。所以，我們公司很少有測試人員追着開發修改缺陷的情況，把修改缺陷的響應速度納入個人績效考覈，我個人覺的是一種比較好的方式，值得借鑑或推廣。
2. 組建一個合理的研發團隊，規範測試規範：
a). 關鍵是建立一個完善的研發機制：
在大多數情況下，是不是軟件缺陷或者需不需要修改，怎樣修改不是測試人員和開發人員說了算的，應該是靠研發部門的相關制度或相關部門去約束。畢竟在國內軟件的軟件企業缺少這樣的部門，所以說把修改缺陷相關的重任推到了測試人員的頭上，其實對測試人員實在是太不公平了。要解決這個問題，最關鍵就是建立一個完善的研發機制，讓QA等相關部門督促解決這類問題，比較好。
b). 分清團隊成員的具體責任：
對於研發團隊中的每個成員，必須責任明確，否則像督促缺陷修改這樣的事情本來不是測試人員的責任，現在都推到測試人員頭上了。很鬱悶！！
c). 完善測試規範，明確Bug管理制度：
大部分的公司，都沒有單獨的部門來單獨管理督促缺陷是否修改，都默認爲是測試部門的事情。個人覺的最好是賦予項目組中相關人員一定的資質，讓他們去處理這些瑣事。經常碰到這樣的情況，很多爭議的缺陷都一直放到後面一個版本，一段時間下來，幾個版本爭議的缺陷就多於100個，弄得後面版本也不好發佈。我們的做法是，發佈前幾天，對每個爭議的缺陷用郵件先發給項目組成員先看，後面在召開缺陷評審會議，如果通過，毫無疑問修改，否則關閉或保留到下一個版本。
本文出自51Testing軟件測試網，感謝會員sun_0910在每週一問（08-10-27）中的精彩回答。
http://bbs.51testing.com/forum-157-1.html
3. 從源頭上杜絕無效缺陷的遞交：
a). 測試前細化測試需求,避免遞交歧義缺陷：
很多研發不願意修改的缺陷，大部分都是由於需求不明確或者理解歧義引起的。所以，最好的做法是在測試以前，開個項目會議，細化一下測試需求，讓研發去確認或項目組成員集體Review，達成一致觀點。儘量減少理解上的歧義，力爭儘早消除無效或爭議的軟件缺陷，避免遞交的缺陷成爭議的缺陷。測試人員無法說服研發，讓研發去修復缺陷，長期這樣，測試部的威信就大大降低了。
b). 把握不準的缺陷，遞交以前最好討論一下：
特別是在測試初期，由於測試介入項目時間較短，有時候測試人員對業務或需求瞭解不深，遞交錯Bug也是常有的事情。這個時候，往往測試認爲自己遞交正確了，開發人員認爲自己開發軟件是對的，互不相讓，如果處理不好，很容易弄僵關係，弄得大家都不是很愉快。要是項目中出現這樣的Bug，是很難說服研發去修改的，還有可能成爲研發抓你的“小辮子”的有力證據，要是這樣以後就更難做了。個人的一些做法：所有的測試缺陷相互審覈後，才遞交到缺陷系統上公開，是最爲保險的方法。
c). 清楚無歧義的描述Bug，減少隨機測試，帶來不可重現的Bug：
很多時候，測試人員把缺陷描述不清楚或者缺陷有歧義，開發人員看不懂，不明白具體的意思，加上開發人員任務重時間緊，很容易產生逆反心裏，這就讓開發人員對測試人員有看法，以後遞交的缺陷認可度就大大降低了。還有就是要減少隨機測試，一定要保證遞交的缺陷能夠重複出現，最好要有截圖、圖片或者用數碼相機照下來，讓開發人員認識到這個問題確實存在，並且更具說服力。
很多同事發現的缺陷，只有在測試環境下重現，而在開發環境下不能夠重現。這樣的缺陷開發人員往往是看不到的，他們很容易得出結論，說測試人員遞交無效的缺陷而被拒絕，大部分情況發現是版本弄錯啦！！我們唯一能做的就是做好源代碼的配置管理工作，保證測試環境版本的正確性和獨立性，自己編譯自己部署測試環境。只有這樣，纔會減少無效缺陷的遞交，避免“費勁周折”說服開發人員修改缺陷。
4. 正確分析測試中的軟件缺陷：
a). 爲遞交的每個缺陷準備幾條充足的理由：
一般情況下，我們提到一個Bug時，開發人員都會說出很多可以不修改缺陷的理由，儘量搪塞住我們的口，要求我們關掉缺陷或者置爲無效或者延期到下一個版本。如果你很牛，你可以爲自己遞交的每個缺陷準備很充足的理由去說服開發人員；如果你不是太強，那就可以求助部門同事，集中測試部門團隊的力量，想一些好的、站得住腳理由，詳細介紹給研發人員聽，只要我們遞交的Bug，每個都具說服力的話，我想他們也會盡快修改的。這種方法還真是不錯，大家不妨試一試。
b). 詳細分析缺陷給項目帶來的各種可能影響或缺陷風險：
比如說，我們遞交一個缺陷，如果研發的覺的這個缺陷可以修改或可以不修改時。我們一定要給研發分析修改這個缺陷的必要性，不修改，對客戶帶來哪種可能影響或存在哪些風險。要在修改缺陷的代價與修復成本的關係上去衡量。相信，當我們對缺陷分析的很詳細時，研發人員一定會修改Bug的。
5. 做一個聰明的測試工程師：
a). 注意和研發人員的溝通技巧：
如果測試人員沒有做過開發工作，理解也許就比較片面。有的測試人員，對待問題沒有耐心，性情比較急，也是常有的事。如果沒有較好的溝通技巧，也許就是幾句話的功夫，就和同事爭吵了起來，弄得大家都比較尷尬。個人建議：談話時，要注意溝通技巧，要有換位思維的方式，做事情對事不對人，處理事情一定要有一顆寬容的心。只有這樣，才能夠很好的說服研發去修改Bug。
b). 和研發人員搞好私人關係，做研發的聽衆：
比較明智的測試人員，一定要學會傾聽研發人員的心生。很多時候，開發人員碰到工作困難的時候，很希望和人傾述，如果測試人員是他的聽衆，那麼你們的關係一定會不錯。搞好了私人關係，工作中你遞交的缺陷，他們就不會那麼斤斤計較了，畢竟關係是基礎，關係好了好說話呀，在中國就是如此。如果私人關係好了，說服研發修改Bug就是很容易的事情。不過得提醒一句：不能因爲關係好就把Open的缺陷給關了。
6. 抓住時機，不要錯過千載難逢的好機會：
a). 求助公司上層領導：
很多時候，測試到後期，開發人員把缺陷也修改的差不多了，公司領導（比如說老總、總監、項目經理或開發經理）就會隨時來測試部門，找測試經理或負責人瞭解項目測試的具體情況。如果有一些問題都是爭議問題，作爲測試Leader的你不妨給領導聊聊，把更高層的人拉進來爲測試部門說話，爲測試部門撐腰，但是凡事都有一個度，不能太過分，否則很傷同事的和氣。
b). 要求客戶代表援助：
很多GUI的缺陷或可改可不該的缺陷，可能作爲客戶使用不是很方便。我們可以和客戶代表聊聊這樣的缺陷，如果客戶代表同意這樣做，那沒問題，可以不修改；如果客戶不同意，他自然會直接找項目經理或高層人員協調解決這個問題，這就不用我們測試人員操心了。因爲客戶就是上帝，這招不錯吧！！！