“沒有專職的測(cè)試人員？

代碼提交就直接發(fā)布到生產(chǎn)環(huán)境？

而且，一天還可以發(fā)布多次？”

對(duì)于很多團(tuán)隊(duì)來說，這是完全不可能的事情！他們都是怎么做到的？

01 兩個(gè)案例

相信很多人都對(duì)前面這些問題很好奇，在解開謎團(tuán)之前，我們先來看兩個(gè)案例。

案例1

隨著互聯(lián)網(wǎng)業(yè)務(wù)的發(fā)展，某行業(yè)核心系統(tǒng)為了面對(duì)互聯(lián)網(wǎng)的挑戰(zhàn)，需要對(duì)系統(tǒng)進(jìn)行改造?？墒?，真想改起來卻寸步難行……

該系統(tǒng)已經(jīng)有十多年的歷史，業(yè)務(wù)規(guī)則復(fù)雜，業(yè)務(wù)邏輯代碼全部都在數(shù)據(jù)庫腳本層；缺乏有效的業(yè)務(wù)文檔，需求分析文檔是以系統(tǒng)頁面流轉(zhuǎn)和操作步驟為主的形式，開發(fā)和測(cè)試人員對(duì)業(yè)務(wù)沒有清晰的概念，只是知道系統(tǒng)有哪些操作，某個(gè)操作對(duì)應(yīng)的真實(shí)業(yè)務(wù)并不清楚。

面對(duì)幾百萬行代碼的改造，沒有業(yè)務(wù)上下文的支撐，其難度可想而知。

案例2

某團(tuán)隊(duì)開發(fā)半年的一個(gè)網(wǎng)站在上線前一個(gè)多月發(fā)現(xiàn)根本沒法正常運(yùn)行，被迫延期半年后才上線……

原來，該網(wǎng)站是基于一個(gè)第三方平臺(tái)開發(fā)，由于業(yè)務(wù)的特殊性需要支持2TB的數(shù)據(jù)量。但是，該第三方平臺(tái)并沒有驗(yàn)證過可以支持這么大的數(shù)據(jù)量，在上線前一個(gè)多月UAT環(huán)境準(zhǔn)備就緒，系統(tǒng)在UAT運(yùn)行的時(shí)候完全垮掉。

在進(jìn)退兩難的情況下，團(tuán)隊(duì)也只有硬著頭皮往前走，一邊優(yōu)化自己開發(fā)的程序的性能，一邊還要協(xié)助第三方平臺(tái)進(jìn)行升級(jí)……團(tuán)隊(duì)所經(jīng)歷的種種心酸也是不言而喻。

02 傳統(tǒng)質(zhì)量保障之痛

案例分析

前面兩個(gè)案例的痛我們都能感覺到，那么問題到底出在哪里？

案例1：寸步難行的遺留系統(tǒng)

• 缺乏業(yè)務(wù)上下文：沒有有效的業(yè)務(wù)價(jià)值傳遞方式，團(tuán)隊(duì)的溝通都是基于系統(tǒng)行為進(jìn)行，開發(fā)和測(cè)試了解到的都是頁面流轉(zhuǎn)方式和具體的操作，難以識(shí)別業(yè)務(wù)高風(fēng)險(xiǎn)問題；
• 缺乏系統(tǒng)的設(shè)計(jì)，代碼沒有分層，不能體現(xiàn)業(yè)務(wù)，也很難編寫有效的自動(dòng)化測(cè)試來保障質(zhì)量。

案例2：延期半年才成功上線的網(wǎng)站

• 分析、開發(fā)、測(cè)試都沒有考慮真實(shí)業(yè)務(wù)需求，缺乏性能風(fēng)險(xiǎn)意識(shí)，只關(guān)注了功能需求；
• 第三方系統(tǒng)沒有驗(yàn)證，對(duì)第三方系統(tǒng)并沒有有效的風(fēng)險(xiǎn)評(píng)估；
• 測(cè)試環(huán)境準(zhǔn)備不夠及時(shí)，上線前一個(gè)多月才準(zhǔn)備好的UAT環(huán)境也是導(dǎo)致更晚發(fā)現(xiàn)性能問題的原因之一。

從質(zhì)量保障到質(zhì)量保障賦能

