有人說，測試者來自火星，開發者來自金星。這是因為軟件測試員和軟件開發者就好比一對冤家，里面的緣由說不清也道不明。開發代表着創造，而測試則代表着摧毀，因為測試的目的就是以各種方式不斷地從開發出的產品中發現大大小小的Bug，長此以往，開發者認為測試者是在故意找茬，兩者的矛盾慢慢就會產生。
敏捷之前項目中也有開發和測試，就如上文所說矛盾不少，比如測試測出一個bug，提單給開發，開發看了覺得這不是一個bug，實際業務過程中根本不會有這樣的操作方法。還有測試提了一個問題單，開發在下面回復已解決，測試回歸問題單的時候發現這個問題還存在，就質問開發這個問題沒有解決還存在，開發肯定會說這個問題我已經解決了，是不是你的程序版本不對，重新構建一次，測試重新獲取最新程序還是如此，開發因為任務重，同一個問題老是提過來肯定就會覺得煩，這樣來幾次就有可能吵起來。反正到最后開發覺得測試能力不行就只會找茬，真正的問題沒有測出來，盡糾結一些無關重要的問題。而測試覺得開發的功能質量不行，不支持他們的工作。
以前並沒有獨立的產品經理來寫需求，一般都是開發人員兼寫需求，然后給測試人員測，當出現需求方面的理解不一致的問題，肯定都是開發人員更有理，就算測試人員找到幾個不合理的需求，開發人員通常也不會虛心接受，反而覺得是在找自己的茬。所以在團隊中獨立出來產品經理負責所有需求是很有必要的，這樣產品經理、開發、測試三者之間形成三足鼎立是比較好的局面。
一般來說測試人員都不會自己從SVN下載代碼編譯生成程序，然后進行測試。而是開發人員把編譯好的程序和升級的數據庫腳本拷貝到服務器的公共文件夾，然后測試人員再從服務器拷貝下來，數據庫腳本在測試庫上執行，經常會出現開發人員漏拷程序文件和數據庫腳本，這樣測試的結果肯定失敗，然后開發找了半天原因發現只是漏了某個程序文件，然后就再循環一次。如此方式雙方協作的效率很低，浪費了大量時間。
還有就是開發在完成功能后，並沒有仔細進行自驗證，只要代碼編譯通過了，一些明顯錯誤沒有修正就丟給測試去進行測試，那測試隨便點兩下系統就走不通了，只好打回給開發，一個需求測試用例跑完得反反復復好幾次。
所以開發與測試之間要想好好協作，得雙方需求理解一致、運行程序一致、運行環境一致、數據庫一致，還要解決測試人員獲取測試版本的方便性。
為了保障開發和測試對需求理解一致，我們在敏捷過程中通過計划會、測試用例評審和開發ShowCase這幾個關鍵活動保障。計划會中產品經理講解需求，開發和測試都會參加，如果需求理解不一致的地方就馬上溝通由產品經理把關。到測試用例評審的時候，需求細化成一個個測試用例，這樣讓開發和測試進一步深化理解需求達成一致。到開發完成功能給測試Showcase，測試再一次核對開發實現功能與需求是否一致，明顯不一致的地方當場指出來，等開發人員修正后才提交給測試進行測試，這樣就基本能保證測試一次性就能跑完這個需求的所有測試用例。
運行程序、運行環境、數據庫保持一致，這個靠手工的方式是很難不出錯的，最好是通過一些工具來保障。我們團隊是使用Jenkins來做持續構建，開發人員完成功能開發，然后提交代碼到SVN，Jenkins檢測到代碼庫變動，自動拉取最新代碼進行編譯構建、發布程序，測試數據庫也自動還原成與開發數據庫一致。
我們團隊ShowCase的具體過程是這樣的，開發完成功能提交代碼后就通知測試進行ShowCase，這樣時候持續構建已經生成了最新的環境，然后開發在測試環境上向測試人員進行功能展示，開發會按照需求把自己開發的功能都詳細演示一遍，如果演示順利通過測試人員則回到座位進行用例執行，如果演示沒通過開發人員則繼續修改代碼完善直到演示通過為止。為什么開發一定要在測試環境上進行ShowCase，因為如果開發人員用自己的代碼進行演示的話，還是有可能會出現代碼效果與自動構建的程序不一致，所以為了避免這種情況，開發最好是在測試環境上進行演示。同樣測試執行用例后產生的BUG，測試會提問題單，問題單要有詳細的操作步驟與界面截圖，然后開發人員解決BUG后要對此BUG進行根因分析，是代碼邏輯錯誤還是需求理解問題，方便以后對BUG進行分析。BUG解決完后打回給測試的時候，開發也要進行ShowCase。
總之，現在覺得團隊中開發和測試之間的關系還比較好，協作也很流暢，現在看來確實還是方法不對，雖然知道問題的原因但苦於找不到對症下葯的辦法，如果你的團隊中也有類似情況可嘗試一下ShowCase這個方法也好。