敏捷宣言里面有這么一條：“個體和互動辙培，勝過流程和工具”。我非常喜歡的一句邢锯，當然了敏捷宣言總共就那么幾句扬蕊，總結都是非常精辟和智慧的，每一句都值得細細品味丹擎，就不展開說了尾抑。
這里的流程和工具顯然是直指前面我們提到的缺陷管理系統(tǒng)歇父，所以在敏捷開發(fā)模式下我們很少看到有人使用CQ的（有很多項目號稱已經(jīng)敏捷了，但還在繼續(xù)使用CQ這種重量級缺陷管理工具的再愈，不計）榜苫，測試人員和開發(fā)人員以及PO的交流更加緊密但輕量化。
這里把本文中的敏捷開發(fā)模式限定為最流行的 scrum + xp翎冲，scrum本身并沒有要求團隊一定要設置獨立的QA角色垂睬，但實際上在傳統(tǒng)開發(fā)模式往敏捷轉型的時候，原來獨立的測試人員都會被要求“測試前移”成為團隊中獨立的QA抗悍，所以從瀑布開發(fā)模式下轉型敏捷的團隊多半會設置獨立的QA驹饺，特別是在比較大型的組織。
以scrum為例我們先看一看敏捷團隊中QA在迭代的不同時機和不同的角色是怎么發(fā)生交互的缴渊，個人覺得這個是敏捷模式和傳統(tǒng)模式下最大的區(qū)別赏壹。
QA與團隊的交互
迭代n-1
在這個迭代中，QA需要和PO一起完成下個迭代用戶故事的準備衔沼，理解PO優(yōu)先級排序的思路蝌借，確定每個用戶故事的驗收條件，一般這個時候一名合格的QA已經(jīng)對這些用戶故事的測試重點和風險有了一定的了解指蚁。有的團隊沒有設置獨立的QA角色菩佑，那么這些工作就主要落在PO的頭上，或者開發(fā)團隊安排1-2個人凝化，個人更傾向于PO來做這部分工作稍坯，因為定義用戶故事的驗收條件，確定開發(fā)團隊的輸出滿足自己的期望本身就是PO的分內之事(我想這也是scrum為什么沒有要求一定要設置QA角色原因)缘圈。
迭代n
迭代啟動之后，在Planning Meeting上QA會參與用戶故事的估算袜蚕，特別對于測試部分的任務如果存在理解上的偏差時需要進行澄清糟把，對驗收標準進行說明，以幫助開發(fā)人員正確理解用戶故事的意圖和邊界并做出準確的估算牲剃。
在迭代開發(fā)過程中遣疯，QA會進行FT用例的設計和編寫，在需要時解答開發(fā)人員對用戶故事細節(jié)的疑問（其實也是PO的職責凿傅，主要一般PO會比較忙很少在座位旁）缠犀，優(yōu)秀的QA還會參加集體代碼走查，或者通過獨自走查的方式來識別代碼中的設計缺陷或者風險聪舒。
一個用戶故事開發(fā)完成辨液，QA需要和PO一起(這里又看到PO和QA角色的重疊)對用戶故事進行驗收，QA還會對用戶故事進行探索性測試（可能還有性能測試等）并反饋給開發(fā)人員進行修正箱残，一般來說QA和開發(fā)人員是當面溝通滔迈，如果實在需要記錄bug也會直接采用便利貼止吁、Jira等輕量級的工具，一旦開發(fā)人員修復了bug燎悍，QA則會立刻和開發(fā)人員一起進行驗證并關閉bug敬惦。
迭代最后一天，QA通常還需要準備本迭代的Review谈山，雖然Review會議也可以讓其他人來準備俄删，但如果有專職的QA的話讓專職QA來準備是更加合適的。Retrospective Meeting上開發(fā)人員和QA都可以反饋測試方面的問題奏路，比如CI環(huán)境的穩(wěn)定性畴椰，CI的修復速度，驗收標準是否明確思劳，測試執(zhí)行的是否有效迅矛，是否需要更新當前使用的測試技術，有什么問題阻礙了測試任務等等潜叛。
度量
在《敏捷軟件測試》中對于測試的四象限以及各種象限下如何評價進行了詳細說明秽褒，針對不同的測試類型會采用不同的度量指標，tbd
開發(fā)人員對測試的參與
對開發(fā)人員來說一個最大的不同是對 UT 的投入威兜，如果要開發(fā)一個內部質量靠譜的產品销斟，UT是不可或缺的，按照google的說法椒舵，ut/ft/st的比例應該達到 7/2/1蚂踊，可見ut的重要性。比較好的團隊會堅持采用TDD的方式開發(fā)笔宿，保持比較高比例的代碼覆蓋犁钟，也會帶來良好的設計，這是另一個話題這里也不展開泼橘。
比較嚴謹?shù)耐瑢W可能會說涝动，即使是在瀑布式的開發(fā)模式下我們也可以做 UT，也可以做測試分層熬婷稹醋粟？我也不太確定UT算不算是XP實踐，不過以我個人這些年的經(jīng)歷來看重归，在接觸敏捷之前還真沒有寫過UT（可能是我所在的公司比較low吧????）米愿。
總結下不同點
這里可以看到敏捷開發(fā)模式下，測試和開發(fā)為了同一個目標在同一個團隊中工作鼻吮，他們的關系是合作而非對立育苟，在這個前提下，測試能夠真正回歸到原本的那個目標椎木，我們得以回歸理性宙搬，更加客觀的來選擇測試策略和進行更高效的測試笨腥，比如度量指標可以更加科學，不必淪為不同團隊利益博弈的籌碼勇垛；通過不停的迭代和改進脖母，測試人員的技能和團隊其他人員一樣能夠逐步提升，比如最新的測試設計方法的運用闲孤，測試工具的使用谆级，自動化的運用，這些新的知識會給測試人員帶來成就感并幫助他們以更高效的方式工作讼积，不僅僅是人肉測試機器肥照；測試人員在組織中獲得和開發(fā)人員一樣平等的地位，獲得相同的尊重勤众，而且舆绎，就像前面我們提到的一樣，QA的角色和PO的角色有很大部分重合们颜，優(yōu)秀的QA是整個團隊中對產品理解最深刻的那個人吕朵，就像《google軟件測試之道》一書中所說的，QA職業(yè)生涯的下一步就是產品經(jīng)理窥突。
說了這么多好處努溃，看起來只要我們按敏捷的開發(fā)模式做下去就好了，那為什么還有標題里提到的敏捷轉型失敗之道呢阻问？我們繼續(xù)往下面看梧税。
