我們先討論一下在傳統的瀑布模型下QA是如何工作的，其中最主要的問題是什麼；然後作為對比，我們再來看看敏捷團隊裡的QA是如何工作的，工作重點又是什麼；最後，我們詳細看一看在新的職責下，QA應該如何做。

瀑布開發模型

即使在今天，在很多企業中瀑布模型仍然是主流。每一個需求都需要經過分析、設計、開發、測試、上線部署、運維等階段。雖然一些企業已經開始實施敏捷開發，比如專案/產品以迭代的方式運作，也有諸如每日站會、程式碼檢視等敏捷實踐，但是如果仔細審視，你會發現其實開發模式叢骨子裡來說還是瀑布：按照軟體元件劃分的部門結構（詳見康威定律）、按照職能劃分的團隊（開發和測試分屬不同部門）、過長的反饋週期、永遠無法擺脫的整合難題等等。

隨著軟體變得越來越複雜，團隊裡沒有任何一個人可以說出系統是如何運作的，也不知道終端使用者是誰，以及終端使用者會以何種方式來使用最終的軟體。

更糟糕的是，按照職能劃分的團隊在物理上都是隔離的，比如獨立的測試部門，獨立的運維部門，整日忙碌而難以預約到檔期的業務人員，當然還有經常疲於交付，無處吐槽的苦逼開發。由於這些隔離，資訊的反饋週期會非常長，一個本來很容易修復的缺陷可能在4周之後才會被另一個部門的測試發現，然後通過複雜的工作流（比如某種形式的缺陷追蹤系統）流到開發那裡，而開發可能還在拼命的完成早就應該交付的功能，從而形成惡性迴圈。

瀑布模式中的QA

在這樣的環境中，QA們能做的事情非常有限。在需求開始時他們會參加需求澄清的會議，制定一些測試計劃，然後進行測試用例的設計。有的企業會用諸如Excel之類的工具來記錄這些用例。這些寫在Excel裡的，“死”的用例作用非常有限。而最大的問題在於：它們無法自動化執行

除此之外，QA中的有些成員會使用工具來錄製一些UI測試的場景，然後在每個新版本出來之後進行回放。然而，當UI發生一點變化之後，這些自動化的用例就會失效：比如HTML片段中元素位置的調整，JavaScript的非同步呼叫超時等等。

顯然，這種單純以黑盒形式來檢查功能點的測試方式是不工作的，要真正有效的提升軟體質量，僅僅通過事後檢查遠遠不夠，軟體的質量也應該內建於軟體之中。QA的工作也應該是一個貫穿軟體生命週期的活動，從商業想法到真實上線，這其中的所有環節都應該有QA的參與。

系統思考

如果不從一個系統的角度來思考軟體質量，就無法真正構建出健壯的、讓業務和團隊都有信心的軟體系統。質量從來都不只是QA的職責，而是整個團隊的職責。

關於軟體質量，一個根深蒂固的誤解是：缺陷在開發過程中被引入，然後在測試階段被發現，最後在QA和開發的來回撕扯中被解決（或者數量被大規模降低），最後在生產環境中，就只會有很少的，優先順序很低的缺陷。

然而事實上，很多需求從開始就沒有被仔細分析，業務價值不很確定，驗收條件模糊，流入開發後又會引入一些程式碼級別的錯誤，以及業務規則上的缺陷，測試階段會漏掉一些功能點，上線之後更是問題百出（網路故障、快取失效、黑客攻擊、作業系統補丁、甚至記憶體溢位、log檔案將磁碟寫滿等等）。

在一個敏捷團隊中，每個人都應該對質量負責，而QA則以自己的豐富經驗和獨特視角來發掘系統中可能的質量隱患，並幫助團隊將這些隱患消除。

QA到底應該幹什麼？

本質上來說，任何軟體專案的目標都應該是：更快地將高質量的軟體從想法變成產品。

將這個大目標細分一下，會得到這樣幾個子項，即企業需要：

• 更大的商業回報（發掘業務價值）
• 更短的上線時間（做最簡單，直接的版本）
• 更好的軟體質量（質量內嵌）
• 更少的資源投入（減少浪費）

