我們先討論一下在傳統(tǒng)的瀑布模型下QA是如何工作的，其中最主要的問題是什么;然后作為對比，我們再來看看敏捷團隊里的QA是如何工作的，工作重點又是什么;最后，我們詳細看一看在新的職責下，QA應該如何做。
即使在今天，在很多企業(yè)中瀑布模型仍然是主流。每一個需求都需要經(jīng)過分析、設計、開發(fā)、測試、上線部署、運維等階段。雖然一些企業(yè)已經(jīng)開始實施敏捷開發(fā)，比如項目/產(chǎn)品以迭代的方式運作，也有諸如每日站會、代碼檢視等敏捷實踐，但是如果仔細審視，你會發(fā)現(xiàn)其實開發(fā)模式叢骨子里來說還是瀑布：按照軟件組件劃分的部門結構(詳見康威定律)、按照職能劃分的團隊(開發(fā)和測試分屬不同部門)、過長的反饋周期、永遠無法擺脫的集成難題等等。
隨著軟件變得越來越復雜，團隊里沒有任何一個人可以說出系統(tǒng)是如何運作的，也不知道最終用戶是誰，以及最終用戶會以何種方式來使用最終的軟件。
更糟糕的是，按照職能劃分的團隊在物理上都是隔離的，比如獨立的測試部門，獨立的運維部門，整日忙碌而難以預約到檔期的業(yè)務人員，當然還有經(jīng)常疲于交付，無處吐槽的苦逼開發(fā)。由于這些隔離，信息的反饋周期會非常長，一個本來很容易修復的缺陷可能在4周之后才會被另一個部門的測試發(fā)現(xiàn)，然后通過復雜的工作流(比如某種形式的缺陷追蹤系統(tǒng))流到開發(fā)那里，而開發(fā)可能還在拼命的完成早就應該交付的功能，從而形成惡性循環(huán)。
在這樣的環(huán)境中，QA們能做的事情非常有限。在需求開始時他們會參加需求澄清的會議，制定一些測試計劃，然后進行測試用例的設計。有的企業(yè)會用諸如Excel之類的工具來記錄這些用例。這些寫在Excel里的，“死”的用例作用非常有限。而最大的問題在于：它們無法自動化執(zhí)行。另外，在實際軟件開發(fā)中，需求總是會經(jīng)常發(fā)生變化，需求的優(yōu)先級也會有調整，然后這些記錄在Excel中的“死”的用例會很快過期，變得無人問津。
除此之外，QA中的有些成員會使用工具來錄制一些UI測試的場景，然后在每個新版本出來之后進行回放。然而，當UI發(fā)生一點變化之后，這些自動化的用例就會失效：比如HTML片段中元素位置的調整，JavaScript的異步調用超時等等。
顯然，這種單純以黑盒形式來檢查功能點的測試方式是不工作的，要真正有效的提升軟件質量，僅僅通過事后檢查遠遠不夠，軟件的質量也應該內建于軟件之中。QA的工作也應該是一個貫穿軟件生命周期的活動，從商業(yè)想法到真實上線，這其中的所有環(huán)節(jié)都應該有QA的參與。
如果不從一個系統(tǒng)的角度來思考軟件質量，就無法真正構建出健壯的、讓業(yè)務和團隊都有信心的軟件系統(tǒng)。質量從來都不只是QA的職責，而是整個團隊的職責。
關于軟件質量，一個根深蒂固的誤解是：缺陷在開發(fā)過程中被引入，然后在測試階段被發(fā)現(xiàn)，最后在QA和開發(fā)的來回撕扯中被解決(或者數(shù)量被大規(guī)模降低)，最后在生產(chǎn)環(huán)境中，就只會有很少的，優(yōu)先級很低的缺陷。
然而事實上，很多需求從開始就沒有被仔細分析，業(yè)務價值不很確定，驗收條件模糊，流入開發(fā)后又會引入一些代碼級別的錯誤，以及業(yè)務規(guī)則上的缺陷，測試階段會漏掉一些功能點，上線之后更是問題百出(網(wǎng)絡故障、緩存失效、黑客攻擊、操作系統(tǒng)補丁、甚至內存溢出、log文件將磁盤寫滿等等)。
在一個敏捷團隊中，每個人都應該對質量負責，而QA則以自己的豐富經(jīng)驗和獨特視角來發(fā)掘系統(tǒng)中可能的質量隱患，并幫助團隊將這些隱患消除。
我在ThoughtWorks的同事Anand Bagmar在他的演講What is Agile testing- How does automation help?中詳細討論過這部分內容。
本質上來說，任何軟件項目的目標都應該是：更快地將高質量的軟件從想法變成產(chǎn)品。
將這個大目標細分一下，會得到這樣幾個子項，即企業(yè)需要：
其實就是傳說中的多、快、好、省。如果說這是每一個軟件項目的目標的話，那么團隊里的每一個人都應該向著這個目標而努力，任何其他形式的工作都可以歸類為“浪費”。用Excel記錄那些經(jīng)常會失效，而且無法自動執(zhí)行的測試用例是浪費，會因為頁面布局變化而大面積失效的UI測試也是浪費，一個容易修復的缺陷要等到數(shù)周之后才被發(fā)現(xiàn)也是浪費。
在這個大前提下，我們再來思考QA在團隊里應該做什么以及怎么做。
Lisa Crispin在《敏捷軟件測試》中提到過一個很著名的模型：敏捷測試四象限。這個模型是QA制定測試策略時的一個重要參考：
如果按照縱向劃分的話，圖中的活動，越向上越面向業(yè)務;越向下越靠近技術。橫向劃分的話，往左是支撐團隊，往右是評價產(chǎn)品。
其實簡化一下，QA在團隊里的工作，可以分為兩大類：
根據(jù)這個四象限的劃分，大部分團隊可能都會從Q2起步：QA會和BA，甚至UX一起，從需求分析入手，繼而進行業(yè)務場景梳理，這時候沒有具體的可以被測試的軟件代碼。不過這并不妨礙測試活動，比如一些紙上原型的設計：
這一階段之后，我們已經(jīng)有了用戶故事，這時候QA需要和開發(fā)一起編寫用戶故事的自動化驗收測試。當開發(fā)交付一部分功能之后，QA就可以做常規(guī)的用戶故事測試了，幾個迭代之后，QA開始進行跨功能需求測試和探索性測試等。根據(jù)探索性測試的結果，QA可能會調整測試策略，調整測試優(yōu)先級，完善測試用例等等。
根據(jù)項目的不同，團隊可以從不同的象限開始測試策略的制定。事實上，Q1-Q4僅僅是一個編號，與時間、階段并無關系，Lisa Crispin還專門撰文解釋過。
關于QA如何在軟件分析的上游介入，并通過BDD的方式與業(yè)務分析師一起產(chǎn)出軟件的各種規(guī)格描述，繼而通過實例來幫助整個團隊對需求的理解，ThoughtWorks的林冰玉有一篇文章很好的介紹了BDD的正確做法。如果將QA的外延擴展到在線的生產(chǎn)環(huán)境，制定合理的測量指標，調整測試策略，強烈推薦林冰玉寫的另一篇文章產(chǎn)品環(huán)境中的QA。
事實上，軟件生命周期中有很多的活動處于灰色地段。既可以說是應該開發(fā)做，又可以說應該QA做，甚至可以推給其他角色(比如OPs)。不過我們知道，一旦涉及角色，人們就再也不會按照全局優(yōu)化的思路來應對問題了。這種灰色的活動包括：
在團隊實踐中，這些活動我們通常會讓QA和開發(fā)或者OPs同事一起結對來完成。一方面避免知識孤島的形成，另一方面在跨角色的工作中，也可以激發(fā)出更多不同的思路。
雖然在這些活動中，QA都會參與，但并不是說團隊里只要有一個QA就可以了。QA在參與這些活動時，側重點還是有很大不同的。
比如需求分析階段，如果有QA的加入，一些從QA角度可以發(fā)現(xiàn)的有明顯缺陷的場景，則可以在分析階段就得到很好的處理。另一方面，盡早介入可以設計出更合理的測試計劃(比如哪些功能的優(yōu)先級比較高，用戶會更頻繁使用，那么對應的測試比重也會更高)。在Story分析與書寫階段，QA可以幫助寫出更加合理的驗收條件，既滿足業(yè)務需求，又可以很好的指導開發(fā)。
在和開發(fā)一起編寫澄清需求時，主要是編寫自動化驗收測試，而不是實際編寫業(yè)務邏輯的實現(xiàn)(雖然QA應該參與Code Reivew環(huán)節(jié)，學習并分享自己的觀點);甚至在上線運維階段，QA還需要和OPs一起來設計用戶數(shù)據(jù)的采集指標(比如用戶訪問的關鍵路徑，瀏覽器版本，地區(qū)的區(qū)分等)，從而制定出新的測試策略。
海淘科技不僅提供，文章下載，點擊：測試自動化后 我們需要什么樣的QA？。而且提供搜索引擎seo推廣文章和網(wǎng)站建設服務。
