敏捷宣言里面有這么一條：“個體和互動，勝過流程和工具”。我非常喜歡的一句，當然了敏捷宣言總共就那么幾句，總結都是非常精辟和智慧的，每一句都值得細細品味，就不展開說了。
這里的流程和工具顯然是直指前面我們提到的缺陷管理系統，所以在敏捷開發模式下我們很少看到有人使用CQ的（有很多項目號稱已經敏捷了，但還在繼續使用CQ這種重量級缺陷管理工具的，不計），測試人員和開發人員以及PO的交流更加緊密但輕量化。
這里把本文中的敏捷開發模式限定為最流行的 scrum + xp，scrum本身并沒有要求團隊一定要設置獨立的QA角色，但實際上在傳統開發模式往敏捷轉型的時候，原來獨立的測試人員都會被要求“測試前移”成為團隊中獨立的QA，所以從瀑布開發模式下轉型敏捷的團隊多半會設置獨立的QA，特別是在比較大型的組織。
以scrum為例我們先看一看敏捷團隊中QA在迭代的不同時機和不同的角色是怎么發生交互的，個人覺得這個是敏捷模式和傳統模式下最大的區別。
QA與團隊的交互
迭代n-1
在這個迭代中，QA需要和PO一起完成下個迭代用戶故事的準備，理解PO優先級排序的思路，確定每個用戶故事的驗收條件，一般這個時候一名合格的QA已經對這些用戶故事的測試重點和風險有了一定的了解。有的團隊沒有設置獨立的QA角色，那么這些工作就主要落在PO的頭上，或者開發團隊安排1-2個人，個人更傾向于PO來做這部分工作，因為定義用戶故事的驗收條件，確定開發團隊的輸出滿足自己的期望本身就是PO的分內之事(我想這也是scrum為什么沒有要求一定要設置QA角色原因)。
迭代n
迭代啟動之后，在Planning Meeting上QA會參與用戶故事的估算，特別對于測試部分的任務如果存在理解上的偏差時需要進行澄清，對驗收標準進行說明，以幫助開發人員正確理解用戶故事的意圖和邊界并做出準確的估算。
在迭代開發過程中，QA會進行FT用例的設計和編寫，在需要時解答開發人員對用戶故事細節的疑問（其實也是PO的職責，主要一般PO會比較忙很少在座位旁），優秀的QA還會參加集體代碼走查，或者通過獨自走查的方式來識別代碼中的設計缺陷或者風險。
一個用戶故事開發完成，QA需要和PO一起(這里又看到PO和QA角色的重疊)對用戶故事進行驗收，QA還會對用戶故事進行探索性測試（可能還有性能測試等）并反饋給開發人員進行修正，一般來說QA和開發人員是當面溝通，如果實在需要記錄bug也會直接采用便利貼、Jira等輕量級的工具，一旦開發人員修復了bug，QA則會立刻和開發人員一起進行驗證并關閉bug。
迭代最后一天，QA通常還需要準備本迭代的Review，雖然Review會議也可以讓其他人來準備，但如果有專職的QA的話讓專職QA來準備是更加合適的。Retrospective Meeting上開發人員和QA都可以反饋測試方面的問題，比如CI環境的穩定性，CI的修復速度，驗收標準是否明確，測試執行的是否有效，是否需要更新當前使用的測試技術，有什么問題阻礙了測試任務等等。
度量
在《敏捷軟件測試》中對于測試的四象限以及各種象限下如何評價進行了詳細說明，針對不同的測試類型會采用不同的度量指標，tbd
開發人員對測試的參與
對開發人員來說一個最大的不同是對 UT 的投入，如果要開發一個內部質量靠譜的產品，UT是不可或缺的，按照google的說法，ut/ft/st的比例應該達到 7/2/1，可見ut的重要性。比較好的團隊會堅持采用TDD的方式開發，保持比較高比例的代碼覆蓋，也會帶來良好的設計，這是另一個話題這里也不展開。
比較嚴謹的同學可能會說，即使是在瀑布式的開發模式下我們也可以做 UT，也可以做測試分層啊？我也不太確定UT算不算是XP實踐，不過以我個人這些年的經歷來看，在接觸敏捷之前還真沒有寫過UT（可能是我所在的公司比較low吧????）。
總結下不同點
這里可以看到敏捷開發模式下，測試和開發為了同一個目標在同一個團隊中工作，他們的關系是合作而非對立，在這個前提下，測試能夠真正回歸到原本的那個目標，我們得以回歸理性，更加客觀的來選擇測試策略和進行更高效的測試，比如度量指標可以更加科學，不必淪為不同團隊利益博弈的籌碼；通過不停的迭代和改進，測試人員的技能和團隊其他人員一樣能夠逐步提升，比如最新的測試設計方法的運用，測試工具的使用，自動化的運用，這些新的知識會給測試人員帶來成就感并幫助他們以更高效的方式工作，不僅僅是人肉測試機器；測試人員在組織中獲得和開發人員一樣平等的地位，獲得相同的尊重，而且，就像前面我們提到的一樣，QA的角色和PO的角色有很大部分重合，優秀的QA是整個團隊中對產品理解最深刻的那個人，就像《google軟件測試之道》一書中所說的，QA職業生涯的下一步就是產品經理。
說了這么多好處，看起來只要我們按敏捷的開發模式做下去就好了，那為什么還有標題里提到的敏捷轉型失敗之道呢？我們繼續往下面看。
