究竟什麼是敏捷測試
時至今日，還討論這樣一個老話題，是否感覺老調重彈？因為兩年前（2010年底）時任谷歌中國測試經理的段念先生就寫了一篇文章《什麼是敏捷軟體測試》（刊登在InfoQ網站上[1]）， 就已經談到這個話題，“敏捷軟體測試更多的是一種理念，而非過程”。在2011年，我自己也寫了一篇文章《敏捷測試的思考和新發展》，刊登在《程式設計師》雜誌上，談到“在BDD、ATDD和TDD最根本的、共同的思想基礎上，構成一個全新的、更完善的敏捷測試框架”[2]。而更早的時候（2010年10月），寫了一篇《敏捷測試的方法和實踐》（也刊登在《程式設計師》雜誌上），開始的那一小節就在討論 “什麼是敏捷測試”，簡單地說，“敏捷測試就是持續地對軟體質量問題進行及時地反饋”[3]
圖1 傳統測試與敏捷測試 [4]
這樣看來，“敏捷測試（Agile Testing）”就不是一個新概念了，但為什麼不少人還是不理解什麼敏捷測試呢？現在偶爾還看到一些文章或微博帖子還在討論什麼是敏捷測試，但似乎雲裡霧裡、不知所云，感覺“敏捷測試”在許多人的心目中還是比較模糊。估計是以前的文章，包括我的文章，沒有把“敏捷測試”說透，所以有了再寫一篇文章的想法，儘量一次把“敏捷測試”這個內涵給大家說清楚。以後，有機會再討論傳統測試團隊如何轉型、敏捷文化下測試團隊如何建設等。
首先，可以明確的是，敏捷測試既不是一種方法（如黑盒方法、白盒方法等），也不是一種方式（如探索式測試）。因為在敏捷測試中可以採用已有的各種方法，包括白盒方法、黑盒方法；在敏捷中也可以採用探索式測試（exploratory test），也可以採用基於指令碼的測試（scripted test）。那敏捷測試是什麼？敏捷測試應該是一套解決方案、一類測試操作與管理的框架、一組實踐或由一定順序的測試活動構成的特定的測試流程。就像Scrum一樣，Scrum可以理解為敏捷方法的具體實現的框架、一組實踐或具體的解決方案。簡單地說，敏捷測試就是順應敏捷開發方法、力求達到質量和效率平衡的一系列的測試實踐。讓我們看看Wikipedia 是如何描述敏捷測試的：
Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace.
它強調敏捷測試是遵守敏捷開發方法原則之下的軟體測試實踐，由跨功能敏捷團隊的所有人員參與（包括測試人員以其專業特長的特殊貢獻）以保證持續的、快速的業務價值交付。所以要理解敏捷測試，我們還是要回過頭來仔細看一下“敏捷宣言”背後所蘊含的12條原則。我相信，大家都已熟悉敏捷宣言，如果不熟悉，可以先認真閱讀以下完整的敏捷宣言，不僅僅是那四句話。
1. 方法論上的敏捷測試
先從敏捷開發這一方法論層次來討論什麼是敏捷測試，即敏捷測試有什麼具體特徵，或有哪些主要實踐，然後再就目前非常熱的敏捷具體框架Scrum來討論Scrum中的敏捷測試（或稱為Scrum Testing）。先研究一下敏捷宣言背後所蘊含的12條原則[5]：
1) 我們最重要的目標，是通過持續不斷地及早交付有價值的軟體使客戶滿意。
2) 欣然面對需求變化，即使在開發後期也一樣。為了客戶的競爭優勢，敏捷過程掌控變化。
3) 經常地交付可工作的軟體，相隔幾星期或一兩個月，傾向於採取較短的週期。
4) 業務人員和開發人員必須相互合作，專案中的每一天都不例外。
5) 激發個體的鬥志，以他們為核心搭建專案。提供所需的環境和支援，輔以信任，從而達成目標。
6) 不論團隊內外，傳遞資訊效果最好效率也最高的方式是面對面的交談。
7) 可工作的軟體是進度的首要度量標準。
8) 敏捷過程倡導可持續開發。責任人、開發人員和使用者要能夠共同維持其步調穩定延續。
9) 堅持不懈地追求技術卓越和良好設計，敏捷能力由此增強。
10) 以簡潔為本，它是極力減少不必要工作量的藝術。
11) 最好的架構、需求和設計出自自組織團隊。
12) 團隊定期地反思如何能提高成效，並依此調整自身的舉止表現。
這12條原則中沒有一條直接談到測試，那是否說明沒有敏捷測試呢？有開發就有測試，只是原來參加敏捷宣言的17人，基本是清一色程式設計師，沒有在原則中單獨闡述一下測試的原則。但其中一些原則和測試的關聯性很強，例如：
1) 軟體測試如何支撐或協助“持續不斷地及早交付有價值的軟體”？如何在非常有限的時間內進行充分的測試？這就是我們經常在敏捷測試中強調的“自動化測試”，如果沒有自動化測試，就沒有敏捷，就不能持續不斷地及早交付有價值的軟體，而且還要“使客戶滿意”。
2) “欣然面對需求變化，即使在開發後期也一樣”和傳統的開發原則是不同的，傳統的開發希望有嚴格的需求變更控制，越到後期控制越嚴。而敏捷開發擁抱變化，那麼測試如何適應這種變化？如何快速地完成迴歸測試？這可能要依賴於開發做好單元測試，或全員參與測試，以及全面支援系統級的、端到端的迴歸測試的自動化測試執行。
3) 傳統的開發也要求“業務人員和開發人員必須相互合作”，但存在一定的階段性，例如前期需求評審、期間產品走查（product walk-through）、後期驗收測試等要求有緊密的溝通與協作。但敏捷開發更強調“專案中的每一天都不例外”，在這樣的原則下，如何去做敏捷測試？這樣可以減少測試文件，剛開始也沒必要把測試計劃寫得很詳細，而是寫一頁紙測試計劃就可以，將來再持續的完善和調整。
4) “可工作的軟體是進度的首要度量標準”，不再是測試計劃完成情況、完成的測試用例數目、測試指令碼量等，而是如何及時驗證每天完成的功能特性。開發的工作量也不能按程式碼行來衡量，而是看多少個具體的使用者故事（功能特性）被實現了（done）。某個開發說已完成了某個使用者故事，要麼是通過他自己的驗證，要麼是通過測試人員的驗證，誰做的測試不重要，關鍵是要有準備好的測試，隨時驗證已完成的工作。
5) “堅持不懈地追求技術卓越和良好設計”，一方面要求測試的技術要不斷提高，在處理每個測試任務時，都應該找到最有效的辦法；另方面，在前期要更多地參與設計評審，及時發現設計的問題。只有良好的設計，才能更好地支援系統的功能擴充和不斷的重構。
基於這些原則，我們就可以概括一下敏捷測試的一些特點：
1) 敏捷測試一定是敏捷開發方法的一部分，應符合敏捷測試宣言的思想，也遵守上面所列的敏捷開發的原則，強調測試人員的個人技能，始終保持與客戶/使用者、其它成員（特別是業務人員、產品設計人員等）的緊密協作，建立良好的測試框架（特別是持續整合測試和自動化迴歸測試的基礎設施）以適應需求的變化，更關注被測系統的本身而不是測試文件（如測試計劃、測試用例等）。
2) 敏捷測試具有鮮明的敏捷開發的特徵，如測試驅動開發（TDD）、驗收測試驅動開發（ATDD），可以見我的另一篇文章《敏捷測試的思考和新發展》所討論的。測試驅動開發的思想是敏捷測試的核心，或者說，單元測試是敏捷測試的基礎，如果沒有足夠的單元測試就無法應付將來需求的快速變化、也無法實現持續的交付。這也說明，在敏捷測試中，開發人員承擔更多的測試，這也就是我們說的，在敏捷測試中，是整個團隊的共同努力。在敏捷測試中，可以沒有專職的測試人員，每個人都可以主動去取設計任務、程式碼任務做，也可以去拿測試任務來做。在敏捷測試中，也可以像開發人員的結對程式設計那樣，實踐結對測試——一個測試人員對應一個開發人員、或一個測試人員對應另一個測試人員。
3) 敏捷測試無處不在、無時不在。在傳統測試裡也提倡儘早測試，包括需求和設計的評審；在傳統測試裡也提倡全過程測試。但在傳統測試裡階段性特徵相對突出一些，例如，需求評審，意味著先讓產品人員去寫需求，但需求文件寫好之後，測試人員再參加評審。而在敏捷測試裡，團隊每一天都在一起工作，一起討論需求、一起評審需求。在敏捷測試中，這種持續性更為顯著一些。
4) 敏捷測試是基於自動化測試的，自動化測試在敏捷測試中佔有絕對的主導地位。在傳統測試中也提倡自動化測試，但由於傳統開發的週期比較長（幾個月到幾年），即使沒有自動化測試也是可以應付的，一般來說，迴歸測試能夠獲得幾周時間，甚至1-2個月的時間。而敏捷測試的持續性迫切要求測試的高度自動化，在1-3天內就有完成整個的驗收測試（包括迴歸測試）。沒有自動化，就沒有敏捷。
2. Scrum的敏捷測試
下面就以流行的敏捷框架Scrum來討論敏捷測試，會更具體一些，會更具可操作性。我們通過下面圖2再複習一下Scrum的模型，但這裡就不詳細介紹了。
圖2 Scrum過程示意圖
從圖中可以看出，除了最後“驗收測試”階段，其它過程似乎沒有顯著的測試特徵，但隱含的測試需求和特徵還是存在的。
1) Product Backlog （需求定義階段），在定義使用者需求時測試要做什麼？測試需要考慮客戶的價值大小（優先順序）、工作量基本估算之外，需要認真研究與產品相關的使用者的行為模式（如BDD），產品的質量需求，哪些質量特性是我們需要考慮的？有哪些競爭產品？這些競爭產品有什麼特點（優點、缺點等）？
2) Sprint Backlog（階段性任務劃分和安排），這時候需要明確具體要實現的功能特性和任務，作為測試，這時候要特別關注“Definition of Done”，即每項任務結束的要求——即任務完成的驗收標準，特別是功能特性的設計和程式碼實現的驗收標準。ATDD的關鍵一步也體現在這裡，在設計、寫程式碼之前，就要將驗收標準確定下來。一方面符合測試驅動開發思想，第一次就要把事情做對，預防缺陷；另方面持續測試和驗收測試的依據也清楚了，可以快速做出測試通過與否的判斷。
3) 在每個迭代（Sprint）實施階段，主要完成Sprint Backlog所定義的任務，這時除了TDD或單元測試之外，應該進行持續整合測試或通常說的BVT（Build Verification Test）。而且開發人員在設計、寫程式碼時都會認真考慮每一元件或每一程式碼塊都具有可測試性，因為測試任務可能由他們自己來完成。如果有專職的測試人員角色，一方面可以完善單元測試、整合測試框架，協助開發人員進行單元測試；另方面可以按照針對新實現的功能特性進行更多的探索式測試，同時開發驗收測試的指令碼。如果沒有專職的測試人員角色，這些事情也是要完成，只是由整個團隊共同完成。雖沒有工種的分工，但也存在任務的分工。
4) 驗收測試可以由自動化測試工具完成，但一般情況下，不可能做到百分之百的自動化測試。例如易用性測試就很難由工具完成。即使對效能測試，是由工具完成，但還需要人來設計測試場景，包括關鍵業務選擇、負載模式等。敏捷的驗收測試，和傳統的驗收測試不同，側重對“Definition of Done”的驗證，但基本的思想和傳統開發是一致的，任何沒有經過驗證的產品特性是不能直接釋出出去的。
3. 結論
敏捷測試就是符合敏捷宣言思想，遵守敏捷開發原則，在敏捷開發環境下能夠很好地和其整體開發流程融合的一系列的測試實踐，這些實踐具有鮮明的敏捷開發的特徵，如TDD、ATDD、結對程式設計、持續測試等。和傳統測試的區分，可以概括如下：
1) 傳統測試更強調測試的獨立性，將“開發人員”和“測試人員”角色分得比較清楚。而敏捷測試可以有專職的測試人員，也可以是全民測試，即在敏捷測試中，可以沒有“測試人員”角色，強調整個團隊對測試負責。
2) 傳統測試更具有階段性，從需求評審、設計評審、單元測試到整合測試、系統測試等，從測試計劃、測試設計再到測試執行、測試報告等，但敏捷測試更強調持續測試、持續的質量反饋，階段性比較模糊。
3) 傳統測試強調測試的計劃性，認為沒有良好的測試計劃和不按計劃執行，測試就難以控制和管理，而敏捷測試更強調測試的速度和適應性，側重計劃的不斷調整以適應需求的變化。
4) 傳統測試強調測試是由“驗證”和“確認”兩種活動構成的，而敏捷測試沒有這種區分，始終以使用者需求為中心，每時每刻不離使用者需求，將驗證和確認統一起來。
5) 傳統測試強調任何發現的缺陷要記錄下來，以便進行缺陷根本原因分析，達到缺陷預防的目的，並強調缺陷跟蹤和處理的流程，區分測試人員和開發人員的各自不同的責任。而敏捷測試強調面對面的溝通、協作，強調團隊的責任，不太關注對缺陷的記錄與跟蹤。
6) 傳統測試更關注缺陷，圍繞缺陷開展一系列的活動，如缺陷跟蹤、缺陷度量、缺陷分析、缺陷報告質量檢查等，而敏捷測試更關注產品本身，關注可以交付的客戶價值。在快速交付的敏捷開發模式下，缺陷修復的成本很低。
7) 傳統測試鼓勵自動化測試，但自動化測試的成功與否對測試沒有致命的影響，但敏捷測試的基礎就是自動化測試，敏捷測試是具有良好的自動化測試框架支撐的快速測試。
參考文章：
[4] Lisa Crispin, Janet Gregory著, 崔康 譯， 敏捷軟體測試：測試人員與敏捷團隊的實踐指南, 清華大學出版社，2010