作者：陳曉鵬，原埃森哲中國卓越測試中心負責人，敏捷及DevOps專家，18年IT領域測試相關工作經驗，超過10年在IBM、埃森哲、德勤等國際頂尖IT諮詢及世界五百強公司工作。擅長測試諮詢與落地、專案管理、測試成熟度評估及測試中心建設、測試自動化及敏捷測試、DevOps等相關領域。
首先非常感謝Testin的徐琨總邀請，前天晚上在雲測學院做了一場免費公開課《傳統測試人員如何轉型敏捷測試》。
（想看影片回放的童鞋可以掃描下方二維碼加入釘釘測試大咖秀的群即可免費回看）
說起敏捷，已經不再是什麼新鮮的事情，無論是敏捷圈眾多的從業者還是書城裡各種應接不暇的敏捷相關書籍，都可以感覺到敏捷已經在中國欣欣向榮，成為一種必然的趨勢。然而不得不說的是，在測試領域卻成了一塊窪地。無論是敏捷還是規模化敏捷，都沒有談到太多怎麼中做測試的指導。
搜遍亞馬遜、噹噹、京東，你能看到和敏捷測試相關的書籍也寥寥無幾，除了Lisa Crispin寫的姐妹篇之外，基本上沒有太多經典書本。再加上敏捷裡面流傳著一句話：敏捷沒有測試人員了。這更加劇了眾多測試從業者迷茫而不安的心情。
對於測試目前這種窘境，我想在今年一定會有所改觀。包括朱少民老師、陳霽老師等同行也在發力敏捷測試培訓這塊內容。在前晚的公開課上我也看到了近400人的直播觀看記錄。說明其實很多測試人員還是非常迫切希望學習這種知識的。
但是，從學員們的留言中，我還是感覺到任重而道遠。仍然有不少的測試朋友們並沒有正確的理解敏捷測試，甚至是敏捷的理念。所以我特意把同學們在前晚提的問題收集起來，準備一條條回覆。這是做過那麼多場培訓以來第一次這麼用心的去解答問題，我覺得如果不這麼做，其實這些童鞋們還是會帶著之前錯誤的意識和思維去做事，而最後的結論很可能就是“敏捷無用或者敏捷測試無用”。
1. 探索式測試有什麼書籍推薦？
第一本我要推薦的是《探索式軟體測試》，這本書的作者叫James Whittaker。如果大家對此大神感覺陌生，那另外一本也是他寫的神作《谷歌軟體測試之道》應該讀過吧？
其實我更想極力推薦的第二本書是我的好朋友高翔老師寫的《探索式測試實踐之路》，這本書是一本理論與實踐相結合的書，個人覺得寫的比第一本更加系統，非常值得一讀。
當然如果有興趣的童鞋還可以看我的公眾號文章《探索式測試，敏捷開發的天然伴侶》這篇文章。
2. 增量式和迭代式的區別？
增量開發是對所要開發的東西胸有成竹比較清晰了，但是因為產品外部因素的不確定，所以分成不同的批次來開發。如下圖所示：
而迭代開發是還不清楚自己要開發的東西，所以需要不斷的漸近明晰，它主要應對的是產品內部的不確定因素，如下圖：
而敏捷，就是採用增量+迭代的方式來開發的，如下圖：
3. 敏捷測試開發測試比一般多少？
美國敏捷測試專家Lisa Crispin曾在她的書中說過，不要去糾結開發測試比，因為沒有意義。沒有意義的原因我想是因為在Scrum團隊中，只有一個開發團隊而不會再區分誰是開發角色誰是測試角色。如果你非要我說一個數字，那我想根據我看到的情況是基本上一個Scrum團隊也就1-2個測試人員，其中還包括一個自動化或者測開工程師。
4. 敏捷測試適合什麼樣的專案？
敏捷測試當然適合於敏捷專案。如果想把敏捷測試放在瀑布模式下運轉，等同於你把傳統瀑布模式測試那一套放在敏捷專案中運轉，是很痛苦的。
5. 敏捷與devops有什麼區別呢？
根據喬梁老師在我朋友圈的留言定義：DevOps是敏捷的一種延伸。我覺得“延伸”這個詞用得很好。敏捷解決了開發過程的問題，但是敏捷只是談到了生成PSPI潛在可交付產品增量就停止了，並沒有談到怎麼上線、怎麼把價值交付給使用者、怎麼在運維中拿到反饋並形成閉環。而這些就是DevOps解決的問題。DevOps的一個核心理念是價值必須真正交付到終端使用者，只有上線了，使用者能用這個功能了，這樣才算是價值交付到終端使用者，而敏捷顯然還沒有做到這一步。
6. 敏捷中單元測試一般是誰來做？
開發人員自己做。《谷歌軟體測試之道》中寫道，沒有誰比開發更懂得測試自己的單元元件了。所以必須開發自己來做。敏捷推薦的是TDD的模式，也就是開發人員在真正動手寫程式碼之前需要先編寫單元測試用例再寫程式碼。打個比方就是你在打槍的時候需要先瞄準靶子再點射，而不是像一頓掃射後發現目標不對又浪費子彈。而這個靶子就是你的單元測試用例。
7. 如何衡量測試工作量，如何考核？
測試的工作量肯定在每個Sprint Planning的時候在做工作估算的時候一起做的，一個story的完成除了開發之外還必須測試，而story的完成標準是測試必須透過而不只是開發的程式碼完成。所以不要把測試的活動單獨拎出來估算。這種做法和敏捷測試理念是背道而馳的。敏捷測試強調把開發和測試都包含整個開發過程中。
8. 如何做測試總結分析，並進行改善？
每個Sprint結束時會有一個retrospetive的活動，這是一個回顧總結的活動，測試總結分析也同樣在此活動中進行，並形成改善的行動。記住，最重要的是行動的落實實施。否則就是虎頭蛇尾，不起任何作用。
9. 不記Bug，那怎麼來做分析與監督呢？如何不斷改進來提升研發交付質量呢？
在Lisa Crispin的《敏捷測試》和徐毅老師翻譯的《敏捷教練》的書中都提到，對於上線前的缺陷，不一定要記錄在缺陷管理系統DMS中。建議如果真要用缺陷管理系統，可以把上線後缺陷錄在裡面。原因在於什麼？
上線前缺陷如果走缺陷管理系統，需要測試人員登記、測試主管評審、發給開發主管、開發主管分派給開發人員、開發人員進行修復、然後再發給測試人員迴歸。這樣的流程跑下來，怎麼能適應1周或2週一個迭代？
Lisa建議，發現缺陷，直接走到開發人員跟前復現給他看，這是最有效率的解決Bug的方式。如果登記在DMS，這就變成了功能性組織的味道，很有可能登記這些缺陷是為了反饋開發人員做得多不好。同時缺陷也不能成為監督開發人員或測試人員的一個指標，這破壞了敏捷強調的一個團隊、自組織和免責的文化。
10. 敏捷測試Sprint不記錄BUG。那怎麼反饋給開發並作BuG迴歸？
如上述所說，直接走到開發前面去復現給開發看，開發修復完喊一聲就可以迴歸了，關鍵是要快。
11. 對於敏捷測試，版本上線的標準是什麼了
首先，版本的上線標準不是測試說了算。因為在敏捷專案中，是團隊負責質量，而不是測試負責質量。其次，每個版本應該有一個DOD，會明確定義這個版本的完成標準。只要遵從這個DOD，都達到了DOD的要求，自然就達到了上線的標準。
12. 敏捷團隊之後，還需要測試部存在麼。還是都併入專案組各自管理？併入的話，誰來關注測試人員的上升空間和能力提升？
從敏捷的角度來說，測試人員歸到各專案中，確實沒有測試部門存在的必要了，這也是《谷歌測試之道》釋放出來的一個顛覆性觀點。但是，從我個人的經驗來講，測試組織（例如卓越測試中心TCOE）是非常有必要存在的。
TCOE的存在，不是為了和專案爭取測試人員管理權，如果是這樣那就和傳統的職能型部門沒有什麼兩樣。TCOE的價值在於當這些測試人員出了專案之後，它應該能夠承擔起測試人員能力培養和職業生涯規劃的責任。
因為TCOE集中了所有的測試資源，裡面有不同領域的專家，可以做各種能力的培養和提升；同時TCOE可以打破專案的籬笆，讓一些測試資產得到複用，而不用每個專案重複造輪子。
沒有TCOE，這些事情都沒有辦法做，同時測試人員也沒有組織的歸屬感。所以我個人贊同有這麼個測試組織，但是需要注意一點：當測試人員在專案中時，切忌和專案爭管理權。
13. 我們公司測試在變革，測試團隊現在分管到專案組不再有測試老大統一管理,這種適合敏捷嗎
這個問題和上面的問題是一致的。已經回答。
14. 敏捷交付，一個系統，每週迭代版本後，測試完版本需求後，其他功能模組要怎麼處理呢？全量是不可能有時間的。
在敏捷中有兩種測試型別，一種叫In-Sprint測試，一種叫Cross-Sprint測試。Cross-Sprint就是解決模組間整合的問題。大家可以關注我在IDCF訓練營上的敏捷測試的課程，裡面會有詳細的介紹。
15. 新版本測試OK後，影響舊模組功能，怎麼定責？因為測試通常驗證版本需求和相關聯模組。
不贊同用“定責”這個詞，因為敏捷應該是“免責”文化。另外這個新版本沒有問題，但是影響就模組功能和上面的問題類似，都是由Cross-Sprint測試來保障的。具體可以看IDCF訓練營上的課程。
16. 傳統測試會看Bug收斂情況來評估專案是否適合上線，敏捷測試怎麼來評估？
敏捷測試主要看DOD（definiton of Done），這個和傳統的測試不一樣。傳統測試會看缺陷累積的收斂趨勢，那是建立在測試階段長達幾周甚至是幾個月的時間。但是敏捷中一個迭代也就2周時間，是沒有辦法看缺陷累積也沒有必要的。
17. 公司、文化、組織不支援的話，敏捷測試該如何落地呢？
個人覺得如果公司層面不支援大的變動，那敏捷的一些實踐也是可以落地的，比如持續整合、自動化測試、活動看板等，這些都不是對組織有太大的變化。
18. 公司誰能推動建立敏捷測試團隊
公司所有人都有責任和義務推動，當然，最主要的還是老闆們要有意識要支援，這就是在規模化敏捷SAFe中專門強調，領導必須接受敏捷知識的培訓。
19. 敏捷對測試怎麼度量呢？
其實敏捷沒有專門對測試指標進行度量，還是結合開發任務、結合使用者故事一起度量的。一個使用者故事是否完成，是需要測試根據使用者故事的接受標準（AC）去驗證的。對使用者故事完成的度量其實就是在對測試的度量了。
20. 做敏捷測試，一般需要什麼專業技能
我之前在公眾號中發過一篇敏捷測試宣言和原則指南的文章，裡面有一條原則：“be a fullstack Tester”。所以最好是希望你是全棧式的測試人員，看得了架構、擼得了程式碼、做得了測試。測試人員要懂架構，這點我很贊同，相信茹炳盛老師也是如此，他最喜歡透過大型電商的架構演進來闡述該如何做測試。
當然，有些人說要求太高了。那具體的每個測試的角色需要什麼技能，可以關注我在IDCF訓練營上的課程，裡面有個敏捷測試人員技能圖譜，會詳細聊。
21. 如何評價團隊成員貢獻
測試人員的貢獻，我想最直觀的就是團隊的認可。金盃銀盃不如團隊的口碑。我們不能走傳統測試的老路，透過極其複雜的度量標準來衡量每個人的貢獻值，其實透過度量出來的資料也未必能真實反映出情況。
22. 敏捷自動化部分如何進行？
敏捷自動化的實施理論基礎是測試金字塔和分層自動化。如果展開來講要將很長時間。如果有興趣可以關注我在IDCF訓練營的課程。
23. 自動化測試指令碼需要在一個Sprint的什麼階段準備好？只有user story，沒有詳細設計和可測程式碼，自動化指令碼如何準備？
我曾經有個專案有實際經驗，一般自動化測試指令碼會在下一個sprint的第三天完成，並且在下一個sprint做迴歸執行。可能有人會問，質量如何保證？我在IDCF會專門有個案例分享是如何保證的。
24. 敏捷測試是否還在一個Sprint中完成這個迭代的開發任務的冒煙測試然後再進行自動化API的指令碼開發？下一個Sprint在進行上一個Sprint的開發任務的用例執行？
我的實踐經驗，是的。不過具體怎樣實施還是有一些道道的。可以關注我的IDCF課程。
25. 如果不寫測試用例，不做用例評審，怎麼保證測試的質量？
這裡談到的應該是探索式測試的範疇。首先強調一點，探索式測試不是說不寫測試用例，而是用簡單的方式來寫。探索式測試是一種有效的方式。可以檢視我寫公眾號文章《探索式測試，敏捷開發的天然伴侶》，也可以關注IDCF課程，裡面會有詳細的探索式測試的內容。
