敏捷測試中理想的測試組織

　　近些年，在軟件項目中非常流行一個詞——敏捷。大大小小的項目，通常都包含著"敏捷"這個關鍵字。其實敏捷本身是一種優化的思想，是軟件工程發展到一定階段后的產物。面對風云變幻的市場，都希望迅速響應市場或客戶的變化。但如何真正在項目中做到敏捷，除了方法論之外，還有各種外部條件的制約。而現實是很多研發團隊只注重了方法論的學習，而沒注意組織結構應該如何變化才能適應敏捷測試的需要。有的人可能會說，敏捷強調的不是人人都應該是開發和測試嗎?但這只是在理想情況中。真實項目中，肯定還是存在測試和開發的分工的。所以本文想談談在敏捷測試中，我們的測試組織應該如何建設，才能合理將工作進行分工，充分發揮組織內部每個人的長處。即在敏捷測試環境中，我們應該用什么樣的人，去做什么樣的事，才能獲得最大的效率。

　　當考慮團隊的組織結構時離不開兩點考慮：要做什么事以及要什么樣的人去做這些事。其實很多人對敏捷測試并不太熟悉，甚至不知道談到敏捷測試，我們究竟指的是哪些測試，要怎么做才能使測試敏捷起來。所以我們先來看看第一個問題：要做什么事，也就是說當我們談到敏捷測試時，我們究竟談了些什么。

　　在一本比較著名的講解敏捷測試實踐的書《A Practical Guide for Testers and Agile Teams》中，明確將敏捷測試的所有測試類型劃分為了四個象限的測試，按照測試內容來分，可以主要分為面向技術(Technology-Facing)和面向業務(Business-Facing)的測試。在面向技術的測試中，主要包括我們熟悉的 Unit/Component 測試，PSR(Performance， Security， Reliability)測試，Usability 測試等等。而在面向業務的測試中，主要包括手動的探索性測試，User-story 和系統測試，以及自動化的 BAT 和回歸測試等等。由于這里所講的測試類型的特點都會跟什么樣的人去做有很大的聯系，所以在接下來的部分我再詳細討論各種測試的特點。

　　知道了敏捷測試究竟在做什么，也就是它所指的范圍(Scope)之后，我們接下來就可以根據所要做的這些事的特點，再去甄選合適的人去完成它。這里需要注意的一個原則是：盡量發揮每個人的特長，讓專業的人去做專業的事，殺雞用牛刀是不可取的。如圖 1：敏捷開發組織架構圖，再來看看為什么安排這些人去做這些事。

　　圖 1. 敏捷開發組織架構圖

　　首先是面向技術的測試。為什么是面向技術呢?因為這些測試類型都是需要深入到代碼級或者是需要工具去實現的，而且跟具體的業務邏輯和業務流程關系不大。

　　Unit/Component 測試(負責人：開發人員)

　　這部分的測試由開發人員自己完成。原因很簡單，開發人員最清楚代碼的結構和代碼邏輯。我們完全不必專門安排所謂的白盒測試或者單元測試工程師去幫開發去完成這些事，這些是他們應該完成的事，往大了說就是每個人都應該為質量負責。而且，特別是在測試驅動開發的模式中，我們更是絕對不能讓測試人員越俎代庖地去做這些事，那樣做是得不償失的。因為如果不是由開發人員自己去寫的測試代碼，那么到時出了錯，要想 debug 或者是找 root cause 的話，將會花費更多的代價。所以記住在測試驅動開發模式下，開發和測試那塊根本就沒測試人員什么事，作為測試人員大可不必想著一定要讀懂代碼，從老板或者是組織管理者的角度看的，那簡直就是浪費錢，測試人員應該做的是，如何更好地幫助開發去理解需求，也就是敏捷中常說的 user-story，以及如何設計測試來驗證產品是否真正完成了這個 user-story，接下來面向業務的測試中還會說到這點。

　　回頁首

　　PSR 以及各種“ility”測試(負責人：相關測試類型專家)

　　性能、安全性以及各種用戶體驗啊，易用性健壯性測試對產品的重要性不言而喻，而這些測試類型往往又是非常專業的，復雜性程度相當高。要想做好，不僅僅是會用一點工具，會錄制下腳本，或者是懂看代碼就能實現的。它要求測試人員不僅對工具使用非常嫻熟，更重要的是要深入了解系統架構以及系統所運行環境的具體情況，如桌面程序，在安全性方面往往跟系統本身的安全性緊密相關，要求測試的人對所在的系統也要了如指掌，web 程序，性能瓶頸更是跟系統軟硬件，所用協議等密切相關，沒有對這些相關方面有系統地把握和學習，根本做不好。所以如果是組織內部有條件，可以由專門做這些非功能性系統測試的專家或者資深工程師負責這些類型的測試，才能得到比較理想的測試效果，不然最大的可能性就是走走過場而已，得不到實際的效果。

　　再來看看面向業務的測試。面向業務的測試是大部分測試人員所熟悉和了解的，但測試工程師也有好幾種類型，初級的，高級的，做自動化的，做手動的，該如何按照不同的測試類型來進行分配?

　　回頁首

　　ET/User-Story/System 測試(負責人：有經驗的 / 高級測試工程師)

　　在敏捷測試中，這幾種測試的重要性也是不言而喻的。像探索性測試在敏捷測試中，甚至超過了系統測試的重要性，是敏捷測試面向系統和業務的核心測試類型。探索性測試的特點是測試人員可以事先對被測系統沒有任何的了解，通過一邊學習一邊測試，快速地在有限時間內根據優先級最大限度地發現系統中存在的問題，所以說效率非常高。當然，同時對測試人員的要求也就非常高。它可以沒有測試用例，但一定有很多引導測試人員思考的 test idea，只有測試人員自身經驗非常豐富的情況下，他才有可能根據最少的線索，猜測最有可能發現 bug 的地方。并且快速學習和總結能力是個不可或缺的條件，這就注定了只能由經驗豐富的高級測試工程師才能勝任。User-story 分析要求測試人員具備良好地溝通和理解能力，能夠將客戶表達出來的或者潛在的客戶需求轉換為我們的用戶"故事"和業務邏輯的描述，供開發人員進行參考。系統測試就不說了，大家都很了解，需要對被測系統有深入全面的了解所以在這幾個測試類型中，是對測試工程師能力的一個綜合考驗，雖然沒有涉及到代碼以及自動化，但必須要求測試經驗豐富，測試方法掌握扎實，對業務精通的人員來進行。

　　回頁首

原文轉自：http://www.ibm.com/developerworks/cn/rational/r-cn-agiletestorganization/