其實就是傳說中的多、快、好、省。如果說這是每一個軟體專案的目標的話，那麼團隊裡的每一個人都應該向著這個目標而努力，任何其他形式的工作都可以歸類為“浪費”。用Excel記錄那些經常會失效，而且無法自動執行的測試用例是浪費，會因為頁面佈局變化而大面積失效的UI測試也是浪費，一個容易修復的缺陷要等到數週之後才被發現也是浪費。

在這個大前提下，我們再來思考QA在團隊裡應該做什麼以及怎麼做。

QA的職責

Lisa Crispin在《敏捷軟體測試》中提到過一個很著名的模型：敏捷測試四象限。這個模型是QA制定測試策略時的一個重要參考：

如果按照縱向劃分的話，圖中的活動，越向上越面向業務；越向下越靠近技術。橫向劃分的話，往左是支撐團隊，往右是評價產品。

其實簡化一下，QA在團隊裡的工作，可以分為兩大類：

• 確保我們在正確的交付產品
• 確保我們交付了正確的產品

根據這個四象限的劃分，大部分團隊可能都會從Q2起步：QA會和BA，甚至UX一起，從需求分析入手，繼而進行業務場景梳理，這時候沒有具體的可以被測試的軟體程式碼。不過這並不妨礙測試活動，比如一些紙上原型的設計：

這一階段之後，我們已經有了使用者故事，這時候QA需要和開發一起編寫使用者故事的自動化驗收測試。當開發交付一部分功能之後，QA就可以做常規的使用者故事測試了，幾個迭代之後，QA開始進行跨功能需求測試和探索性測試等。根據探索性測試的結果，QA可能會調整測試策略，調整測試優先順序，完善測試用例等等。

根據專案的不同，團隊可以從不同的象限開始測試策略的制定。事實上，Q1-Q4僅僅是一個編號，與時間、階段並無關係，Lisa Crispin還專門撰文解釋過。

關於QA如何在軟體分析的上游介入，並通過BDD的方式與業務分析師一起產出軟體的各種規格描述，繼而通過例項來幫助整個團隊對需求的理解，ThoughtWorks的林冰玉有一篇文章很好的介紹了BDD的正確做法。如果將QA的外延擴充套件到線上的生產環境，制定合理的測量指標，調整測試策略，強烈推薦林冰玉寫的另一篇文章產品環境中的QA。

其他職責

事實上，軟體生命週期中有很多的活動處於灰色地段。既可以說是應該開發做，又可以說應該QA做，甚至可以推給其他角色（比如OPs）。不過我們知道，一旦涉及角色，人們就再也不會按照全域性優化的思路來應對問題了。這種灰色的活動包括：

• 持續整合的搭建
• 測試環境的建立與維護
• UAT上的資料準備
• 程式碼中的測試程式碼的維護
• 測試程式碼的重構

在團隊實踐中，這些活動我們通常會讓QA和開發或者OPs同事一起結對來完成。一方面避免知識孤島的形成，另一方面在跨角色的工作中，也可以激發出更多不同的思路。

萬能的QA？

雖然在這些活動中，QA都會參與，但並不是說團隊裡只要有一個QA就可以了。QA在參與這些活動時，側重點還是有很大不同的。

比如需求分析階段，如果有QA的加入，一些從QA角度可以發現的有明顯缺陷的場景，則可以在分析階段就得到很好的處理。另一方面，儘早介入可以設計出更合理的測試計劃（比如哪些功能的優先順序比較高，使用者會更頻繁使用，那麼對應的測試比重也會更高）。在Story分析與書寫階段，QA可以幫助寫出更加合理的驗收條件，既滿足業務需求，又可以很好的指導開發。

在和開發一起編寫澄清需求時，主要是編寫自動化驗收測試，而不是實際編寫業務邏輯的實現（雖然QA應該參與Code Reivew環節，學習並分享自己的觀點）；甚至在上線運維階段，QA還需要和OPs一起來設計使用者資料的採集指標（比如使用者訪問的關鍵路徑，瀏覽器版本，地區的區分等），從而制定出新的測試策略。