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