英文原文：The Developer-Tester Divide

　　作者：Gil Zilberfeld 譯者：蔡堅安

　　從此以后他們幸福地生活在一起

　　關于開發人員和測試人員的關系，人們闡述了很多，討論了很多，爭論了很多。而貌似一旦這兩者坐在一起，對峙便開始了，兩者間的爭論多于相互認同。顯然，這不利于實現兩者合作的目標——向用戶提供價值。

　　讓我們來分析事情的來龍去脈和現狀，思考如何做得更好。

　　史前時期

　　在最開始，不存在測試人員，只有開發人員。軟件開發人員和軟件項目的其他人員比起來并沒有特別大的不同，除了如下事實：他們是軟件項目的主要成本。準確地 說這里的成本并不完全是指開發人員自身(雖然那時優秀的開發人員并不好找)，而是開發時間以及運行軟件所需的資源（比如巨型計算機）。從經濟角度考慮，專 門成立測試人員是行不通的：開發軟件的時間如此昂貴，為測試人員分配時間顯得很浪費。

　　沒有專門人員檢查工作，軟件開發人員只好自己做測試。因為開發軟件的時間如此昂貴，他們通過檢查日志、打印信息以及離線“調試”來確保軟件正常運行。那時 還沒有可用于調試的IDE，開發時間如此昂貴，可不能在查看成百上千頁的打印數據上花費太多的時間。因此檢查數據的人都是開發人員，這樣大家使用彼此熟悉 的術語，對問題心知肚明。這樣，盡管速度還不夠快，但整個團隊能夠和諧地前進，。

　　開始分裂

　　隨著軟件行業的高速發展以及計算機成本的降低，軟件公司在考慮成本的同時也開始關注軟件質量。軟件使用者開始變得挑剔，他們經常在初次使用時就不滿意，要求軟件公司修復或改善他們所購買的軟件。

　　保證軟件質量的方案之一就是驗收測試：客戶在軟件系統上執行應用場景。這些場景就像是軟件公司和客戶之間的契約：軟件系統只有通過這些場景測試才能夠被客戶接受。

　　最初，開發人員會自己執行驗收測試，或者由客戶執行驗收測試，然后將問題反饋給開發人員。但軟件公司很快就意識到開發人員不擅長于處理和客戶的關系，于是隔離客戶和開發團隊的想法開始萌芽。

　　存在的問題不僅僅是客戶和開發人員之間的溝通。因為驗收測試有時無法達到預期效果，人們越來越意識到應該對開發團隊進行更加嚴格的質量監控。若由其他團隊 的開發人員進行質量監控，則會導致軟件成本增加；而進行質量監控不需要理解錯綜復雜的軟件是如何工作的，因此軟件測試人員這個職業便產生了。

　　當然，這種組織結構的變化并不是自然而然產生的，組織結構變化需要管理上的支撐和協調。所以經過幾年的發展，軟件項目中開發人員和測試人員兩種角色的界限還是不清晰，

　　隨著軟件測試領域的發展，越來越多的測試人員需要提升自身的技能，于是開始產生了相關的方法論和培訓需求。培訓和認證機構看到了這個市場機會，開始提供測 試人員以及開發人員培訓服務。隨著方法論的逐漸成熟，測試專家開始涌現。之后開發和測試領域都有各自的專家，開發人員和測試人員的界限清晰起來了。

　　雙城記

　　開發人員和工作人員在思維和工作方式上截然不同。開發人員認為自己是創新家，他們從無到有創建出軟件，卻常常招測試人員指手畫腳。另一方面，測試人員苦苦 忍耐開發進度，而當終于從開發人員手里接過軟件時卻發現軟件是個廢物。質量始終難以過關，測試人員重復測試出主要應用場景的錯誤，花費了不少時間。由于時 間有限，很多應用程序沒能完全通過測試。

　　開發人員認為測試人員就是敵人，因此可能會把軟件發布拋在腦后，使出渾身解術避開測試人員。測試人員認為開發人員不夠專業，產生了很多本可以避免的bug。軟件團隊中彌漫者諸多不信任。