在傳統(tǒng)的質(zhì)量保障模式下，前面案例所發(fā)生的事情并不少見。隨著業(yè)務(wù)和技術(shù)的不斷發(fā)展，對(duì)傳統(tǒng)系統(tǒng)的質(zhì)量之痛，相信大家都是深有體會(huì)。

一方面，靠獨(dú)立的測(cè)試團(tuán)隊(duì)把關(guān)質(zhì)量，靠滯后的測(cè)試階段來測(cè)試、發(fā)現(xiàn)系統(tǒng)的問題，導(dǎo)致大量時(shí)間的浪費(fèi)和成本的升高。

另一方面，不同角色的人員相互獨(dú)立、甚至有著高高的部門壁壘，是一種相對(duì)對(duì)立而不是合作的關(guān)系。普遍認(rèn)為測(cè)試是最終要對(duì)質(zhì)量把關(guān)和負(fù)責(zé)的，其他角色各自做好自己階段范圍內(nèi)的工作就好，形成了一種“各人自掃門前雪”的局面，而沒人能將業(yè)務(wù)需求到產(chǎn)品整個(gè)串起來，確保是否開發(fā)了正確的系統(tǒng)。

這樣的質(zhì)量保障方式已經(jīng)不能適應(yīng)今天的發(fā)展，需要團(tuán)隊(duì)整體對(duì)質(zhì)量負(fù)責(zé)。要讓習(xí)慣了“自掃門前雪”的團(tuán)隊(duì)不同角色都能做到為質(zhì)量負(fù)責(zé)，不是喊喊口號(hào)就可以做到的。因此，如何對(duì)團(tuán)隊(duì)進(jìn)行質(zhì)量保障賦能成為搞好質(zhì)量的關(guān)鍵。

03 團(tuán)隊(duì)的質(zhì)量保障賦能

開篇提到的那幾個(gè)問題說的就是前沿的互聯(lián)網(wǎng)科技公司Google、Amazon和Facebook等，他們都是質(zhì)量保障賦能做的非常好的典范。

大公司都是怎么做的？

通過對(duì)那些大公司的軟件交付實(shí)踐進(jìn)行調(diào)研分析，不難得出以下幾個(gè)方面的共性：

• 全流程標(biāo)準(zhǔn)化
• 大規(guī)模自動(dòng)化
• 所有權(quán)（Ownership）

1.全流程標(biāo)準(zhǔn)化

全流程標(biāo)準(zhǔn)化，從字面意思就可以理解，指的就是嚴(yán)格設(shè)定整個(gè)軟件開發(fā)流程，流程上每個(gè)環(huán)節(jié)的具體做法都有標(biāo)準(zhǔn)的定義。更進(jìn)一步，可以理解為兩個(gè)方面的內(nèi)容：標(biāo)準(zhǔn)流程和標(biāo)準(zhǔn)實(shí)踐。

標(biāo)準(zhǔn)流程

流程可能包括需求計(jì)劃、代碼審查、靜態(tài)掃描、動(dòng)態(tài)測(cè)試、部署發(fā)布、監(jiān)控等，流程標(biāo)準(zhǔn)化就是定義清楚流程中都有哪些環(huán)節(jié)。

為了保證流程的標(biāo)準(zhǔn)化，最常見的做法就是采用流水線，以及流水線上的標(biāo)準(zhǔn)工具來實(shí)現(xiàn)。

• Google的分布式構(gòu)建系統(tǒng)Blaze、基于Web的代碼評(píng)審工具、用于單元測(cè)試的Mocking框架、缺陷跟蹤工具Buganizer、發(fā)布驗(yàn)收審核工具等。
• Amazon也有很多構(gòu)建者工具（Builder's tool）供整個(gè)軟件開發(fā)和交付流程使用。所有團(tuán)隊(duì)采用同樣的系統(tǒng)和工具，對(duì)于流程的標(biāo)準(zhǔn)化是很重要的一部分。

然而，工具并不能獨(dú)自保障標(biāo)準(zhǔn)化的實(shí)施，有些環(huán)節(jié)還需要結(jié)合規(guī)則或者政策進(jìn)行一定的約束來做到，如代碼提交規(guī)則、測(cè)試覆蓋率的要求、失敗回滾政策、發(fā)布的規(guī)則等。

