本文首發(fā)于【林子的空間】

“沒有專職的測試人員坝茎？

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

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

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

關(guān)于質(zhì)量的神話

01 兩個(gè)案例

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

案例1

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

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

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

案例2

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

原來，該網(wǎng)站是基于一個(gè)第三方平臺開發(fā)黔州，由于業(yè)務(wù)的特殊性需要支持2TB的數(shù)據(jù)量阔籽。但是，該第三方平臺并沒有驗(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é)助第三方平臺進(jìn)行升級……團(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ā)和測試了解到的都是頁面流轉(zhuǎn)方式和具體的操作素跺，難以識別業(yè)務(wù)高風(fēng)險(xiǎn)問題；
• 缺乏系統(tǒng)的設(shè)計(jì)刊愚，代碼沒有分層踩验，不能體現(xiàn)業(yè)務(wù)商玫，也很難編寫有效的自動(dòng)化測試來保障質(zhì)量牡借。

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

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

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

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

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

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

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

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

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

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

大公司都是怎么做的？

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

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

Google愤钾、Amazon瘟滨、Facebook的質(zhì)量保障賦能實(shí)踐

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)測試、部署發(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的代碼評審工具瞬场、用于單元測試的Mocking框架涧郊、缺陷跟蹤工具Buganizer、發(fā)布驗(yàn)收審核工具等彤灶。
• Amazon也有很多稱為構(gòu)建者工具（Builder's tool）供整個(gè)軟件開發(fā)和交付流程使用。所有團(tuán)隊(duì)采用同樣的系統(tǒng)和工具幌陕，對于流程的標(biāo)準(zhǔn)化是很重要的一部分。

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

• Amazon提供模板告訴人們正確的做法，并且采用政策來阻止新人犯錯(cuò)现恼，同時(shí)鼓勵(lì)人們創(chuàng)建更多的政策來優(yōu)化以找到最優(yōu)的實(shí)踐方案，一旦有錯(cuò)誤出現(xiàn)就會添加新的相關(guān)政策來優(yōu)化始锚，比如：單元測試覆蓋率不能低于70%喳逛、每次部署不允許同時(shí)部署到所有區(qū)域（Region）等。
• Google和Facebook也都有類似的一些規(guī)則姐呐，比如代碼必須有一名代碼所有者、并且是除作者以外的一人評審?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í)踐主要是針對標(biāo)準(zhǔn)流程以外的一些特定領(lǐng)域或者特定場景下的實(shí)踐眶熬，像針對安全領(lǐng)域的威脅建模、針對微服務(wù)架構(gòu)帶來的不確定性的混沌工程等拳缠。

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

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

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

說到標(biāo)準(zhǔn)化盔憨，可能有人會說：“我們也在做標(biāo)準(zhǔn)化，也有指標(biāo)和規(guī)則要求郁岩，比如有持續(xù)集成流水線，要求做代碼評審脸秽，要求單元測試覆蓋率不能低于多少蝴乔，要求用戶故事的開發(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ì)有自己的配置雕沿，采用什么工具猴仑、跑哪些測試沒有統(tǒng)一的模式，測試掛了第一個(gè)動(dòng)作是重跑或者先將遲遲難以修復(fù)的測試忽略掉；
• 代碼評審可能就是每天要來一次的一種儀式篡诽，至于效率和質(zhì)量榴捡，也沒什么衡量；
• 單元測試為了滿足指標(biāo)要求吊圾，專挑容易的寫測試，并不區(qū)分業(yè)務(wù)優(yōu)先級砰碴；
• 用戶故事開發(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)化測試付秕。其實(shí)，這里說的大規(guī)模自動(dòng)化掠河，不僅有大規(guī)模的測試自動(dòng)化猛计，還包括大規(guī)模的流程自動(dòng)化。

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

測試自動(dòng)化

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

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

流程自動(dòng)化

測試自動(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)境蛤奢，不僅有測試的保證，也不需要人為的干預(yù)啤贩。構(gòu)建了很多的檢查器（Checker）來檢查整個(gè)流水線上強(qiáng)制政策執(zhí)行情況拜秧，比如：單元測試覆蓋率低于70%不讓提交、AWS同時(shí)部署多個(gè)區(qū)域會自動(dòng)中止并自動(dòng)回滾等志衍。
• Google同樣有工具自動(dòng)度量單元測試覆蓋率，并且可以通過工具自動(dòng)地推薦合適的代碼評審人員等足画。

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

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

• Google和Facebook的代碼所有權(quán)制度，任何人改代碼都得有所有者的許可叁幢，這對代碼質(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)了工程師的使命感，從而對質(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)慎的，注意評估坪仇、持續(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ì)量保障賦能非常地難。

做不到別人家的公司那樣空免，我們在除了盡力做到標(biāo)準(zhǔn)化和自動(dòng)化之外盆耽，還能做些什么？下面分享我和同事在ThoughtWorks經(jīng)歷的一些實(shí)踐摄杂。

測試全流程介入

“全程的測試介入”是被我們寫進(jìn)敏捷測試宣言的一條價(jià)值觀，測試左移墨坚、持續(xù)測試和測試右移都是價(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ā)布流程更加順暢辱姨；
• 線上事故診斷信息收集清單：對于線上事故的診斷，需要第一時(shí)間收集哪些相關(guān)信息雨涛，以幫助更快速的定位問題；
• ……

結(jié)對或評審（Pair/Review）

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

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

除了結(jié)對陡蝇，QA還可以通過評審的方式傳遞質(zhì)量意識，比如用戶故事登夫、單元測試、日志記錄情況的評審等鸦致。

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

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

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

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

測試全流程介入

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

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

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

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

缺陷分析

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

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

關(guān)于缺陷分析的詳情，可以參考我之前的文章《缺陷分析如何幫助質(zhì)量內(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)器赞？

測試策略指導(dǎo)

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

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

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

QA的三個(gè)級別

前面說到了敏捷團(tuán)隊(duì)的QA需要承擔(dān)起賦能者的職責(zé)奢啥，這需要QA上升到第三層，我的文章《再談敏捷QA》有關(guān)于這三層的介紹桩盲。

QA只有從認(rèn)知上做好轉(zhuǎn)變，不再是簡單測試人員的思維捞蛋，才能更好的承擔(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ì)所有角色對價(jià)值的理解撕捍、業(yè)務(wù)價(jià)值在團(tuán)隊(duì)的傳遞非常重要。
• 質(zhì)量內(nèi)建：質(zhì)量內(nèi)建通過測試左移贞言、多個(gè)角色的合作，在缺陷暴露之前做到提前預(yù)防该窗，將質(zhì)量構(gòu)建在軟件系統(tǒng)里蚤霞。
• 快速反饋：快速反饋就是要做到軟件開發(fā)生命周期的每個(gè)環(huán)節(jié)都能收到反饋，需要加強(qiáng)每個(gè)環(huán)節(jié)的測試相關(guān)活動(dòng)和大量自動(dòng)化測試的覆蓋昧绣。

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