起因
我的同事肖然在 《ThoughtWorks的敏捷開發》一文中介紹了ThoughtWorks敏捷開發的全貌，並在其中簡單介紹了ThoughtWorks是怎麼做質量內建和敏捷測試的。我作爲一名加入ThoughtWorks已經7年的QA，想更爲詳細的介紹一下這些內容，希望能幫助業界中仍對於敏捷測試有疑慮和困惑的團隊建立起自己的敏捷測試體系和實踐，從而幫助團隊更好的實施敏捷軟件開發。
在目前的軟件開發領域，敏捷依然沒有被廣爲採用，很多人詬病其：
- 開發速度其實並不比傳統的開發方式快
- 軟件質量得不到保證
- 無法應用於大規模軟件開發
- 文檔少導致開發出來的軟件難以維護
- ……
其實大多都是在不瞭解敏捷開發中質量內建與敏捷測試的情況下得出來的。如果只是閱讀《敏捷宣言》，是很難以理解其中關於質量內建和敏捷測試的相關內容。所以通過長期的項目實踐，我們對質量內建以及敏捷測試總結出了一套自己的理論和實踐體系。
測試在流行敏捷開發方法中的缺位
業界有很多所謂敏捷開發流程，比如Scrum，Kanban等，但是其中測試相關的內容相對較少，並且不夠系統化和細節化，所以業界就出現了很多測試人員，他們總結了測試人員應該在敏捷開發中如何進行測試工作。由於很多測試人員也是公司或者團隊在Scrum和Kanban的轉型中接觸和學習到敏捷，然後通過有限的資料以及自悟在團隊中進行敏捷測試，又在一知半解下又去宣傳敏捷測試或者去抵制敏捷測試，導致敏捷測試甚至敏捷本身在國內亂象叢生。
首先敏捷測試一定是敏捷開發方法的一部分，所以敏捷開發方法論裏面應該需要包括敏捷測試的相關內容，但是現在業界中所謂的一些標準的敏捷開發流程裏面卻很少包含系統化的測試實踐。由於敏捷測試實踐或者說敏捷實踐的核心就是縮短反饋週期，逐步優化整個系統。並且因爲每個團隊的情況都是有差距的，所以通過同一種標準的方式去要求所有不同的團隊，則會產生很多負面的效果。
現在業界已經有不少通用的敏捷測試實踐，以及一些在特定條件下面的經典流程(後面會介紹一個經典的敏捷測試管理流程)。其次對於大規模敏捷開發中的敏捷測試來講，其核心還是在開發團隊裏面合理使用各種敏捷測試實踐，縮短測試反饋週期。
因此不管敏捷開發還是敏捷測試裏面的敏捷都沒有一個所謂統一的最終敏捷，應該是需要越來越敏捷的狀態纔是最好，然後最終達到自己項目的一個穩定敏捷狀態就可以。
敏捷測試的原則
ThoughtWorks沒有Tester這個職位，而是叫做QA。這裏的QA不是”Quality Assurance”，而是"Quality Analyst”——質量分析師。其主要工作是在承擔項目部分權責的情況下，負責各種質量相關的工作，通過各種實踐讓團隊中所有人都會對質量負責，並做一部分質量相關的工作。
QA每天都可能需要根據不同的情況而相應改變自己的工作內容，雖然每天主要的工作內容仍然是測試相關的各種工作，但是並不一定需要自己獨立完成它們，其中還包括把所有團隊成員組織起來，一起協作完成這些工作。並通過各種實踐，讓每個成員都能承擔最適合自己的質量相關的工作。QA需要了解並熟悉所有質量相關的活動和工作，並根據項目的情況將它們合理的組合起來使用。我們還總結出了一些敏捷測試的原則：
- 我們的目標在於和團隊一起儘快地交付高質量軟件。
- 測試人員儘早參與軟件早期階段，與所有團隊角色合作，通過實例化需求，確保對業務價值理解的一致性。
- 測試人員關注生產環境狀態，收集數據，指導和優化前期的分析、開發和測試。
- 測試人員和開發人員同處一個產品項目團隊，而不是獨立的測試團隊或部門。
- 測試人員負責探索性測試，和開發人員結對，設計、實現和維護自動化測試。
- 自動化測試在流水線中持續精準執行，快速發現每次代碼提交對於已有功能的影響
- 測試數據對於自動化測試是充分的，並能按需獲得。
- 測試活文檔化，和代碼一起，作爲知識資產進行版本化管理。
- 自動化測試需要有效的分層。
- 預防缺陷，而不是關注缺陷的數量。
這些原則展示出了敏捷測試的特點，指導我們更好的實施了敏捷測試，使得我們不僅僅關注測試本身，完成相關的測試工作，而且還要真正的在測試工作中關注並實施敏捷，並且通過各種敏捷實踐來促使全員負責質量的目標，最終在有限的時間內盡最大可能正確的交付客戶價值。
敏捷測試實踐與管理體系
在過去的20多年中，我們的QA通過大量的項目經驗，總結出了許多敏捷測試實踐，比如測試前移、每日結對檢查以及線上測試等等。我將它們分爲三個部分，分別是迭代開發中、故事卡開發過程中和產品環境中的敏捷測試實踐，分別從三個不同的維度總結了我們的各種敏捷實踐，從而幫助大家更爲系統化的瞭解它們。
迭代開發中的敏捷測試實踐
在真實的項目中，如何有效的將各種敏捷實踐組織起來，並在不同的團隊中使用，是敏捷測試管理最大的一個挑戰。由於每個團隊的情況都不一樣，比如產品規模，業務目標，人員能力等，導致敏捷測試流程和管理體系都會有所區別。雖然有所區別，但是敏捷測試管理還是圍繞着敏捷的核心價值進行管理，並且有自己特有的流程體系和度量體系。
通過多年的交付和諮詢經驗，我們的QA們總結了不少敏捷管理的實踐和經驗，並形成了一套經典的測試流程，適用於業務複雜的企業級軟件系統的開發。其完全是符合經典敏捷開發流程的，但是在真正項目實踐時，需要根據項目自身的特點和資源優先級來選擇其中適合自己的實踐，從而儘可能的滿足當前項目對於軟件質量和測試的需求。
首先在整個開發流程中，將不同的測試方法和測試實踐按照測試策略和測試計劃加入到整個迭代開發中，從而在每個迭代中實施它們。下圖爲一個經典敏捷測試生命週期圖。
（敏捷測試之迭代生命週期（經典模型））
在整個生命週期中一定要使用持續集成以及持續交付中的各種實踐，並且週期性的快速交付一些功能已經逐步被大家所認可。其中能幫助快速交付的一個最重要的步驟就是迴歸測試，所以應該儘可能自動化迴歸測試用例，加速交付過程。QA需要思維敏捷並且富有創造力，而大量週而復始的手動迴歸測試會阻止QA鍛鍊思維和創造力，其次長時間大規模的手動也是很容易出錯的。
圖中有性能測試等非功能測試。對於一些質量要求很高的項目，特別是對於性能，安全以及穩定性很高的項目，除了功能測試以外，還需要做大量的非功能測試，比如壓力測試，耐久性測試，負載測試，災備測試，安全測試以及各種異常測試等。這個時候就需要QA擁有相關的知識來負責這些測試，可以是自己做，也可以是教其他人做，比如團隊的開發人員等，或者由自己把關並外包給其它公司做。
在項目開始階段，開發人員開始開發工作前，QA還需要完成以下實踐：
測試分析
由於測試前移，測試分析所關注的實踐要關注更多的東西，它包括風險分析、測試設計等。風險分析需要儘可能的指出業務或者技術層面上問題，它們會在什麼時候、在什麼地方、對產品的利益相關者產生多大的影響等。測試設計則需要指出如何在有限的時間和資源的情況下如何高效的覆蓋高風險的功能等。QA必須在每個項目中都做測試分析，並且在項目的不同的階段都需要做。比如和業務分析一起結對寫驗收測試條件的時候、設計迴歸測試套件的時候、做探索性測試的時候、開發和維護自動化測試的時候，以及當要忽略迴歸測試套件中某些測試用例的時候。
測試策略
QA需要經常和團隊的其他成員合作來完成測試策略，比如開發人員、項目經理等。由於一個大型軟件項目需要開發大量的自動化測試，並且不少自動化測試都需要開發人員來完成，所以需要有一個測試策略來指導整個團隊成員來完成各種類型的測試，比如單元測試、功能測試、服務契約測試、界面測試等等。
故事卡開發過程中的敏捷測試實踐
其次在每個不同的迭代週期中，敏捷測試實踐的主要工作就是圍繞故事卡來進行。對於每個單獨的故事卡，我們也有一套自己的敏捷測試故事環。需要注意的是，這個敏捷測試故事環和這些敏捷測試實踐只是一個經典模型，在真實的不同項目的實踐中會有所改變。
（故事卡生命週期（經典模型））
上面是敏捷開發故事環，在環中不同的階段需要加入我們定義的經典敏捷測試實踐，就形成了敏捷測試故事環。其中實踐包括：
故事啓動
在傳統瀑布開發模式中，測試人員一般是不參與故事啓動相關工作，但是在敏捷開發流程中，QA需要從這裏就開始介入，其經典實踐包括：
- 需求澄清
- 業務場景和驗收測試（AC）的確認
這個實踐也屬於測試前移。這兩個實踐的核心是需要QA和業務分析人員以及開發配合，一起來澄清所有不清楚和有疑問的需求，並確認所有的驗收條件即驗收測試用例。如果QA發現業務需求分析本身有問題，或者驗收條件不合理、不可測等，那麼QA就需要挑戰這些問題和不合理，儘量保證開發拿到的故事卡是業務清晰，驗收條件合理並可測。通過這些實踐可以實現測試前移和ATDD，儘量在開發之前發現缺陷，從而預防缺陷，並保證三方人員對於需求的理解都是一致的。這個活動也稱爲Kick Off。
故事計劃
故事啓動並澄清需求後，就是故事計劃了。其實很多團隊是沒有故事計劃的，或者故事計劃是在迭代開始前一次性做一次。不過我們還是建議在每個故事開發前做一個簡短的計劃工作，用於計劃這個故事卡。在其中QA需要計劃測試工作，其經典實踐包括：
- 測試工作估算
- 制定測試計劃
這個測試計劃和工作估算是針對這個故事卡的，其中包括我需要對這張卡做哪些測試，測試數據和測試環境的計劃與準備，測試工作大概需要多少個點等。但是估算並不是承諾，只是讓大家瞭解測試工作內容的複雜度以及困難度。對於困難的測試點，則可以計劃讓開發人員幫助一起做。
故事開發
如果有故事計劃，那麼完成計劃之後開始開發工作，如果沒有就在故事啓動後直接開始。在開發過程中，QA需要儘可能的在開發完畢之前發現產生的缺陷，從而實現缺陷的快速反饋，其經典實踐包括：
- QA和開發結對實現自動化測試
- QA和開發或者業務分析結對做每日內部演示和反饋（Desk Check 或者 Shoulder Check）
- 及時和團隊溝通發現的問題和缺陷
這三個經典的實踐可以防止缺陷流動到測試階段，減少缺陷的反饋週期，減少返工的成本，從而降低軟件開發週期，提高單位時間內的軟件質量。
一個團隊中不同角色的人會關注不同的風險和問題。比如QA需要詳細的，精準的將缺陷告知開發人員；但是對於PM，QA需要幫助其瞭解項目整體上的風險，幫助其管理項目進度和發佈計劃。所以記錄缺陷，並且對於嚴重缺陷或者風險需要告知整個團隊或者管理層是QA的一項重要工作。
對於那些自動化測試成本很高的項目，應該首先至少做一遍手動測試後，然後做完之後再來評估哪些需要做自動化，哪些不需要。
故事驗收
通過前面加入了敏捷實踐而開發出來的功能，其驗收測試的用例應該大部分甚至全部通過。但是爲了防止漏網之魚以及開發人員最後提交的代碼修改出現side effect，我們仍然在開發完成之後定義了一個“故事驗收”階段，用於整體驗證功能的所有驗收條件等，其經典實踐包括：
- QA和業務分析結對進行快速驗收測試，提供快速反饋
通過這個環節，可以儘可能的保障驗收條件不會存在缺陷，從而減少缺陷發現和修復的週期。但是如果業務沒有時間，也可以由QA一人或者QA和開發人員結對完成。
驗收測試可以是手動測試，也可以是自動化測試。但是大部分實際情況中，都是先做手動測試，再通過手動測試的用例再來編寫自動化測試。對於實現了ATDD的團隊，那麼也建議在功能開發完畢後做一遍手動測試，因爲自動化測試很多時候可能會遺漏一些驗證條件，忽略一些細節。而通過至少做一遍手動測試，可以發現一些通過自動化測試發現不了的東西。比如發現了一個bug，需要添加自動化測試來覆蓋它；或者某些自動化測試斷言過少；或者某些測試沒有實踐的意義，或者是重複的，需要刪除等。
故事測試
通過故事驗收以後，理論上驗收條件應該大部分或者全部滿足了，所以不應該存在明顯的缺陷了。這個時候應該做更多的測試，比如探索性測試，安全測試等，從而發現驗收條件以外的缺陷。其經典實踐包括：
- 執行探索性測試，安全測試等
- 強調會阻礙故事發布的風險因素
- 爲測試發現的嚴重缺陷添加自動化測試
- 執行自動化驗收測試，可以是迴歸測試
通過這個環節可以盡最大可能發現所有問題，並在最後給客戶演示之前評估完所有的風險，並盡最大可能防止風險會影響到客戶。
系統測試和客戶演示
如果故事功能屬於一個完整業務流程中的一個節點功能，那麼這種情況下就需要進行業務層面上的端到端測試。當端到端測試成功之後，就可以進行功能的最終客戶驗收演示，從而最終完成功能故事卡的開發。其經典實踐包括：
- 執行業務層面上端到端的系統測試
- 和團隊及客戶就功能特性的質量和穩定性進行溝通
- 給客戶驗收功能和特性
如果客戶驗收成功，那麼這個功能就可以準備上線了。但是如果驗收失敗，就需要進行分析，爲什麼失敗？確認是第一步“故事啓動”裏面的驗收條件有錯誤或者遺漏，還是功能本身就分析和設計錯誤，滿足不了客戶的需求。然後通過“5 Whys”或者“Retro”等會議找到爲什麼驗收失敗的原因，並且制定下一步改進的方案。理論上，通過前面這些步驟之後再驗收失敗的可能性很小，除非業務分析人員本身由於能力等原因就從最開始就分析錯了，並且通過和開發人員、QA等的結對也沒有發現。雖然仍然沒有辦法避免驗收演示失敗這種小概念事件，但是一旦發生，由於敏捷中的持續改進，我們可以通過持續改進並進一步減小其發生的概率。
除了敏捷測試故事環中的常規工作和實踐，還需要經常對測試進行維護與重構。一般一個成功的大型軟件項目都有大規模的測試用例或者自動化測試，並且項目的成功與否和這些測試用例或者自動化測試的有效性以及健壯性直接相關。但是現實中大規模自動化測試有一個大問題，那就是“易碎性”。而這種“易碎性”最主要是由於環境的改變或者自動化測試代碼的改動。對於環境的改變，測試人員應該參與到DevOps建設中，從而建立起一套穩定的測試環境，包括測試數據系統等。而對於自動化測試腳本的改變，很多時候是由於新加功能而需要修改測試系統通用代碼，從而導致的副作用。所以對於自動化測試代碼也需要像對待產品代碼一樣，進行重構和維護。
產品環境中的敏捷測試實踐
當一個發佈版本開發(包括測試)完成以後，就需要進行部署和發佈。而我們的QA也需要參與發佈管理。由於QA參與並且負責了大量質量相關活動，所以對於軟件系統的整體質量有較高的認識。所以QA有責任參加發佈會議，並且參與決定是否發佈的決定。
當產品真正交付到用戶手中或者發佈上線以後，我們的QA仍然需要在產品環境中做質量相關的工作，稱之爲產品環境中的QA，或者叫測試後移。這將工作範圍擴大到產品環境，增加了更多的反饋來源，跟持續交付結合，可以幫助持續提高產品質量、持續優化業務價值。
產品統計數據分析
產品環境中軟件系統在運行過程中會產生大量的數據，如果通過A/B測試還可以獲得大量不同特徵的數據。而通過分析這些數據，往往可以找到優化和提高軟件質量的方案。比如統計一個Web系統在產品環境下所有頁面的下載和加載的平均時間、最長時間以及趨勢，可以有效的發現一些性能問題；又比如客戶端瀏覽器類型統計，可以幫助優化測試策略，加強對於用戶量最多的瀏覽器的兼容性測試等等。從而通過這種方式有效的持續提高產品的質量。
可調式性日誌分析和優化
現代的服務系統越來越複雜，導致調試也越來越困難，特別是線上調試就更爲困難。很多線上系統主要是通過日誌來進行調試，所以日誌的可調式性就非常重要。因爲日誌的可調式性直接影響到了當產品出現問題之後調試並發現問題原因的速度和時效，如果可調式性好，那麼產品環境遇到問題後修復的時間也會相對縮短。因此QA可以通過各種機會，比如定期，或者某次產品遇到產品環境問題後，對於產品環境的日誌進行可調式性分析，並協助團隊一起對其進行優化。
持續業務功能監控
當前業界對於產品環境的監控主要以服務監控爲主，比如服務是不是在線或者下線等，而很少做業務功能級別的監控，比如監控某一個核心業務功能是不是工作正常。而產品環境下的QA需要幫助團隊搭建核心業務功能的監控方案，比如提供測試場景和步驟，提供業務成功的驗證方案等等。然後當某個業務功能工作不正常的時候，但是系統服務仍在線的情況下，依然可以在最短的時間內獲得業務功能的反饋。
除了上面三個主要的實踐以外，QA還可以在產品環境下做更多的一些實踐來獲得質量的快速反饋，從而提高產品系統的質量。所以產品環境下的QA是未來特別值得深入研究的一個話題。
除了以上介紹到的敏捷測試中的實踐，其實還有其他一些適合不同團隊的敏捷實踐，這裏就不再贅述了。
總結
通過我們長期的項目實踐，思考與洞見，不僅總結出了10條敏捷測試的原則，還有了我們的敏捷測試宣言：
全程的測試介入 over 孤立的測試階段
團隊整體對質量負責 over 測試人員獨力把關質量
持續性的精準自動化測試 over 迴歸式的全量自動化測試
質量內建 over 質量檢測
這個敏捷測試宣言基本上體現了我們敏捷測試的核心實踐，並且和敏捷宣言一樣，儘管右項有其價值，但是我們更重視左項的價值。
在這種敏捷測試的實踐體系中，我們的開發測試比通常可以做到2～4 : 1。但是這個不是絕對的，我們有少部分項目可以做到5:1或者更高，因此不同的項目都需要根據自己的實際情況來制定這個比例，比如項目時間、質量需求、人員能力等等。通過我多年的工作中的觀察以及總結，我發現開發人員技能越高，願意並能做越多的測試工作，那麼測試開發比就越大。而在開發人員技能等同的情況下，軟件系統的業務複雜度越高，開發測試比就越小。
最後，你們做了敏捷測試嗎？和我們做的差距大嗎？
更多精彩洞見，請關注微信公衆號ThoughtWorks洞見