• Amazon提供模板告訴人們正確的做法，并且采用政策來阻止新人犯錯(cuò)，同時(shí)鼓勵(lì)人們創(chuàng)建更多的政策來優(yōu)化以找到最優(yōu)的實(shí)踐方案，一旦有錯(cuò)誤出現(xiàn)就會(huì)添加新的相關(guān)政策來優(yōu)化，比如：?jiǎn)卧獪y(cè)試覆蓋率不能低于70%、每次部署不允許同時(shí)部署到所有區(qū)域（Region）等。
• Google和Facebook也都有類似的一些規(guī)則，比如代碼必須有一名代碼所有者、并且是除作者以外的一人評(píng)審?fù)ㄟ^才能提交。

標(biāo)準(zhǔn)實(shí)踐

標(biāo)準(zhǔn)流程之外，一些標(biāo)準(zhǔn)的實(shí)踐也屬于全流程標(biāo)準(zhǔn)化的一部分。當(dāng)然，在標(biāo)準(zhǔn)流程各個(gè)環(huán)節(jié)所采用的也都是標(biāo)準(zhǔn)實(shí)踐，這里單獨(dú)列出只是想進(jìn)一步強(qiáng)調(diào)標(biāo)準(zhǔn)實(shí)踐的重要性。流程外的標(biāo)準(zhǔn)實(shí)踐主要是針對(duì)標(biāo)準(zhǔn)流程以外的一些特定領(lǐng)域或者特定場(chǎng)景下的實(shí)踐，像針對(duì)安全領(lǐng)域的威脅建模、針對(duì)微服務(wù)架構(gòu)帶來的不確定性的混沌工程等。

• 對(duì)安全性要求特別高的Amazon則要求所有軟件工程師都像安全工程師一樣思考，在軟件開發(fā)初期需要考慮安全模型，并且構(gòu)建的安全模型需要通過安全專家的評(píng)審。

事實(shí)標(biāo)準(zhǔn)與書面標(biāo)準(zhǔn)

說到標(biāo)準(zhǔn)化，可能有人會(huì)說：“我們也在做標(biāo)準(zhǔn)化，也有指標(biāo)和規(guī)則要求，比如有持續(xù)集成流水線，要求做代碼評(píng)審，要求單元測(cè)試覆蓋率不能低于多少，要求用戶故事的開發(fā)速度一個(gè)點(diǎn)兩天完成等等，可是我們還是做不到一天多次發(fā)布……”

這似乎是我們見得很多的標(biāo)準(zhǔn)化，這種標(biāo)準(zhǔn)化更多的是停留在書面的一些指標(biāo)要求，而具體怎么實(shí)現(xiàn)指標(biāo)其實(shí)有很多的方式……
比如：

• 流水線每個(gè)團(tuán)隊(duì)有自己的配置，采用什么工具、跑哪些測(cè)試沒有統(tǒng)一的模式，測(cè)試掛了第一個(gè)動(dòng)作是重跑或者先將遲遲難以修復(fù)的測(cè)試忽略掉；
• 代碼評(píng)審可能就是每天要來一次的一種儀式，至于效率和質(zhì)量，也沒什么衡量；
• 單元測(cè)試為了滿足指標(biāo)要求，專挑容易的寫測(cè)試，并不區(qū)分業(yè)務(wù)優(yōu)先級(jí)；
• 用戶故事開發(fā)卡著天數(shù)完成，而忽略是否真正實(shí)現(xiàn)了業(yè)務(wù)所需，也顧不上質(zhì)量是否滿足要求……

這樣的結(jié)果是表面看起來指標(biāo)都很漂亮，而質(zhì)量卻令人堪憂。這是一種書面標(biāo)準(zhǔn)，很難真正做到質(zhì)量保障賦能。

前面分析的Google、Amazon和Facebook除了有書面的指標(biāo)要求，更多的是規(guī)定了實(shí)現(xiàn)指標(biāo)的路徑，比如：各團(tuán)隊(duì)統(tǒng)一的代碼倉庫管理與嚴(yán)格的代碼提交權(quán)限，各個(gè)環(huán)節(jié)規(guī)定統(tǒng)一工具的使用、統(tǒng)一的模板和政策，使得整個(gè)軟件開發(fā)和交付流程只有一種選擇，并且遵循這些規(guī)則和路徑一定可以實(shí)現(xiàn)指標(biāo)的要求。

