TDD團隊中的測試人員

　　測試驅動開發(TDD)是一種開發方式，它改變了傳統軟件開發的流程，即首先設計程序，再進行編碼與測試工作。TDD采取了很小的增量式開發方式：首先編寫一個測試，再編寫實際程序代碼以通過測試，最后對代碼進行改進。這種方式的結果是大量的(通?？蛇_到幾千個)自動化測試，能夠在幾秒鐘之內執行完畢。

　　測試人員需要注意到一點，這些高效的自動化單元測試剔除了大多數手工測試的執行。這樣一來，我們就需要重新反思是否有必要在TDD團隊中繼續保留測試人員的角色。

　　從表面上看，無論是否采用TDD，“測試人員”都是團隊中必不可少的角色，但實際情況要復雜得多，現在讓我們來看看這些復雜性體現在何處：

　　如果你打算開始嘗試TDD，那么建議你不要試圖在團隊中揉合老派的QA與功能測試人員。

　　如果你已經成功地實施了TDD，那么在團隊中安排一位專攻測試的成員仍然是有意義的。

　　在TDD中團隊中能夠取得成功的測試人員與傳統的功能測試人員的區別在于，前者具有更扎實的技術背景。

　　QA的興衰

　　在對“ TDD已死? ”這一主題所展開的一次對話中，Kent Beck(KB)、Martin Fowler(MF)與David Heinemeier Hansson(DHH)圍繞著QA與測試展開了激烈的討論。他們指出了專職測試人員歷史的3個發展階段：

　　堆積QA：通常指機能失調的QA部門，其中充斥著大量的功能測試人員。

　　摒棄QA：對于讓程序員負責測試的做法過于自信，在開發過程中摒棄測試人員。

　　當前現狀：在項目中引入適當的QA(甚至是功能性的)仍是有必要的。

　　流行于上世紀90年代的堆積QA的做法現在看來似乎已經過時了，許多IT組織已經解散了他們的QA部門，并將測試人員分派到各個敏捷團隊中。不過，在許多敏捷團隊中，這些測試人員仍在繼續著早期的手工測試任務。眾多組織仍然受困于延續自20年前的機能失調的測試方法。

　　老派的QA方式之所以出現機能失調的情況，是因為這種方式依賴于大量的功能測試人員。這些測試人員是手工測試方面的專家，但對于技術方面的技能知之甚少。測試人員的專業性決定了他們擅長于對功能的“測試”。但是，老派的QA部門更傾向于(同時也出于商業利益的考慮)讓這些測試人員對功能進行“檢查”。

　　“檢查”的主要特點在于：這種測試 完全 可以實現 自動化 (Bach 與Bolton 2013)。這就意味著“檢查”功能可以由程序員完成。至于是應該讓測試人員還是程序員進行功能“檢查”，這種選擇貌似隨意，其實不然：無論是發現 bug、進行隔離、匯報、跟蹤或是提出修復意見，測試人員都要花費更多的時間(Kaner 2001)。

　　通過手工測試人員對功能進行“檢查”的方式讓老派的QA變得非常低效。一旦團隊培養出“不要測試自己的代碼，把它丟給QA去做”這種觀念，測試工作就變得機能失調了(KB與DHH在這次對話中的觀點)。這種方式發展到一定程度，就會造成效率的不斷下降，隨著投入的測試人員越多，反而會造成bug數量的不斷升高。('Better Testing - Worse Quality'，Hendrickson 2001)

　　摒棄QA是對于手工測試這種機能失調的實踐的一種自然反應。之所以本文的標題沒有取名為“敏捷團隊中的測試人員”，是因為摒棄QA的做法在某些情況下并不可行，比如你的敏捷團隊雖然實施了Scrum框架，卻沒有進行任何自動化單元測試，又或是團隊正在進行某些商業現成品或技術(COTS)的軟件開發。如果團隊中沒有設立功能測試人員，則必須實施TDD實踐，或是其他任何一種能夠生成自動化單元測試的方法。

　　在大多數情形下，選擇了TDD就意味著你必須改變程序員的技能、習慣，并且往往還需要改變他們的態度與自我意識。而實現以上這幾點并不容易，同時 TDD本身也并非可以一促而就的：“要很好地掌握遺留代碼、對單元測試進行適當的隔離、以及集成測試是非常困難的”(Shore 2007)。根據評估，當程序員轉為采用TDD實踐后，前幾個月的生產力會急劇下降。不僅如此，對實踐TDD的新手往往要進行幾周乃至幾個月時間進行手把手的培訓(Larman，Vodde 2008)。

　　依我的經驗看來，老派的程序員與測試人員之間往往存在著一種共生現象。老派的程序員不喜歡進行單元測試，只要項目中有測試人員，他們就企圖蒙混過關。而老派的測試人員也不愿意學習技術知識，只要為程序員找到了足夠的bug，他們也同樣選擇應付了事。老派的程序員與測試人員都希望避免進行任何改變。因此，在我看來，如果程序員已經開始實施TDD實踐，再往團隊中安置一個功能測試人員就是一個壞主意。

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