　　軟件公司中的這兩個黨派之間還存在另一個問題：軟件需求以及測試場景的溝通問題。因為思維方式的差異和語言的歧義性，軟件需求經過再次表述，接著再次被理解，結果和實際會有很大出入。而這些理解上的出入直到測試階段才被發現，相互指責隨之爆發。

　　最后一個會引發兩黨沖突的問題是時間鴻溝。開發人員說可以測了，測試人員便開始測試，開發人員接著進行新功能的開發以保持生產率。然而，當測試人員報告bug時開發人員的開發工作被擾亂了，開發人員開始抱怨測試人員見縫插針，指手畫腳。

　　開發派和測試派之間的緊張局勢顯然不利于減少浪費和產生有價值的產品。兩派之間的沖突導致了重復工作，相互指責，而軟件產品難以有見光的一天。

　　敏捷之橋

　　敏捷實踐一開始就以開發出能良好運轉的軟件作為目標。這是很重要的一步：敏捷宣言的倡導者來自軟件行業的各個領域（開發人員、測試人員和管理人員），他們把業務價值放在第一位，任何事情都應以它為依托。

　　“完整團隊”是其解決方案，這是試圖將客戶和開發團隊捆綁在一起的極限編程實踐。敏捷組織也有測試人員的概念。

　　因為開發人員與測試人員有了共同點并需要緊密協作，他們恢復了之前抗拒的行為：交流。

　　他們開始使用相同的術語交流需求是什么。語言障礙消除了，雙方在應該怎樣做和哪些事情還未解決上達成一致。

　　最重要的是，在一個sprint中，功能特性被開發和測試，所有發現的bug都被修正。這樣，開發人員和測試人員之間的時間鴻溝消失了，因為他們始終在相同的迭代周期中協作。

　　當開發人員和測試人員在同一迭代周期中協作時，他們發現了更好的情況：測試人員在流程早期捕獲錯誤和決定怎么處理，這樣對開發工作產生正面的推動，開發人 員也從迭代中受益：在sprint中捕獲和修正的bug都不算是真正的“bug”，只有逃脫出迭代周期的bug才會被當作真正的bug記錄下來——開發人 員可不愿意成天被別人說自己開發的軟件是有bug的。

　　改造

　　敏捷團隊實踐也產生了奇特的社會學副作用：開發人員和測試人員之間的界限不再清晰。敏捷團隊中開發人員做著各種各樣的事情，他們介于開發人員和測試人員之 間。開發人員開始參與測試，而測試人員則學會了怎樣開發以及怎樣編寫代碼做自動化測試。沒有人能夠做所有事情，但每個人都學會了額外的技能。

　　另一個邊際效應是軟件質量的提升。敏捷實踐認為每個人都應該關注質量。開發人員肩負起本來的職責：保證他們的代碼能夠正常運行。軟件質量提高了，測試人員則可以在一般性測試之后開始探索式測試，使軟件質量更上一層樓。

　　美好結局？

　　試圖獲得成功的敏捷團隊還一直處于發展變化之中。敏捷軟件公司正在嘗試創建功能特性團隊，這樣的團隊不僅僅由開發人員和測試人員組成，還包括了其他角色。

　　但這樣的公司還是少數。大多數公司還沒有涉及真正的協同敏捷軟件開發。開發人員和測試人員仍然被相互隔離，他們認為從業務角度考量這兩種角色就應該被分開。

　　敏捷實踐已經證實，通過流程以及協作可以打破開發人員和測試人員之間的隔閡。成功的敏捷實踐必然包括開發團隊和測試團隊的融合。沒有重新組織以使兩者融合，是不可能獲得成功的，或者用敏捷的術語：不可能獲得良好運轉的軟件。

　　關于作者

　　Gil Zilberfeld 是Typemock公司的產品經理。在15年的軟件開發之旅中，Gil經歷了軟件開發的各個方面，從編碼到團隊管理，再到流程實現。Gil在演講和博客中談論單元測試，鼓勵初級和高級開發人員在他們的項目把單元測試作為核心實踐。你可以通過電子郵件gilz@typemock.com和他的博客聯系他。

it知識庫：開發人員與測試人員的劃分，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。