這是一種事實(shí)標(biāo)準(zhǔn)，比書面標(biāo)準(zhǔn)能夠更好的做到質(zhì)量保障賦能。

2.大規(guī)模自動(dòng)化

說到自動(dòng)化，大家很容易想到了自動(dòng)化測(cè)試。其實(shí)，這里說的大規(guī)模自動(dòng)化，不僅有大規(guī)模的測(cè)試自動(dòng)化，還包括大規(guī)模的流程自動(dòng)化。

自動(dòng)化測(cè)試當(dāng)然是跟流水線和標(biāo)準(zhǔn)化分不開的，通常流水線上自動(dòng)化測(cè)試不僅有動(dòng)態(tài)的測(cè)試腳本執(zhí)行，也有靜態(tài)的自動(dòng)代碼掃描。

• Google、Amazon和Facebook都是對(duì)自動(dòng)化測(cè)試要求比較高的，除了單元測(cè)試、集成測(cè)試、端到端測(cè)試外，還都非常關(guān)注自動(dòng)化的性能測(cè)試，如負(fù)載測(cè)試是部署前必須完成的測(cè)試。

流程自動(dòng)化

測(cè)試自動(dòng)化主要是用來驗(yàn)證系統(tǒng)是否按照預(yù)期在運(yùn)行，保證的是軟件系統(tǒng)的質(zhì)量。而流程自動(dòng)化是保障流程更高效、更正確執(zhí)行的非常重要的手段。

• Amazon提倡的是自動(dòng)化每一件事情，也就是軟件開發(fā)流程中所有手動(dòng)完成的任務(wù)都做到自動(dòng)化完成。這種自動(dòng)化一切的做法，使得每次代碼提交可以直接部署到生產(chǎn)環(huán)境，不僅有測(cè)試的保證，也不需要人為的干預(yù)。構(gòu)建了很多的檢查器（Checker）來檢查整個(gè)流水線上強(qiáng)制政策執(zhí)行情況，比如：?jiǎn)卧獪y(cè)試覆蓋率低于70%不讓提交、AWS同時(shí)部署多個(gè)區(qū)域會(huì)自動(dòng)中止并自動(dòng)回滾等。
• Google同樣有工具自動(dòng)度量單元測(cè)試覆蓋率，并且可以通過工具自動(dòng)地推薦合適的代碼評(píng)審人員等。

3.所有權(quán)（Ownership）

另一個(gè)共性是所有權(quán)制度，這是一種可以激勵(lì)員工內(nèi)在動(dòng)力去主動(dòng)承擔(dān)質(zhì)量保障職責(zé)的方式。就好比父母會(huì)對(duì)自己的孩子負(fù)責(zé)那樣，代碼、服務(wù)、產(chǎn)品所有者也會(huì)比較容易積極主動(dòng)的去對(duì)自己所有的代碼、服務(wù)、產(chǎn)品這些個(gè)“孩子”負(fù)責(zé)。

• Google和Facebook的代碼所有權(quán)制度，任何人改代碼都得有所有者的許可，這對(duì)代碼質(zhì)量的保障是很有效的。
• Facebook的開發(fā)人員需要負(fù)責(zé)支持所開發(fā)產(chǎn)品的運(yùn)維工作，使得他們更加重視質(zhì)量。
• Amazon是每個(gè)小團(tuán)隊(duì)負(fù)責(zé)一個(gè)服務(wù)，不僅需要負(fù)責(zé)開發(fā)和運(yùn)維，還需要自行制定需求計(jì)劃。采用由下往上發(fā)起計(jì)劃的方式，由一線員工去計(jì)劃接下來的開發(fā)內(nèi)容，因?yàn)樗麄冏罱咏蛻簟⒆钋宄蛻羲龅降膯栴}和真正的需求。這樣的方式讓增強(qiáng)了工程師的使命感，從而對(duì)質(zhì)量更加重視、更有意愿去把質(zhì)量搞好。

