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

“沒有專職的測試人員？

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

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

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

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

01 兩個案例

相信很多人都對前面這些問題很好奇，在解開謎團之前，我們先來看兩個案例。

案例1

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

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

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

案例2

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

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

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

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

案例分析

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

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

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

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

• 分析、開發(fā)、測試都沒有考慮真實業(yè)務(wù)需求，缺乏性能風(fēng)險意識，只關(guān)注了功能需求；
• 第三方系統(tǒng)沒有驗證，對第三方系統(tǒng)并沒有有效的風(fēng)險評估；
• 測試環(huán)境準(zhǔn)備不夠及時，上線前一個多月才準(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ì)量之痛，相信大家都是深有體會。

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

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

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

03 團隊的質(zhì)量保障賦能

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

大公司都是怎么做的？

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

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

Google、Amazon、Facebook的質(zhì)量保障賦能實踐

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

大規(guī)模自動化

測試自動化

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

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

流程自動化

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

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

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

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

• Google和Facebook的代碼所有權(quán)制度，任何人改代碼都得有所有者的許可，這對代碼質(zhì)量的保障是很有效的。
• Facebook的開發(fā)人員需要負責(zé)支持所開發(fā)產(chǎn)品的運維工作，使得他們更加重視質(zhì)量。
• Amazon是每個小團隊負責(zé)一個服務(wù)，不僅需要負責(zé)開發(fā)和運維，還需要自行制定需求計劃。采用由下往上發(fā)起計劃的方式，由一線員工去計劃接下來的開發(fā)內(nèi)容，因為他們最接近客戶、最清楚客戶所遇到的問題和真正的需求。這樣的方式讓增強了工程師的使命感，從而對質(zhì)量更加重視、更有意愿去把質(zhì)量搞好。

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

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

三者有機結(jié)合

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

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

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

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

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

做不到呀

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

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

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

測試全流程介入

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

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

模板或清單（Template/Checklist）

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

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

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

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

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

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

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

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

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

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

測試全流程介入

業(yè)務(wù)價值驅(qū)動測試

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

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

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

缺陷分析

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

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

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

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

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

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

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

每個階段團隊所有成員都需要清楚：

• 質(zhì)量要求（質(zhì)量目標(biāo)）是什么？
• 當(dāng)前狀態(tài)怎么樣？
• 需要做哪些調(diào)整以更好的實現(xiàn)目標(biāo)？

測試策略指導(dǎo)

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

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

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

QA的三個級別

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

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

05 團隊質(zhì)量保障賦能的價值觀

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

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

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