我們先討論一下在傳統(tǒng)的瀑布模型下QA是如何工作的，其中最主要的問題是什么扑毡；然后作為對比吃型，我們再來看看敏捷團(tuán)隊(duì)里的QA是如何工作的，工作重點(diǎn)又是什么僚楞；最后勤晚，我們詳細(xì)看一看在新的職責(zé)下，QA應(yīng)該如何做泉褐。

瀑布開發(fā)模型

即使在今天赐写，在很多企業(yè)中瀑布模型仍然是主流。每一個(gè)需求都需要經(jīng)過分析膜赃、設(shè)計(jì)挺邀、開發(fā)、測試跳座、上線部署端铛、運(yùn)維等階段。雖然一些企業(yè)已經(jīng)開始實(shí)施敏捷開發(fā)疲眷，比如項(xiàng)目/產(chǎn)品以迭代的方式運(yùn)作禾蚕，也有諸如每日站會、代碼檢視等敏捷實(shí)踐狂丝，但是如果仔細(xì)審視换淆，你會發(fā)現(xiàn)其實(shí)開發(fā)模式叢骨子里來說還是瀑布：按照軟件組件劃分的部門結(jié)構(gòu)（詳見康威定律）、按照職能劃分的團(tuán)隊(duì)（開發(fā)和測試分屬不同部門）几颜、過長的反饋周期倍试、永遠(yuǎn)無法擺脫的集成難題等等。

隨著軟件變得越來越復(fù)雜蛋哭，團(tuán)隊(duì)里沒有任何一個(gè)人可以說出系統(tǒng)是如何運(yùn)作的县习，也不知道最終用戶是誰，以及最終用戶會以何種方式來使用最終的軟件。

更糟糕的是躁愿，按照職能劃分的團(tuán)隊(duì)在物理上都是隔離的哈蝇，比如獨(dú)立的測試部門，獨(dú)立的運(yùn)維部門攘已，整日忙碌而難以預(yù)約到檔期的業(yè)務(wù)人員炮赦，當(dāng)然還有經(jīng)常疲于交付，無處吐槽的苦逼開發(fā)样勃。由于這些隔離吠勘，信息的反饋周期會非常長，一個(gè)本來很容易修復(fù)的缺陷可能在4周之后才會被另一個(gè)部門的測試發(fā)現(xiàn)峡眶，然后通過復(fù)雜的工作流（比如某種形式的缺陷追蹤系統(tǒng)）流到開發(fā)那里剧防，而開發(fā)可能還在拼命的完成早就應(yīng)該交付的功能，從而形成惡性循環(huán)辫樱。

瀑布模式中的QA

在這樣的環(huán)境中峭拘，QA們能做的事情非常有限。在需求開始時(shí)他們會參加需求澄清的會議狮暑，制定一些測試計(jì)劃鸡挠，然后進(jìn)行測試用例的設(shè)計(jì)。有的企業(yè)會用諸如Excel之類的工具來記錄這些用例搬男。這些寫在Excel里的拣展，“死”的用例作用非常有限。而最大的問題在于：它們無法自動化執(zhí)行缔逛。另外备埃，在實(shí)際軟件開發(fā)中，需求總是會經(jīng)常發(fā)生變化褐奴，需求的優(yōu)先級也會有調(diào)整按脚，然后這些記錄在Excel中的“死”的用例會很快過期，變得無人問津敦冬。

除此之外辅搬，QA中的有些成員會使用工具來錄制一些UI測試的場景，然后在每個(gè)新版本出來之后進(jìn)行回放匪补。然而伞辛，當(dāng)UI發(fā)生一點(diǎn)變化之后烂翰，這些自動化的用例就會失效：比如HTML片段中元素位置的調(diào)整夯缺，JavaScript的異步調(diào)用超時(shí)等等。