然而，任何實(shí)踐都有兩面性，用的不好可能帶來壞的結(jié)果。所有權(quán)制度也可能導(dǎo)致跟我們提倡的“團(tuán)隊(duì)共同承擔(dān)質(zhì)量保障職責(zé)”產(chǎn)生矛盾，形成不同的利益群體，真正遇到問題的時(shí)候發(fā)生“踢皮球”現(xiàn)象。因此，所有權(quán)實(shí)踐也是需要小心謹(jǐn)慎的，注意評(píng)估、持續(xù)改進(jìn)很重要，也可以由小團(tuán)隊(duì)共同承擔(dān)所有權(quán)職責(zé)的方式，或者不同的人或團(tuán)隊(duì)輪流承擔(dān)所有權(quán)職責(zé)。

• 像Google的構(gòu)建警察，就是由有經(jīng)驗(yàn)的同事輪流來擔(dān)任的。

三者有機(jī)結(jié)合

標(biāo)準(zhǔn)化和自動(dòng)化相輔相成，標(biāo)準(zhǔn)化做的好就能更方便的實(shí)現(xiàn)自動(dòng)化，而自動(dòng)化又是有助于標(biāo)準(zhǔn)化實(shí)現(xiàn)的手段。

全面的標(biāo)準(zhǔn)化和自動(dòng)化使得犯錯(cuò)幾率降低，加快了軟件交付速度，但同時(shí)也可能影響技術(shù)人員的能力提升。因此，需要鼓勵(lì)團(tuán)隊(duì)創(chuàng)新，將經(jīng)驗(yàn)教訓(xùn)固化為新的規(guī)則政策，創(chuàng)建新的和優(yōu)化已有的標(biāo)準(zhǔn)。這些流程實(shí)踐并不是一成不變的，而是不斷演進(jìn)完善的。

鼓勵(lì)創(chuàng)新是公司提供的文化氛圍，是一種外在的激勵(lì)因素，而所有權(quán)制度是可以激勵(lì)員工內(nèi)在動(dòng)力的方式。

所有權(quán)制度也可能帶來負(fù)面的效果，不僅需要時(shí)刻回顧和改進(jìn)，還務(wù)必跟標(biāo)準(zhǔn)化和自動(dòng)化結(jié)合起來，以形成有機(jī)整體，盡量減少任何一個(gè)實(shí)踐帶來的負(fù)面影響。

因此，標(biāo)準(zhǔn)化、自動(dòng)化和所有權(quán)三者有機(jī)結(jié)合，是質(zhì)量保障賦能成功的關(guān)鍵。

其他質(zhì)量保障賦能實(shí)踐

標(biāo)準(zhǔn)化、自動(dòng)化做的那么好的，那都是別人家的公司。而我們大多數(shù)的公司或團(tuán)隊(duì)，由于企業(yè)文化、組織架構(gòu)、思維習(xí)慣、人員能力、基礎(chǔ)設(shè)施等因素的影響，要做好質(zhì)量保障賦能非常地難。

做不到別人家的公司那樣，我們?cè)诔吮M力做到標(biāo)準(zhǔn)化和自動(dòng)化之外，還能做些什么？下面分享我和同事在Thoughtworks經(jīng)歷的一些實(shí)踐。

測(cè)試全流程介入

“全程的測(cè)試介入”是被我們寫進(jìn)敏捷測(cè)試宣言的一條價(jià)值觀，測(cè)試左移、持續(xù)測(cè)試和測(cè)試右移都是價(jià)值觀具體的體現(xiàn)。

從賦能的角度來看，敏捷開發(fā)團(tuán)隊(duì)的QA全流程介入，參與多個(gè)環(huán)節(jié)，承擔(dān)賦能者的職責(zé)，起到幫助團(tuán)隊(duì)做好質(zhì)量保障賦能的作用，具體的實(shí)踐可以總結(jié)為以下三個(gè)方面的內(nèi)容。

模板或清單（Template/Checklist）

QA跟不同角色共同制定一系列的模板或者清單，以幫助該角色更清晰的了解到所處環(huán)節(jié)需要考慮或者完成的事情。這些模板或清單可能是：

