【敏捷】7.showcase，開發中必須引發重視的小環節

有人說，測試者來自火星，開發者來自金星。這是由於軟件測試員和軟件開發者就比如一對冤家，裏面的原因說不清也道不明。開發表明着創造，而測試則表明着摧毀，由於測試的目的就是以各類方式不斷地從開發出的產品中發現大大小小的Bug，久而久之，開發者認爲測試者是在故意找茬，二者的矛盾慢慢就會產生。

    
    敏捷以前項目中也有開發和測試，就如上文所說矛盾很多，好比測試測出一個bug，提單給開發，開發看了以爲這不是一個bug，實際業務過程當中根本不會有這樣的操做方法。還有測試提了一個問題單，開發在下面回覆已解決，測試迴歸問題單的時候發現這個問題還存在，就質問開發這個問題沒有解決還存在，開發確定會說這個問題我已經解決了，是否是你的程序版本不對，從新構建一次，測試從新獲取最新程序仍是如此，開發由於任務重，同一個問題總是提過來確定就會以爲煩，這樣來幾回就有可能吵起來。反正到最後開發以爲測試能力不行就只會找茬，真正的問題沒有測出來，盡糾結一些無關重要的問題。而測試以爲開發的功能質量不行，不支持他們的工做。

    之前並無獨立的產品經理來寫需求，通常都是開發人員兼寫需求，而後給測試人員測，當出現需求方面的理解不一致的問題，確定都是開發人員更有理，就算測試人員找到幾個不合理的需求，開發人員一般也不會虛心接受，反而以爲是在找本身的茬。因此在團隊中獨立出來產品經理負責全部需求是頗有必要的，這樣產品經理、開發、測試三者之間造成三足鼎立是比較好的局面。

    通常來講測試人員都不會本身從SVN下載代碼編譯生成程序，而後進行測試。而是開發人員把編譯好的程序和升級的數據庫腳本拷貝到服務器的公共文件夾，而後測試人員再從服務器拷貝下來，數據庫腳本在測試庫上執行，常常會出現開發人員漏拷程序文件和數據庫腳本，這樣測試的結果確定失敗，而後開發找了半天緣由發現只是漏了某個程序文件，而後就再循環一次。如此方式雙方協做的效率很低，浪費了大量時間。

    還有就是開發在完成功能後，並無仔細進行自驗證，只要代碼編譯經過了，一些明顯錯誤沒有修正就丟給測試去進行測試，那測試隨便點兩下系統就走不通了，只好打回給開發，一個需求測試用例跑完得反反覆覆好幾回。

 

    因此開發與測試之間要想好好協做，得雙方需求理解一致、運行程序一致、運行環境一致、數據庫一致，還要解決測試人員獲取測試版本的方便性。

    爲了保障開發和測試對需求理解一致，咱們在敏捷過程當中經過計劃會、測試用例評審和開發ShowCase這幾個關鍵活動保障。計劃會中產品經理講解需求，開發和測試都會參加，若是需求理解不一致的地方就立刻溝通由產品經理把關。到測試用例評審的時候，需求細化成一個個測試用例，這樣讓開發和測試進一步深化理解需求達成一致。到開發完成功能給測試Showcase，測試再一次覈對開發實現功能與需求是否一致，明顯不一致的地方當場指出來，等開發人員修正後才提交給測試進行測試，這樣就基本能保證測試一次性就能跑完這個需求的全部測試用例。

    運行程序、運行環境、數據庫保持一致，這個靠手工的方式是很難不出錯的，最好是經過一些工具來保障。咱們團隊是使用Jenkins來作持續構建，開發人員完成功能開發，而後提交代碼到SVN，Jenkins檢測到代碼庫變更，自動拉取最新代碼進行編譯構建、發佈程序，測試數據庫也自動還原成與開發數據庫一致。

    咱們團隊ShowCase的具體過程是這樣的，開發完成功能提交代碼後就通知測試進行ShowCase，這樣時候持續構建已經生成了最新的環境，而後開發在測試環境上向測試人員進行功能展現，開發會按照需求把本身開發的功能都詳細演示一遍，若是演示順利經過測試人員則回到座位進行用例執行，若是演示沒經過開發人員則繼續修改代碼完善直到演示經過爲止。爲何開發必定要在測試環境上進行ShowCase，由於若是開發人員用本身的代碼進行演示的話，仍是有可能會出現代碼效果與自動構建的程序不一致，因此爲了不這種狀況，開發最好是在測試環境上進行演示。一樣測試執行用例後產生的BUG，測試會提問題單，問題單要有詳細的操做步驟與界面截圖，而後開發人員解決BUG後要對此BUG進行根因分析，是代碼邏輯錯誤仍是需求理解問題，方便之後對BUG進行分析。BUG解決完後打回給測試的時候，開發也要進行ShowCase。

    總之，如今以爲團隊中開發和測試之間的關係還比較好，協做也很流暢，如今看來確實仍是方法不對，雖然知道問題的緣由但苦於找不到對症下藥的辦法，若是你的團隊中也有相似狀況可嘗試一下ShowCase這個方法也好。

    敏捷開發系列文章目錄