顯然甘耿，這種單純以黑盒形式來檢查功能點(diǎn)的測試方式是不工作的踊兜，要真正有效的提升軟件質(zhì)量，僅僅通過事后檢查遠(yuǎn)遠(yuǎn)不夠佳恬，軟件的質(zhì)量也應(yīng)該內(nèi)建于軟件之中捏境。QA的工作也應(yīng)該是一個(gè)貫穿軟件生命周期的活動于游，從商業(yè)想法到真實(shí)上線，這其中的所有環(huán)節(jié)都應(yīng)該有QA的參與垫言。

系統(tǒng)思考

如果不從一個(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)境中瓶盛，就只會有很少的，優(yōu)先級很低的缺陷示罗。

然而事實(shí)上惩猫，很多需求從開始就沒有被仔細(xì)分析，業(yè)務(wù)價(jià)值不很確定蚜点，驗(yàn)收條件模糊帆锋，流入開發(fā)后又會引入一些代碼級別的錯誤，以及業(yè)務(wù)規(guī)則上的缺陷禽额，測試階段會漏掉一些功能點(diǎn)锯厢，上線之后更是問題百出（網(wǎng)絡(luò)故障、緩存失效脯倒、黑客攻擊实辑、操作系統(tǒng)補(bǔ)丁、甚至內(nèi)存溢出藻丢、log文件將磁盤寫滿等等）剪撬。

在一個(gè)敏捷團(tuán)隊(duì)中，每個(gè)人都應(yīng)該對質(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)容斋否。

QA到底應(yīng)該干什么梨水？

本質(zhì)上來說，任何軟件項(xiàng)目的目標(biāo)都應(yīng)該是：更快地將高質(zhì)量的軟件從想法變成產(chǎn)品茵臭。

將這個(gè)大目標(biāo)細(xì)分一下疫诽，會得到這樣幾個(gè)子項(xiàng)，即企業(yè)需要：

• 更大的商業(yè)回報(bào)（發(fā)掘業(yè)務(wù)價(jià)值）
• 更短的上線時(shí)間（做最簡單，直接的版本）
• 更好的軟件質(zhì)量（質(zhì)量內(nèi)嵌）
• 更少的資源投入（減少浪費(fèi)）

其實(shí)就是傳說中的多奇徒、快雏亚、好、省摩钙。如果說這是每一個(gè)軟件項(xiàng)目的目標(biāo)的話罢低，那么團(tuán)隊(duì)里的每一個(gè)人都應(yīng)該向著這個(gè)目標(biāo)而努力，任何其他形式的工作都可以歸類為“浪費(fèi)”胖笛。用Excel記錄那些經(jīng)常會失效奕短，而且無法自動執(zhí)行的測試用例是浪費(fèi)，會因?yàn)轫撁娌季肿兓竺娣e失效的UI測試也是浪費(fèi)匀钧，一個(gè)容易修復(fù)的缺陷要等到數(shù)周之后才被發(fā)現(xiàn)也是浪費(fèi)翎碑。

在這個(gè)大前提下，我們再來思考QA在團(tuán)隊(duì)里應(yīng)該做什么以及怎么做之斯。

QA的職責(zé)

Lisa Crispin在《敏捷軟件測試》中提到過一個(gè)很著名的模型：敏捷測試四象限日杈。這個(gè)模型是QA制定測試策略時(shí)的一個(gè)重要參考：

如果按照縱向劃分的話，圖中的活動佑刷，越向上越面向業(yè)務(wù)莉擒；越向下越靠近技術(shù)。橫向劃分的話瘫絮，往左是支撐團(tuán)隊(duì)涨冀，往右是評價(jià)產(chǎn)品。

其實(shí)簡化一下麦萤，QA在團(tuán)隊(duì)里的工作鹿鳖，可以分為兩大類：

• 確保我們在正確的交付產(chǎn)品
• 確保我們交付了正確的產(chǎn)品

根據(jù)這個(gè)四象限的劃分，大部分團(tuán)隊(duì)可能都會從Q2起步：QA會和BA壮莹，甚至UX一起翅帜，從需求分析入手，繼而進(jìn)行業(yè)務(wù)場景梳理命满，這時(shí)候沒有具體的可以被測試的軟件代碼涝滴。不過這并不妨礙測試活動，比如一些紙上原型的設(shè)計(jì)：

