TDD團隊中的測試人員(2)

　　我在多年的經驗中觀察到了這種反模式：如果你打算采用TDD或其他某種由開發者進行測試的實踐，那么僅僅是因為在團隊中出現了一位功能測試人員，就會讓你的努力付諸東流。因此，如果你確實計劃實施TDD，我的建議是從團隊中取消功能測試人員的角色!

　　但事實上，在實施TDD的過程中，在團隊中保留一定的QA仍然是必要的，這是因為某些變化或許會出乎你的意料。在上述關于TDD與QA的對話中，David Heinemeier Hansson說道：“ 或許你已經通過了所有測試，但或許它并沒有發現真正的問題。一旦到了實際應用過程中，用戶會以你始料未及的方式使用你的應用。 ”

　　Martin Fowler十分贊同David的觀點，但在同一番對話中，Kent Beck的措詞顯得更為謹慎。但他也同意，在QA這方面，“ 事情的發展已經趨向于另一個極端 ”。如果你無法預見到所有的可能性，那么從外部獲取某些反饋的做法“非常有意義”。

　　TDD團隊中的測試與團隊組成

　　在以上對話的最后，我們已意識到在TDD的實施中，除了在編程過程中所創建的測試外，進行一定其他形式的測試工作仍是有意義的。敏捷測試的概念在 “敏捷測試”(Crispin，Gregory 2009)等書籍中進行了詳盡的描述。但實施敏捷測試是否仍然需要“測試人員”，即專業從事測試的員工，人們對于這一點似乎還有爭論。Google仍然有數百名測試人員，而Facebook幾乎完全沒有設立測試人員的職位。

　　而普通的公司則有著不同的考慮，他們必須保證員工已掌握了工具與概念方面的知識以開發并維護各種應用，并確保高效的分工。讓我們實際分析一下在Java環境中引入測試人員意味著什么。

　　支持Java的TDD工具包括JUnit與某種模擬測試框架，一般的開發者都能夠掌握這些工具。不過，JUnit框架不僅支持在Java環境中應用TDD，它還表現出了測試工作的第二次革新：它不僅支持自動化單元測試，還支持其他各種測試的自動化。

　　JUnit目前還支持運行：通過JAX-RS實現的集成測試、自動驗收測試、基于Selenium Webdriver的UI測試、以及支持各種數據集的參數化測試等等。并且這些測試都能夠與持續集成(CI)方案進行整合。

　　除了這些測試工具之外，其他各種工具與框架也大量涌現?？梢哉f，一般的開發者很難掌握在一個普通的現代化項目中所用到的全部工具。

　　概念性的知識是創建高質量應用的基本。要實現高可維護性，開發者需要了解代碼整潔之道，而要掌握這方面知識需要多年的經驗積累。如果我們想要精通這一領域的知識，接下來還可以學習設計模式、線程以及性能的原理。

　　準確的、可維護的以及高性能的代碼雖然十分重要，但他們并不能保證某個應用是可信賴的。為了彌補這方面的缺失，開發者還需要學習安全方面的知識。而為了創建一個能夠吸引用戶的應用，開發者還要了解UX方面的知識。最后，為了設計一種高效的方式以保證以上所說的特性，開發者還需要熟悉測試的知識。

　　在組建IT部門時，工作的分工是又一項要考慮的重點。在團隊的專業構成中，我們可以選擇由各領域的專家，例如由一位安全方面的專家、一位UX設計師和一位測試人員組成一個團隊，但這樣一來就沒有編碼者的位置了，結果就是團隊無法產出任何實際的東西。

　　反過來，我們也可以由多面手構成整個團隊，但這意味著整個團隊必須將最好的光陰花費在學習上，除非他們都是天才。這樣的團隊同樣不會有很高的產出。

　　因此，我們的結論是在開發團隊中有必要引入部分專利性。我們不能指望每個開發者不僅能夠掌握全部的工具，并且還是整潔代碼、UX以及安全和測試方面的專家。另一方面，在團隊中引入的專家數量也應有所限制。

　　既然我們必須引入一定的專業性，那么設置一位測試專家是比較有意義的：對于開發者來說，如果讓他們來選擇，那么大多數人不會去探索單元測試之外的內容，甚至有很多人根本不愿意承擔任何測試工作。這也是為什么許多開發者不喜歡、甚至是厭惡測試的原因。如果要在這種環境中嘗試轉變為敏捷測試實踐，那么就需要設立一位對于測試工作有熱情并樂于實現它的專家。

　　與TDD的實施類似，以上過程同樣需要他人的指導，并且向團隊展示其工作結果。如果某位測試專家創建了對某個服務的測試集，并且能夠從IDE中執行，那么程序員就很可能會去使用。不僅如此，如果開發者感受到了測試的實用性，那么他們就會開始擴展其功能，并以可維護的方式實現。一旦為測試所觸動之后，程序員就會愿意繼續進行測試。但以我的經驗來看，僅靠程序員自己是無法感受到測試的好處的。

原文轉自：http://www.infoq.com/cn/articles/testers-TDD-teams