說(shuō)好的團(tuán)隊(duì)為質(zhì)量負(fù)責(zé)呢？

以下文章來(lái)源于BY林子 ，作者林冰玉

問(wèn)：誰(shuí)應(yīng)該為質(zhì)量負(fù)責(zé)？
答：QA是負(fù)責(zé)測(cè)試把關(guān)，主要負(fù)責(zé)吧，DEV也要在設(shè)計(jì)和代碼上對(duì)質(zhì)量負(fù)責(zé)。
問(wèn)：那其他角色呢？
答：BA還好吧，跟質(zhì)量的關(guān)系沒(méi)那么大。
……
在藍(lán)鯨項(xiàng)目，似乎大家對(duì)質(zhì)量的關(guān)注意識(shí)有些欠缺，于是在項(xiàng)目上的不同角色、不同工作年限的人之間采樣做了一次訪談，上面這個(gè)問(wèn)題就是其中訪談的問(wèn)題之一。有同事曾提醒我說(shuō)這種題就是送分題，肯定不會(huì)有人回答不出?？墒牵聦?shí)并非如此…
為什么會(huì)這樣呢？我猜想可能是大家對(duì)質(zhì)量的理解不一致的緣故，在沒(méi)有搞清楚什么是質(zhì)量的前提下，當(dāng)然也沒(méi)有可能理解到底誰(shuí)該為質(zhì)量負(fù)責(zé)。
因此，我們來(lái)看看質(zhì)量到底是什么？
質(zhì)量是什么
產(chǎn)品質(zhì)量不是檢測(cè)出來(lái)的，從產(chǎn)品生產(chǎn)出來(lái)后質(zhì)量就已經(jīng)在那了。
——著名的質(zhì)量管理專家戴明
在講什么是質(zhì)量之前，我們有必要區(qū)分兩個(gè)不同的概念：測(cè)試只能檢測(cè)、發(fā)現(xiàn)缺陷，而質(zhì)量要通過(guò)缺陷預(yù)防來(lái)實(shí)現(xiàn)。 測(cè)試與質(zhì)量不可同日而語(yǔ)，以后再也不要說(shuō)“上線這么多問(wèn)題，測(cè)試是怎么測(cè)的”這種話了。



那么，質(zhì)量到底是什么？對(duì)于不同的角色、不同的利益相關(guān)者，質(zhì)量有著不同的含義。總的來(lái)說(shuō)，可以分為外部質(zhì)量和內(nèi)部質(zhì)量?jī)煞N。
1. 外部質(zhì)量
顧名思義，外部質(zhì)量就是軟件呈現(xiàn)給用戶的外部形態(tài)，是否有缺陷、是否穩(wěn)定、是否有性能問(wèn)題等。也就是最終用戶在軟件使用過(guò)程中的各種體驗(yàn)，包括軟件可學(xué)習(xí)、高效、不易出錯(cuò)、有用、難忘等特性，都屬于外部質(zhì)量范疇。外部質(zhì)量也可以稱為使用質(zhì)量，主要是從使用軟件的用戶角度來(lái)看的。
外部質(zhì)量能夠被用戶直接感知到，直接影響用戶的使用，因而顯得特別重要，客戶/用戶一般也比較容易為外部質(zhì)量買單。
2. 內(nèi)部質(zhì)量
同樣的，內(nèi)部質(zhì)量就是指軟件系統(tǒng)內(nèi)部的質(zhì)量狀態(tài)，包括代碼的效率、結(jié)構(gòu)、可讀性、可擴(kuò)展性、可靠性和可維護(hù)性等。內(nèi)部質(zhì)量主要從開(kāi)發(fā)人員角度來(lái)看，也稱為代碼質(zhì)量。
內(nèi)部質(zhì)量不會(huì)被最終用戶感知到，不容易被客戶/用戶買單，也常容易被團(tuán)隊(duì)忽略。但是，內(nèi)部質(zhì)量會(huì)影響外部質(zhì)量，需要團(tuán)隊(duì)引起重視，加強(qiáng)設(shè)計(jì)、開(kāi)發(fā)等環(huán)節(jié)的質(zhì)量把控。
3. 內(nèi)建質(zhì)量
質(zhì)量不能被檢測(cè)出來(lái)，要提高軟件產(chǎn)品的內(nèi)、外部質(zhì)量，都需要通過(guò)質(zhì)量?jī)?nèi)建（或質(zhì)量?jī)?nèi)嵌）的方式，做好每個(gè)環(huán)節(jié)的質(zhì)量保障工作。質(zhì)量?jī)?nèi)建包含自動(dòng)化測(cè)試和手動(dòng)測(cè)試：
自動(dòng)化測(cè)試：從多個(gè)層次（單元、組件、端到端等）寫自動(dòng)化測(cè)試，并將其作為部署流水線的一部分來(lái)執(zhí)行，每次提交應(yīng)用程序代碼、配置或環(huán)境以及運(yùn)行時(shí)所需要軟件發(fā)生變化時(shí)，都要執(zhí)行這些測(cè)試。同時(shí)，隨著項(xiàng)目業(yè)務(wù)和技術(shù)架構(gòu)的演進(jìn)，自動(dòng)化測(cè)試策略也需要隨之調(diào)整、不斷改進(jìn)。

