而在另一方，測試員注重于求證和懷疑。測試員對所有設計出來的東西都不信任，他們用自己掌握的知識照亮了決策中的黑暗一角，那正是別人未知或否認的。（測試員的座右銘是：“萬物皆有缺陷，我能找到它們！”）
把這兩種人－樂觀者和懷疑者－聚在一起，以雙方才智的協同之力開發出更好的軟件是可能的，但這種情況很少發生。通常每個人都在走極端，成了狹隘的程序員或測試員，充斥著樂觀或悲觀的情緒，卻從來不愿退一步考慮雙方觀點中的可取之處。程序代碼成為團隊政治的犧牲品，在雙方的隔閡間被扔來扔去。等到項目結束，團隊花在爭論怎樣做事上的時間超出了真正做事的時間。
結束程序員和測試員間爭斗的最好辦法是重新確定工作目標，讓他們的角色關系成為協作而不是對抗。雖然可以用許多種不同的形式組建開發團隊，甚至有可能不設專職的測試員（有人說一個稱職的軟件工程師才是質量保證的根本），本文仍假定你屬于常見的大中型開發團隊，在這樣的團隊中有一些專職的測試或質量保障角色。
使責任與權利相符
測試員或質量保障人員面臨的挑戰之一是：他們通常對軟件的質量負有責任，但對軟件的設計卻施加不了多少影響。在最糟糕的情況下，編程組的工作先于測試組數周開始，在測試組介入前已編寫了大量代碼。這不能算是質量保障，而是所謂的信任（“我向你保證代碼質量會很高”），他們的測試實際上是在為質量打補�。ā爸灰憬唤o我，我就會盡我所能把代碼質量提高”）。試圖以滯后的測試、少量的資源投入來做質量保障，這其實無異于在說辦不到。
最小化測試與開發間沖突的最簡單的辦法，就是讓測試組擁有能履行其職責的足夠權利。既要給他們充分授權，以便他們在軟件初期設計階段能夠參與或提供反饋，也要對他們這一角色應有的限制達成共識。但如果你讓測試組夾在中間，責任很大而權利很小或沒有，那么他們注定會使整個項目陷入混亂而導致失敗。我不是在主張由測試員統領一切，而是說他們的責任應該與他們的權利大致平衡。
我所見過的最好的團隊都是在一開始就進入了他們各自的角色。測試員、程序員以及其余的人都會盡早說明他們認為項目中哪些是重要的，他們的專長如何能得以施展。如果團隊里有些好主管，他們就會在如何決策上達成一致，即哪些事情適合由程序員決定，哪些事情適合由測試員決定，還有哪些是由雙方或多方共同決定。
盡早開始合作
如果你希望人們在工作中能相互配合，就必須給他們充分的時間以建立起工作關系。你不會與自己不甚了解的人一起分擔重要的事（設想一下你把自己最隱秘的恐懼告訴郵遞員，他不會認為你是認真的；更糟糕的是，你可能再也收不到信件了）。如果這就是人類本性的真相，那你就不會對程序員不滿于測試員的介入感到奇怪了。如果只在項目中的某一個月份測試員才出現并尋找缺陷，他們就會遇到阻力。程序員編寫的代碼的質量－這是他們的驕傲之源－被完全處于局外的人所挑戰，此時測試員就會被當作威脅而不是支持。
所以說，程序員與測試員應當從第一天起就協同工作。他們一起開會討論想從對方那里得到什么，以及他們希望對方做哪些事情。他們會根據項目目標或工作任務列表來安排工作的優先級并做出影響雙方的決策。在日常工作中，程序員總會把測試員的工作看作是幫助他提高工作質量的一種方式，這增強了他的自信心。測試員不再是挑毛病、列缺陷的局外人（“爛程序員，真爛！”），與此相反，他們成為一個局內人、一個合作者，他們對程序員的工作所給予的密切幫助無人能及。
或許最為重要的是，盡早建立起程序員和測試員之間的工作關系，這會打造出一個使項目能夠經受艱難時刻所需的紐帶。在項目后期問題出現、壓力加大，他們將有一段彼此信任的經歷。他們會尋求解決方案應對壓力和新的挑戰，而不是指責對方。
帶著質量意識編程
通常程序員和測試員在質量的含義上有著非常不同的見解。不只是他們，人們有關質量的爭論已經持續了幾百年，至今也未取得多少進展（參見Pirsig的《禪與摩托車維護的藝術》）。不要指望能找到一個永遠正確的答案，那是不可能的事。質量是有高度主觀性的，而且對于不同的項目其含義也會不同。主管們要做的是為當前的項目在質量問題上達成一致，避免哲學式的爭吵，而不是去尋求一個唯一的答案。
精明的團隊很早就對質量進行明確。他們知道在項目后期他們需要通過測試用例找出Bug并評估進展，他們決定不等到結束的時候再去處理這些事情�？梢栽陧椖砍跗诰妥龀鲇嘘P質量的決策。
測試驅動式開發（TDD）是一種流行的在初期就引入質量管理的開發模式，它使測試及質量保障與每個功能特性的設計結為一體。測試用例（軟件在發布前必須滿足的條件）在編寫代碼前就已被創建，以確定代碼應達到的條件。既然你不會蠢到開車的時候不知道要去哪兒，為什么要在你還沒明確目標之前就開始編碼呢（除非你喜歡在公路上閑逛或者編的是些簡單代碼）？
TDD的精髓適用于各種類型的工作。如果你能盡早確定最終要實現的各種特性并把它通知給其他人，成功的機率就會升高。這就是從各項分工的角度將結果分解，使每個人都能最大程度地運用各自的技能幫助項目達到目標。
只有主管能發動和結束戰爭
戰爭史清楚地表明了一點：是那些大權在握者制造了導致戰爭的因素。不管對妥協是懼怕還是拒絕，主管都有能力發動和結束沖突。測試員和程序員沒什么差別，如果在開發團隊中發生沖突，就要從主管身上找原因。
高級程序員和高級測試員之間的關系為組織中其余的人定了調子。如果一方對另一方不予理睬、嘲笑或耍威風，那另一方也會跟著這么做。主管確立行為準則－某個角色的工作該如何去做，他該如何對待其他的角色。這也同樣適用于團隊的管理者，管理所有程序員和測試員的人的行為將確定組織中每個人的行為準則。
為改善測試員和程序員之間的關系，雙方的主管需要對局勢負起責任，這類事情要比那些技術類的工作擁有更高的優先級。本文及以前有關于這方面的文章有助于為解決此類問題提供一些思路。不過只有當主管們敢于進取，明智地承認這些問題，并帶領雙方制定一個如何改變的協作計劃，這一切才會真正得以改進。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
