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

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

　　但事實(shí)上，在實(shí)施TDD的過(guò)程中，在團隊中保留一定的QA仍然是必要的，這是因為某些變化或許會(huì )出乎你的意料。在上述關(guān)于TDD與QA的對話(huà)中，David Heinemeier Hansson說(shuō)道：“ 或許你已經(jīng)通過(guò)了所有測試，但或許它并沒(méi)有發(fā)現真正的問(wèn)題。一旦到了實(shí)際應用過(guò)程中，用戶(hù)會(huì )以你始料未及的方式使用你的應用。 ”

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

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

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

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

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

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

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

　　概念性的知識是創(chuàng )建高質(zhì)量應用的基本。要實(shí)現高可維護性，開(kāi)發(fā)者需要了解代碼整潔之道，而要掌握這方面知識需要多年的經(jīng)驗積累。如果我們想要精通這一領(lǐng)域的知識，接下來(lái)還可以學(xué)習設計模式、線(xiàn)程以及性能的原理。

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

　　在組建IT部門(mén)時(shí)，工作的分工是又一項要考慮的重點(diǎn)。在團隊的專(zhuān)業(yè)構成中，我們可以選擇由各領(lǐng)域的專(zhuān)家，例如由一位安全方面的專(zhuān)家、一位UX設計師和一位測試人員組成一個(gè)團隊，但這樣一來(lái)就沒(méi)有編碼者的位置了，結果就是團隊無(wú)法產(chǎn)出任何實(shí)際的東西。

　　反過(guò)來(lái)，我們也可以由多面手構成整個(gè)團隊，但這意味著(zhù)整個(gè)團隊必須將最好的光陰花費在學(xué)習上，除非他們都是天才。這樣的團隊同樣不會(huì )有很高的產(chǎn)出。

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

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

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

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