手動(dòng)測(cè)試：手動(dòng)測(cè)試也是很關(guān)鍵的部分，如需求驗(yàn)證、演示、可用性測(cè)試和探索式測(cè)試等，在整個(gè)項(xiàng)目過(guò)程中都應(yīng)該持之以恒的做下去。


另外，質(zhì)量?jī)?nèi)建不僅要考慮功能測(cè)試，對(duì)于跨功能測(cè)試同樣是需要做到內(nèi)建的，比如安全內(nèi)建、持續(xù)性能測(cè)試等。
軟件構(gòu)建過(guò)程中多大程度上做到了質(zhì)量?jī)?nèi)建，有多少缺陷做到了提前預(yù)防，這是“內(nèi)建質(zhì)量”。內(nèi)建質(zhì)量雖然跟內(nèi)、外部質(zhì)量不在一個(gè)維度，但也是體現(xiàn)質(zhì)量好壞的一個(gè)方面，在此也把它作為衡量質(zhì)量的一個(gè)維度，測(cè)試或使用過(guò)程中發(fā)現(xiàn)的缺陷數(shù)量可以作為度量指標(biāo)。
因此，我們可以從這三個(gè)維度來(lái)度量軟件產(chǎn)品的質(zhì)量，可以通過(guò)以下方式來(lái)度量：
外部質(zhì)量：用戶反饋、Support的問(wèn)題數(shù)量
內(nèi)部質(zhì)量：code review、結(jié)對(duì)編程、靜態(tài)代碼質(zhì)量檢查
內(nèi)建質(zhì)量：測(cè)試環(huán)境、生產(chǎn)環(huán)境缺陷，Support的反饋
了解了三個(gè)維度質(zhì)量的含義，我們不難理解：
?質(zhì)量不是零缺陷，不是百分百的測(cè)試覆蓋率，也不是沒(méi)有技術(shù)債；
?質(zhì)量是快速反饋，任何改變能夠快速驗(yàn)證，并且快速修復(fù)；
?質(zhì)量是把精力都集中在正確的事情上；
?質(zhì)量是團(tuán)隊(duì)在代碼、設(shè)計(jì)和交付上有信心做出改變；
?質(zhì)量是團(tuán)隊(duì)對(duì)任何改變負(fù)責(zé)。








容易忽視的質(zhì)量
從前面對(duì)質(zhì)量的定義，廣義的質(zhì)量其實(shí)包括軟件產(chǎn)品交付流程中的方方面面，每個(gè)環(huán)節(jié)的一點(diǎn)疏忽都可能對(duì)軟件質(zhì)量造成不同程度的影響。下面列舉一些從項(xiàng)目上經(jīng)歷的對(duì)質(zhì)量關(guān)注有所欠缺的內(nèi)容：
需求分析過(guò)程倉(cāng)促，或者參與人員角色比較單一，導(dǎo)致業(yè)務(wù)上下文了解不夠，關(guān)鍵場(chǎng)景缺乏考慮等；

