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