這一階段之后胶台，我們已經(jīng)有了用戶故事歼疮，這時(shí)候QA需要和開發(fā)一起編寫用戶故事的自動化驗(yàn)收測試。當(dāng)開發(fā)交付一部分功能之后诈唬，QA就可以做常規(guī)的用戶故事測試了韩脏，幾個(gè)迭代之后，QA開始進(jìn)行跨功能需求測試和探索性測試等讯榕。根據(jù)探索性測試的結(jié)果骤素，QA可能會調(diào)整測試策略匙睹，調(diào)整測試優(yōu)先級愚屁，完善測試用例等等济竹。

根據(jù)項(xiàng)目的不同，團(tuán)隊(duì)可以從不同的象限開始測試策略的制定霎槐。事實(shí)上送浊，Q1-Q4僅僅是一個(gè)編號，與時(shí)間丘跌、階段并無關(guān)系袭景，Lisa Crispin還專門撰文解釋過。

關(guān)于QA如何在軟件分析的上游介入闭树，并通過BDD的方式與業(yè)務(wù)分析師一起產(chǎn)出軟件的各種規(guī)格描述耸棒，繼而通過實(shí)例來幫助整個(gè)團(tuán)隊(duì)對需求的理解，ThoughtWorks的林冰玉有一篇文章很好的介紹了BDD的正確做法报辱。如果將QA的外延擴(kuò)展到在線的生產(chǎn)環(huán)境与殃，制定合理的測量指標(biāo)，調(diào)整測試策略碍现，強(qiáng)烈推薦林冰玉寫的另一篇文章產(chǎn)品環(huán)境中的QA幅疼。

其他職責(zé)

事實(shí)上，軟件生命周期中有很多的活動處于灰色地段昼接。既可以說是應(yīng)該開發(fā)做爽篷，又可以說應(yīng)該QA做，甚至可以推給其他角色（比如OPs）慢睡。不過我們知道逐工，一旦涉及角色，人們就再也不會按照全局優(yōu)化的思路來應(yīng)對問題了漂辐。這種灰色的活動包括：

• 持續(xù)集成的搭建
• 測試環(huán)境的創(chuàng)建與維護(hù)
• UAT上的數(shù)據(jù)準(zhǔn)備
• 代碼中的測試代碼的維護(hù)
• 測試代碼的重構(gòu)

在團(tuán)隊(duì)實(shí)踐中钻弄，這些活動我們通常會讓QA和開發(fā)或者OPs同事一起結(jié)對來完成。一方面避免知識孤島的形成者吁，另一方面在跨角色的工作中窘俺，也可以激發(fā)出更多不同的思路。

萬能的QA复凳？

雖然在這些活動中瘤泪，QA都會參與，但并不是說團(tuán)隊(duì)里只要有一個(gè)QA就可以了育八。QA在參與這些活動時(shí)对途，側(cè)重點(diǎn)還是有很大不同的。

比如需求分析階段髓棋，如果有QA的加入实檀，一些從QA角度可以發(fā)現(xiàn)的有明顯缺陷的場景惶洲，則可以在分析階段就得到很好的處理。另一方面膳犹，盡早介入可以設(shè)計(jì)出更合理的測試計(jì)劃（比如哪些功能的優(yōu)先級比較高恬吕，用戶會更頻繁使用，那么對應(yīng)的測試比重也會更高）须床。在Story分析與書寫階段铐料，QA可以幫助寫出更加合理的驗(yàn)收條件，既滿足業(yè)務(wù)需求豺旬，又可以很好的指導(dǎo)開發(fā)钠惩。

在和開發(fā)一起編寫澄清需求時(shí)，主要是編寫自動化驗(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ū)分等）求泰，從而制定出新的測試策略央渣。

擴(kuò)展閱讀

• What is Agile testing - How does automation help?
• 敏捷實(shí)踐Showcase的七宗罪
• 產(chǎn)品環(huán)境下的QA
• 《敏捷軟件測試》

更多精彩洞見，請關(guān)注微信公眾號：ThoughtWorks