忙于交付更多的feature，忽略了對(duì)代碼質(zhì)量的關(guān)注，該重構(gòu)的沒(méi)有重構(gòu)，在原本不太健康的代碼基礎(chǔ)上繼續(xù)增加更多的代碼，導(dǎo)致混亂，筑起高高的技術(shù)債；

沒(méi)有足夠的測(cè)試覆蓋，導(dǎo)致新增代碼容易破壞已有功能；

Dev提交代碼后，就投入新代碼的開(kāi)發(fā)，對(duì)所提交代碼缺乏關(guān)注，CI pipeline紅了不能及時(shí)修復(fù)，可能影響后面QA的測(cè)試進(jìn)度；

大面積的重構(gòu)發(fā)生在release前夕，無(wú)法全面回歸，帶來(lái)很大的風(fēng)險(xiǎn)；

項(xiàng)目初期只考慮少量用戶的場(chǎng)景，隨著業(yè)務(wù)的發(fā)展，系統(tǒng)功能難以擴(kuò)展，導(dǎo)致嚴(yán)重性能瓶頸；

技術(shù)選型失誤，開(kāi)發(fā)困難，沒(méi)有及時(shí)改進(jìn)，一錯(cuò)再錯(cuò)，最后問(wèn)題嚴(yán)重到無(wú)法彌補(bǔ)；

第三方組件評(píng)估不夠充分，導(dǎo)致線上環(huán)境無(wú)法承載等；

開(kāi)發(fā)缺少對(duì)異常情況的處理，測(cè)試過(guò)程缺乏探索，只覆蓋到主干路徑，邊角case可能引發(fā)問(wèn)題；

開(kāi)發(fā)或者測(cè)試都只考慮當(dāng)前功能模塊，缺乏更廣范圍的考慮；

缺乏跨功能需求的關(guān)注，導(dǎo)致嚴(yán)重的安全或者性能問(wèn)題；

對(duì)線上環(huán)境了解不夠，而且沒(méi)有足夠日志信息記錄，線上問(wèn)題難以定位，導(dǎo)致宕機(jī)時(shí)間過(guò)長(zhǎng)；

……

這樣的問(wèn)題還有很多很多，無(wú)法一一枚舉。每個(gè)角色，每個(gè)環(huán)節(jié)都有可能出現(xiàn)紕漏，導(dǎo)致產(chǎn)品質(zhì)量問(wèn)題。
那么，誰(shuí)該為質(zhì)量負(fù)責(zé)是不是已經(jīng)很清楚了？
誰(shuí)該為質(zhì)量負(fù)責(zé)
前面已經(jīng)講到，質(zhì)量是貫穿項(xiàng)目整個(gè)生命周期的非常關(guān)鍵的部分，質(zhì)量保障工作也是需要在每個(gè)環(huán)節(jié)加強(qiáng)關(guān)注，每個(gè)角色都需要為質(zhì)量負(fù)責(zé)。



上表列出的是敏捷開(kāi)發(fā)流程中的各個(gè)實(shí)踐活動(dòng)，它們都與質(zhì)量有關(guān)，每個(gè)活動(dòng)都要求多個(gè)不同的角色同時(shí)參與。

下面從敏捷團(tuán)隊(duì)三個(gè)主力角色BA、QA和Dev的不同視角來(lái)看看各自怎么為質(zhì)量負(fù)責(zé)。

