本文章轉載于搜狗測試
在看過了一些有些的關于敏捷測試的文章（比如這篇），聽了許多人在談論敏捷測試后，我開始意識到敏捷測試跟自己一開始的理解并不太一致。
從一個問題問起
你認為什么樣的團隊適合打造成敏捷測試團隊？
不知道你看到這樣的問題時，會怎樣去想？或者不妨你可以用幾秒鐘的時間來想一想這個問題。倒計時，5，4，3，2，1……
叮！時間到。筆者一開始接觸到敏捷測試的概念的時候，其實是陷入了一個狹隘的誤區（產生了一個誤解），認為敏捷測試團隊是為“測試（QA）”團隊提出的概念，是為了改變現有測試團隊的問題而誕生的。其實這是錯誤的。我們先來看一看敏捷團隊的基本特征之一：
按照在采用敏捷軟件開發方式的組織中，配合敏捷軟件開發團隊進行測試的整體方法。在這樣的組織里，通常來說，都不會存在一個專職只做軟件測試的部門，因為測試被內嵌入整體研發過程，并且“開發人員”、“測試人員”這些角色的概念和邊界也被模糊化，你中有我、我中有你，有基本的分工，但更重視的是彼此合作以便達成團隊（甚至部門、產品、組織）的整體目標。——徐毅，https://www.zhihu.com/question/20074110/answer/15940193
這是來自知乎的一個回答（的一部分），同樣的，《敏捷軟件測試：測試人員與敏捷團隊的實踐指南》（下稱“指南”）也提出了這樣的思想。即不存在所謂的“敏捷測試團隊”（傳統意義的測試），只存在“敏捷團隊”。在這樣的團隊中，每一個人都參與到了“測試”這樣的活動中。
這樣的團隊有什么樣的特點呢？我們說幾個團隊文化上非常明顯的。（詳細可參考“指南”第3章）
首先，質量上，“以如何定義軟件質量的可接受水平的角度來思考組織的質量哲學”。在傳統的測試中，我們經常可能會出現這樣的一些評估標準，例如“BUG修復率達到85+%，是達到上線的標準”，“所有的崩潰必須全部修復，才能上線”，“測試認為這個問題非常嚴重，不能帶到線上”等。而在敏捷的思想里面，這些都是視具體情況而進行評估的。
其次，整個團隊負責質量。當敏捷團隊實際運轉起來時，團隊中的每一個人都參與了質量的保證，不論是產品、開發，還是測試。
第三，合適的節奏。敏捷團隊中整體的團隊速度是一致的，不存在傳統測試中經常發生的場景：開發提測后，只剩下測試在拼命的加班完成后續任務。敏捷團隊中依賴大家以最好的狀態進行工作，高強度的工作并不是常態，加班只是特例。
第四，有效的溝通方式。傳統測試中經常遇到一些實際的困難，例如開發團隊在A地辦公，而測試團隊卻在B地辦公；或者與一些第三方的公司/團隊配合的時候，也需要有效的溝通。敏捷的思路非常強調溝通的連續和有效。通過晨會，通過溝通工具改善，通過角色的轉換來保證溝通的高效。
這樣的團隊中，難免也會出現文化的沖突，尤其當涉及到專家團隊的利益時，或者第三方團隊的文化產生沖突時。
那作為傳統的測試團隊，我們需要克服哪些障礙，才能更適應敏捷團隊呢？
適應敏捷團隊需要克服的障礙
喪失身份
由于眾多的原因，測試人員堅持組織擁有獨立的質量保證團隊。經常會擔心優先權被開發搶走，害怕缺乏敏捷所需的技能而失去競爭力，害怕在新的團隊中迷失方向，害怕在開發團隊中得不到支持等。這些是我們需要克服的第一個障礙。
缺乏培訓
在敏捷團隊中，如果沒有經過有經驗的人的良好培訓，可能會發生一些遺憾的情況，例如會有人因為不理解或者不適應自己的新角色而放棄。這樣的團隊中，尤其是團隊建設初期，有效的培訓是必要的。
過去的經驗/觀點
當習慣、并樂于過去的經驗、項目迭代、溝通方式、軟件發布理念時，敏捷這樣的新概念就難以理解，認為改變的成本高，看不到明顯的意義。并且當敏捷推進產生困難時，這樣的角色就會發出尖銳的疑問。甚至拒絕再給敏捷嘗試的機會。
額外的角色
在敏捷團隊創建之初的時候，需要思考的一個很重要的問題是，團隊中需要什么樣的角色。為了保證敏捷團隊更好的運轉，我們有可能需要再增加一名開發，或者一名性能測試工程師，或者一名敏捷測試的有經驗指導人員等等。合理的規劃和構想團隊的組成，對團隊的敏捷實施是重要的。