• 需求分析清單/用戶故事模板：包括用戶故事價(jià)值描述、帶需求實(shí)例的驗(yàn)收條件、性能和安全需求檢查點(diǎn)等，以盡量減少需求分析階段的遺漏點(diǎn)；
• 完成的定義（Definition of Done，DoD）：清晰定義用戶故事開發(fā)完成的條件，以幫助開發(fā)人員確認(rèn)用戶故事開發(fā)過程中需要做的事情；
• 發(fā)布清單：定義發(fā)布流程中的任務(wù)以及需要注意的點(diǎn)，讓發(fā)布流程更加順暢；
• 線上事故診斷信息收集清單：對(duì)于線上事故的診斷，需要第一時(shí)間收集哪些相關(guān)信息，以幫助更快速的定位問題；
• ……

結(jié)對(duì)或評(píng)審（Pair/Review）

QA通過與不同角色的結(jié)對(duì)，可以把測(cè)試技能和對(duì)質(zhì)量的關(guān)注意識(shí)傳遞給其他角色，以提高整個(gè)團(tuán)隊(duì)的整體質(zhì)量意識(shí)。

跟不同角色的結(jié)對(duì)實(shí)踐可以有：跟BA結(jié)拆分用戶故事和編寫驗(yàn)收條件，跟開發(fā)結(jié)對(duì)拆分任務(wù)、實(shí)現(xiàn)端到端自動(dòng)化測(cè)試，跟運(yùn)維結(jié)對(duì)設(shè)定線上監(jiān)控與分析等。

除了結(jié)對(duì)，QA還可以通過評(píng)審的方式傳遞質(zhì)量意識(shí)，比如用戶故事、單元測(cè)試、日志記錄情況的評(píng)審等。

質(zhì)量主題分享或工作坊

QA可以定期跟團(tuán)隊(duì)分享質(zhì)量保障內(nèi)容，也可以邀請(qǐng)不同角色的同事一起來分享，這些內(nèi)容可以是：質(zhì)量保障小知識(shí)、項(xiàng)目測(cè)試策略與計(jì)劃、項(xiàng)目質(zhì)量狀態(tài)與風(fēng)險(xiǎn)、一些典型bug的發(fā)現(xiàn)過程或者診斷定位過程。

除了獨(dú)立的分享以外，還可以通過工作坊的形式邀請(qǐng)團(tuán)隊(duì)成員深度參與體驗(yàn)，比如：頭腦風(fēng)暴測(cè)試方案、缺陷根因的深度分析、bug大掃除（bug bash）、生產(chǎn)環(huán)境支持策略和流程的改進(jìn)等。

這樣的兩種方式，一方面有助于幫助團(tuán)隊(duì)普及質(zhì)量知識(shí)和提高質(zhì)量意識(shí)，另一方面讓團(tuán)隊(duì)不同角色對(duì)質(zhì)量有更深的體會(huì)、更強(qiáng)的參與感，從而也就有了更大的責(zé)任感，起到賦能的效果。

業(yè)務(wù)價(jià)值驅(qū)動(dòng)測(cè)試

交付業(yè)務(wù)價(jià)值是軟件開發(fā)的根本目的，如果沒能清晰理解業(yè)務(wù)價(jià)值，在開發(fā)過程中跟業(yè)務(wù)價(jià)值有偏離，將會(huì)帶來很大的浪費(fèi)。雖然大家都知道業(yè)務(wù)價(jià)值的重要性，然而業(yè)務(wù)價(jià)值要讓整個(gè)團(tuán)隊(duì)都能很清晰的理解，并不是一件容易的事情。

我們特別強(qiáng)調(diào)業(yè)務(wù)價(jià)值驅(qū)動(dòng)測(cè)試，所采取的業(yè)務(wù)價(jià)值驅(qū)動(dòng)的測(cè)試實(shí)踐，有助于將業(yè)務(wù)價(jià)值傳遞給整個(gè)團(tuán)隊(duì)，讓業(yè)務(wù)價(jià)值跟系統(tǒng)實(shí)現(xiàn)和測(cè)試緊密關(guān)聯(lián)起來。

關(guān)于業(yè)務(wù)價(jià)值驅(qū)動(dòng)測(cè)試的更多內(nèi)容，可以參考我之前的文章《業(yè)務(wù)價(jià)值驅(qū)動(dòng)的測(cè)試》。

缺陷分析

