我們先討論一下在傳統的瀑布模型下QA是如何工作的，其中最主要的問題是什么；然后作為對比，我們再來看看敏捷團隊里的QA是如何工作的，工作重點又是什么；最后，我們詳細看一看在新的職責下，QA應該如何做。
瀑布開發模型
即使在今天，在很多企業中瀑布模型仍然是主流。每一個需求都需要經過分析、設計、開發、測試、上線部署、運維等階段。雖然一些企業已經開始實施敏捷開發，比如項目/產品以迭代的方式運作，也有諸如每日站會、代碼檢視等敏捷實踐，但是如果仔細審視，你會發現其實開發模式叢骨子里來說還是瀑布：按照軟件組件劃分的部門結構（詳見康威定律）、按照職能劃分的團隊（開發和測試分屬不同部門）、過長的反饋周期、永遠無法擺脫的集成難題等等。
隨著軟件變得越來越復雜，團隊里沒有任何一個人可以說出系統是如何運作的，也不知道最終用戶是誰，以及最終用戶會以何種方式來使用最終的軟件。
更糟糕的是，按照職能劃分的團隊在物理上都是隔離的，比如獨立的測試部門，獨立的運維部門，整日忙碌而難以預約到檔期的業務人員，當然還有經常疲于交付，無處吐槽的苦逼開發。由于這些隔離，信息的反饋周期會非常長，一個本來很容易修復的缺陷可能在4周之后才會被另一個部門的測試發現，然后通過復雜的工作流（比如某種形式的缺陷追蹤系統）流到開發那里，而開發可能還在拼命的完成早就應該交付的功能，從而形成惡性循環。
瀑布模式中的QA
在這樣的環境中，QA們能做的事情非常有限。在需求開始時他們會參加需求澄清的會議，制定一些測試計劃，然后進行測試用例的設計。有的企業會用諸如Excel之類的工具來記錄這些用例。這些寫在Excel里的，“死”的用例作用非常有限。而最大的問題在于：它們無法自動化執行。另外，在實際軟件開發中，需求總是會經常發生變化，需求的優先級也會有調整，然后這些記錄在Excel中的“死”的用例會很快過期，變得無人問津。
除此之外，QA中的有些成員會使用工具來錄制一些UI測試的場景，然后在每個新版本出來之后進行回放。然而，當UI發生一點變化之后，這些自動化的用例就會失效：比如HTML片段中元素位置的調整，JavaScript的異步調用超時等等。
顯然，這種單純以黑盒形式來檢查功能點的測試方式是不工作的，要真正有效的提升軟件質量，僅僅通過事后檢查遠遠不夠，軟件的質量也應該內建于軟件之中。QA的工作也應該是一個貫穿軟件生命周期的活動，從商業想法到真實上線，這其中的所有環節都應該有QA的參與。
系統思考
如果不從一個系統的角度來思考軟件質量，就無法真正構建出健壯的、讓業務和團隊都有信心的軟件系統。質量從來都不只是QA的職責，而是整個團隊的職責。
關于軟件質量，一個根深蒂固的誤解是：缺陷在開發過程中被引入，然后在測試階段被發現，最后在QA和開發的來回撕扯中被解決（或者數量被大規模降低），最后在生產環境中，就只會有很少的，優先級很低的缺陷。
然而事實上，很多需求從開始就沒有被仔細分析，業務價值不很確定，驗收條件模糊，流入開發后又會引入一些代碼級別的錯誤，以及業務規則上的缺陷，測試階段會漏掉一些功能點，上線之后更是問題百出（網絡故障、緩存失效、黑客攻擊、操作系統補丁、甚至內存溢出、log文件將磁盤寫滿等等）。
在一個敏捷團隊中，每個人都應該對質量負責，而QA則以自己的豐富經驗和獨特視角來發掘系統中可能的質量隱患，并幫助團隊將這些隱患消除。
我在ThoughtWorks的同事Anand Bagmar在他的演講What is Agile testing- How does automation help?中詳細討論過這部分內容。
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一起來設計用戶數據的采集指標（比如用戶訪問的關鍵路徑，瀏覽器版本，地區的區分等），從而制定出新的測試策略。
擴展閱讀
更多精彩洞見，請關注微信公眾號：ThoughtWorks
