測試自動化后，我們還需要QA嗎？(2)

　　在這個大前提下，我們再來思考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一起來設計用戶數據的采集指標(比如用戶訪問的關鍵路徑，瀏覽器版本，地區的區分等)，從而制定出新的測試策略。

原文轉自：http://icodeit.org/2016/09/what-should-qa-do-in-a-agile-team/