開發人員和測試人員的主要矛盾集中在對bug的定義上。

　　測試人員辛辛苦苦發現軟件中有問題，報了一個bug。這時會出現兩種狀況。第一種，開發人員工作很忙，壓力很大，外加心情不好，會說出如下四類話：

　　a.你會不會用軟件呀?

　　b.你使用了bt的方法發現了用戶永遠也不可能發現的問題

　　c.由于我使用了XXX技術，YYY方法和受到了ZZZ的約束，所以只能出現這樣的問題，所以不是bug

　　d.上次都說過了，是你們測試的問題，先保證測試用例的正確性再來測試

　　而如果開發人員比較閑，也許會仔細斟酌一下，做出下列答復：

　　e.這確實是個問題。但是是由于我的一個小小的疏忽所致，也不至于報的這么嚴重吧?

　　f.老兄，老板們急著要release，我看我們。。。

　　也許大家還會碰到別的情況，但是我們測試人員和開發人員總在和這些bug打轉，相互打口水丈，所以關系一直很緊張。

　　大家也許要問如何解決緊張的關系，我想到了幾個方面，也歡迎大家補充。

　　首先我要為測試人員說說好話，因為我們通常被認為是不重要的一群人。1)開發人員通常把軟件看成是程序，他們的這種認識上的誤區會排斥程序以外的其它因素，例如相關的文檔。2)開發人員通常把軟件的質量等同于軟件功能性方面的質量。ISO/IEC9126標準中定義了6大質量特性，我們做測試的人員不應該讓開發人員鉆其它五項的空子。3)測試人員通常關注的軟件的行為，也是外在表現，是對外部質量的評價。而開發人員通常是關注軟件的實現細節，也是內部構成，即內部質量。外部質量和內部質量是不等價的，也是說開發人員犯的錯誤會引入缺陷，而缺陷在特定的使用下才會產生失效。所以我們應該統一和測試人員關于bug的理解和認識，避免分歧的不斷涌現。

　　為測試人員說了好話，也要說說不好的地方。1)急于提交bug，體現自己工作的成果，而忽視了對bug的描述。對測試的步驟，測試平臺的配置，產生的現象，造成的影響等都應該盡可能詳細。詳細而準確的描述不但能讓開發人員快速而準確的定位問題，而且便于問題的重現。2)不考慮質量評價的優先級和測試的目的。只是一味的發現bug，使用自己都覺得很bt的方法發現了bug，但是這對于對產品質量的評價和決策能產生任何影響嗎?3)大家都是搞技術的，都不愿意接受別人的批評。如果受到了一些言語上的抨擊，開發人員更愿意將問題一直拖下去，而不承認自己的過失。所以人際關系的培養和交流技巧的訓練對測試人員也是很重要的。