而在另一方，測試員注重于求證和懷疑。測試員對所有設計出來的東西都不信任，他們用自己掌握的知識照亮了決策中的黑暗一角，那正是別人未知或否認的。（測試員的座右銘是：“萬物皆有缺陷，我能找到它們！”）
把這兩種人－樂觀者和懷疑者－聚在一起，以雙方才智的協同之力開發出更好的軟件是可能的，但這種情況很少發生。通常每個人都在走極端，成了狹隘的程序員或測試員，充斥著樂觀或悲觀的情緒，卻從來不愿退一步考慮雙方觀點中的可取之處。程序代碼成為團隊政治的犧牲品，在雙方的隔閡間被扔來扔去。等到項目結束，團隊花在爭論怎樣做事上的時間超出了真正做事的時間。
結束程序員和測試員間爭斗的最好辦法是重新確定工作目標，讓他們的角色關系成為協作而不是對抗。雖然可以用許多種不同的形式組建開發團隊，甚至有可能不設專職的測試員（有人說一個稱職的軟件工程師才是質量保證的根本），本文仍假定你屬于常見的大中型開發團隊，在這樣的團隊中有一些專職的測試或質量保障角色。
使責任與權利相符
測試員或質量保障人員面臨的挑戰之一是：他們通常對軟件的質量負有責任，但對軟件的設計卻施加不了多少影響。在最糟糕的情況下，編程組的工作先于測試組數周開始，在測試組介入前已編寫了大量代碼。這不能算是質量保障，而是所謂的信任（“我向你保證代碼質量會很高”），他們的測試實際上是在為質量打補�。ā爸灰憬唤o我，我就會盡我所能把代碼質量提高”）。試圖以滯后的測試、少量的資源投入來做質量保障，這其實無異于在說辦不到。
最小化測試與開發間沖突的最簡單的辦法，就是讓測試組擁有能履行其職責的足夠權利。既要給他們充分授權，以便他們在軟件初期設計階段能夠參與或提供反饋，也要對他們這一角色應有的限制達成共識。但如果你讓測試組夾在中間，責任很大而權利很小或沒有，那么他們注定會使整個項目陷入混亂而導致失敗。我不是在主張由測試員統領一切，而是說他們的責任應該與他們的權利大致平衡。
我所見過的最好的團隊都是在一開始就進入了他們各自的角色。測試員、程序員以及其余的人都會盡早說明他們認為項目中哪些是重要的，他們的專長如何能得以施展。如果團隊里有些好主管，他們就會在如何決策上達成一致，即哪些事情適合由程序員決定，哪些事情適合由測試員決定，還有哪些是由雙方或多方共同決定。
盡早開始合作
如果你希望人們在工作中能相互配合，就必須給他們充分的時間以建立起工作關系。你不會與自己不甚了解的人一起分擔重要的事（設想一下你把自己最隱秘的恐懼告訴郵遞員，他不會認為你是認真的；更糟糕的是，你可能再也收不到信件了）。如果這就是人類本性的真相，那你就不會對程序員不滿于測試員的介入感到奇怪了。如果只在項目中的某一個月份測試員才出現并尋找缺陷，他們就會遇到阻力。程序員編寫的代碼的質量－這是他們的驕傲之源－被完全處于局外的人所挑戰，此時測試員就會被當作威脅而不是支持。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