傳遞業(yè)務(wù)價(jià)值是正向的幫助團(tuán)隊(duì)開發(fā)正確的軟件，而缺陷分析是通過對(duì)出現(xiàn)的問題進(jìn)行詳盡的根因分析、反向幫助團(tuán)隊(duì)改進(jìn)的一種實(shí)踐。失敗是成功之母，缺陷分析的重要性和價(jià)值不難理解。

缺陷分析不是某個(gè)角色獨(dú)有的職責(zé)，需要團(tuán)隊(duì)的共同參與，可以讓團(tuán)隊(duì)不同角色對(duì)產(chǎn)品質(zhì)量狀態(tài)有更清晰的認(rèn)識(shí)，這是一種有效的質(zhì)量保障賦能實(shí)踐。

關(guān)于缺陷分析的詳情，可以參考我之前的文章《缺陷分析如何幫助質(zhì)量?jī)?nèi)建》。

04 團(tuán)隊(duì)質(zhì)量保障賦能的必要條件

了解了團(tuán)隊(duì)質(zhì)量保障賦能的各種實(shí)踐，還有必要強(qiáng)調(diào)以下幾個(gè)非常關(guān)鍵的必要條件。

質(zhì)量目標(biāo)驅(qū)動(dòng)

要做好質(zhì)量保障賦能，不僅需要質(zhì)量目標(biāo)驅(qū)動(dòng)，很關(guān)鍵的一點(diǎn)是質(zhì)量目標(biāo)需要讓團(tuán)隊(duì)每個(gè)人都清楚，并且需要定期回顧，持續(xù)調(diào)整。

每個(gè)階段團(tuán)隊(duì)所有成員都需要清楚：

• 質(zhì)量要求（質(zhì)量目標(biāo)）是什么？

• 當(dāng)前狀態(tài)怎么樣？

• 需要做哪些調(diào)整以更好的實(shí)現(xiàn)目標(biāo)？

測(cè)試策略指導(dǎo)

測(cè)試策略是質(zhì)量保障的指南，為了讓測(cè)試策略真正發(fā)揮價(jià)值，并且團(tuán)隊(duì)每個(gè)成員都能對(duì)測(cè)試策略有清晰的了解，我們推薦《一頁紙測(cè)試策略》。

一頁紙策略圖只是策略的總覽，背后需要大量的溝通和協(xié)作，更加有利于團(tuán)隊(duì)質(zhì)量保障賦能，增強(qiáng)團(tuán)隊(duì)成員的質(zhì)量意識(shí)。

QA職責(zé)的轉(zhuǎn)變

QA只有從認(rèn)知上做好轉(zhuǎn)變，不再是簡(jiǎn)單測(cè)試人員的思維，才能更好的承擔(dān)起這個(gè)艱巨的賦能任務(wù)。

05 團(tuán)隊(duì)質(zhì)量保障賦能的價(jià)值觀

從敏捷宣言和宣言所遵循的原則，可以總結(jié)出敏捷軟件開發(fā)跟質(zhì)量保障緊密相關(guān)的三點(diǎn)價(jià)值觀：

• 交付價(jià)值：敏捷特別強(qiáng)調(diào)價(jià)值的持續(xù)和盡早交付，因此，團(tuán)隊(duì)所有角色對(duì)價(jià)值的理解、業(yè)務(wù)價(jià)值在團(tuán)隊(duì)的傳遞非常重要。
• 質(zhì)量?jī)?nèi)建：質(zhì)量?jī)?nèi)建通過測(cè)試左移、多個(gè)角色的合作，在缺陷暴露之前做到提前預(yù)防，將質(zhì)量構(gòu)建在軟件系統(tǒng)里。
• 快速反饋：快速反饋就是要做到軟件開發(fā)生命周期的每個(gè)環(huán)節(jié)都能收到反饋，需要加強(qiáng)每個(gè)環(huán)節(jié)的測(cè)試相關(guān)活動(dòng)和大量自動(dòng)化測(cè)試的覆蓋。

前面分享的團(tuán)隊(duì)質(zhì)量保障賦能系列實(shí)踐，都是遵循的敏捷價(jià)值觀，是適合敏捷團(tuán)隊(duì)的質(zhì)量保障賦能。

文/ Thoughtworks 林冰玉
原文鏈接：https://insights.thoughtworks.cn/quality-assurance-enablement-in-agile-team/