BA：Busines Analyst，業(yè)務(wù)分析師
BA主要負(fù)責(zé)業(yè)務(wù)需求的分析工作，要理解客戶的業(yè)務(wù)，并將業(yè)務(wù)分解成便于Dev和QA理解的功能點(diǎn)，同時(shí)，還要能夠幫助用戶驗(yàn)證開(kāi)發(fā)完成的軟件系統(tǒng)功能，并展示給客戶。需求作為軟件開(kāi)發(fā)的源頭，是極為關(guān)鍵的。
BA視角的質(zhì)量，主要是需求分析的準(zhǔn)確性和清晰度，要幫助團(tuán)隊(duì)對(duì)需求有一致的認(rèn)識(shí)，從用戶旅程的角度關(guān)注交付給最終用戶的產(chǎn)品是否真的帶來(lái)了價(jià)值。
Dev：Developer，開(kāi)發(fā)人員
Dev作為軟件系統(tǒng)實(shí)現(xiàn)的主力，對(duì)質(zhì)量?jī)?nèi)建是至關(guān)重要的。從需求的理解、整潔的代碼實(shí)現(xiàn)、測(cè)試覆蓋率的保證、頻繁的代碼提交、持續(xù)的集成、對(duì)生產(chǎn)環(huán)境的關(guān)注、運(yùn)維的支持等方面，都有著不可替代的職責(zé)，每個(gè)環(huán)節(jié)都不可忽略。
因此，Dev視角的質(zhì)量不僅是按照需求實(shí)現(xiàn)功能的開(kāi)發(fā)，還要把功能高效的交付給最終用戶。
QA：Quality Analyst，質(zhì)量分析師
QA作為軟件質(zhì)量的倡導(dǎo)者，是唯一一個(gè)全流程都要參與的角色，從需求到上線后的支持，每個(gè)環(huán)節(jié)都不可缺。清晰理解需求、制定質(zhì)量保障策略、做好各個(gè)環(huán)節(jié)的測(cè)試工作（手動(dòng)、自動(dòng)化、探索式、跨功能、非功能測(cè)試，以及生產(chǎn)環(huán)境的QA等）、關(guān)注項(xiàng)目整體質(zhì)量狀態(tài)、及時(shí)反饋質(zhì)量信息給團(tuán)隊(duì)、識(shí)別業(yè)務(wù)風(fēng)險(xiǎn)和優(yōu)先級(jí)、幫助優(yōu)化業(yè)務(wù)價(jià)值，這些都是QA的職責(zé)。
三個(gè)主力角色中的BA一般都會(huì)有從用戶旅程的角度去考慮，其實(shí)Dev和QA也需要同樣的思維模式，不能把story或者AC割裂來(lái)看，而是要從整體的用戶旅程的角度、端到端的去考慮需求的實(shí)現(xiàn)和測(cè)試工作。
除了三個(gè)主力角色，團(tuán)隊(duì)還有其他角色也都是要對(duì)質(zhì)量負(fù)責(zé)的，比如：架構(gòu)師要負(fù)責(zé)項(xiàng)目架構(gòu)的健康，基礎(chǔ)設(shè)施負(fù)責(zé)人要管理和維護(hù)好基礎(chǔ)設(shè)施以保障開(kāi)發(fā)和運(yùn)維工作的順利開(kāi)展，PM要管理好團(tuán)隊(duì)的交付節(jié)奏、團(tuán)隊(duì)成員的工作狀態(tài)、客戶的滿意度等，這些都是跟質(zhì)量相關(guān)的。



寫在最后
質(zhì)量不僅是某個(gè)角色的事情，團(tuán)隊(duì)每個(gè)成員都撇不開(kāi)質(zhì)量這個(gè)話題。團(tuán)隊(duì)為質(zhì)量負(fù)責(zé)要求所有質(zhì)量角色都將質(zhì)量推向看板的左側(cè)，從每個(gè)用戶故事的開(kāi)始就將質(zhì)量融入其中。
軟件開(kāi)發(fā)生命周期的每個(gè)環(huán)節(jié)、每個(gè)實(shí)踐活動(dòng)都不可輕視，只有在每個(gè)點(diǎn)上都做好質(zhì)量的工作，才能實(shí)現(xiàn)真正的高質(zhì)量交付，每個(gè)角色對(duì)此都有著非常重要的職責(zé)。

作者：林冰玉


歡迎關(guān)注微信公眾號(hào) ：Python測(cè)試社區(qū)