在過去的幾個(gè)月，我做了一些實(shí)踐，通過整理、討論和分析項(xiàng)目上的Defects情況，來探索質(zhì)量管理中的待改進(jìn)點(diǎn)。最終發(fā)現(xiàn)，Defects實(shí)際上給質(zhì)量管理帶來了很多的啟示。

當(dāng)然，要討論Defects，首先要使團(tuán)隊(duì)對Defects有一致的理解。我查了很多資料，也沒有找到對”Defects”一詞的明確定義，大部分人將”Defects”等同于“Bug”。

1947年9月9日，Grace Hopper發(fā)現(xiàn)了第一個(gè)電腦上的bug。當(dāng)團(tuán)隊(duì)在Mark II計(jì)算機(jī)上工作時(shí)，搞不清楚為什么電腦不能正常工作了。經(jīng)過深度挖掘，才發(fā)現(xiàn)，原來是一只飛蛾誤打誤撞地飛到了計(jì)算機(jī)內(nèi)部，從而引發(fā)了故障。從此，人們開始用“Bug”(原意是“蟲子”)來稱呼計(jì)算機(jī)中的隱含的錯(cuò)誤。

然而，一個(gè)好的軟件產(chǎn)品，不僅要關(guān)注功能本身，還要關(guān)注其是否好用、是否安全、是否給用戶帶來良好的體驗(yàn)、是否幫助用戶實(shí)現(xiàn)真正的業(yè)務(wù)價(jià)值。因此，從狹義上講，Defects是指軟件程序中存在的某種破壞其正常運(yùn)行的問題或錯(cuò)誤。從廣義上講，Defects還包含那些沒有達(dá)到客戶或用戶期望的質(zhì)量問題。具體來說，Defects可以分為以下幾類：

• 程序錯(cuò)誤: 指程序中存在某種錯(cuò)誤，比如邊界、時(shí)區(qū)等問題，使得系統(tǒng)無法正常工作。
• 性能問題：指由于性能瓶頸所導(dǎo)致的系統(tǒng)缺陷。試想，作為用戶，如果你想要查看一個(gè)報(bào)表，卻需要花10分鐘來等待加載，你是否會(huì)放棄?
• 安全問題：指軟件安全漏洞，造成信息泄露、或使得系統(tǒng)數(shù)據(jù)或功能易受攻擊。
• 兼容性問題：指程序無法在不同的硬件平臺(tái)、操作系統(tǒng)、網(wǎng)絡(luò)環(huán)境等中正常運(yùn)行。
• 功能與用戶需求不否：指軟件功能與用戶期望不匹配。比如，用戶期望造一個(gè)沙發(fā)，卻交付了個(gè)馬扎。
• 交互體驗(yàn)不佳：指用戶使用起來不方便。譬如，電梯控制面板上的“報(bào)警”按鈕和“關(guān)門”按鈕緊挨在一起，你是否經(jīng)常由于”關(guān)門”而誤觸了“報(bào)警”按鈕?再比如，你在網(wǎng)頁中填寫了一個(gè)長長的表單，點(diǎn)擊“提交”按鈕后，系統(tǒng)提示輸入信息有誤，卻并沒有告訴你錯(cuò)誤的哪里，你是會(huì)不耐煩地從頭查閱，還是干脆放棄?

Defects的產(chǎn)生與應(yīng)對策略

產(chǎn)品質(zhì)量是團(tuán)隊(duì)共同的責(zé)任，軟件開發(fā)是一個(gè)過程，任何環(huán)節(jié)都有可能產(chǎn)生質(zhì)量問題，但每個(gè)環(huán)節(jié)的問題都應(yīng)該選擇比較恰當(dāng)?shù)奶幚矸绞健?/p>

在敏捷開發(fā)中，我們以迭代的形式逐步完成產(chǎn)品的開發(fā)，每個(gè)迭代都能以一個(gè)可交付的軟件呈現(xiàn)給用戶，從而盡早地獲得用戶反饋，以保證我們交付的軟件是用戶真正期望的。在每個(gè)迭代中，我們所有的開發(fā)都基于用戶故事卡(Story)，每一張用戶故事卡都將經(jīng)歷Analyse、Design、Code、Test、Deploy的過程。

那么，在敏捷軟件開發(fā)過程中，哪些環(huán)節(jié)都可能產(chǎn)生Defect呢?

正如上圖所示，Defect分別來自于Sprint階段、UAT用戶驗(yàn)收階段以及真正的生產(chǎn)環(huán)境。其中，Sprint階段又細(xì)分為：不合理的需求、不恰當(dāng)?shù)脑O(shè)計(jì)、代碼及邏輯錯(cuò)誤、Story卡測試過程中發(fā)現(xiàn)的問題、回歸測試中發(fā)現(xiàn)的問題、以及非功能性測試發(fā)現(xiàn)的問題。

開發(fā)過程中不同階段的Defects，我們分別采用什么樣的敏捷實(shí)踐來應(yīng)對呢?

上圖以看板的形式展示了Sprint開發(fā)中Story卡片流動(dòng)的過程，以及每個(gè)環(huán)節(jié)的敏捷實(shí)踐，這些實(shí)踐有助我們發(fā)現(xiàn)和改善質(zhì)量問題：

• 不合理的需求：由于QA往往有不同于BA的視角，提早與BA Pair完善Story AC (Acceptance Criteria)。此時(shí)發(fā)現(xiàn)的問題要及時(shí)補(bǔ)充到Story卡上。這樣，不僅能夠盡早地發(fā)現(xiàn)需求上的不合理或遺漏，還有助于QA深入理解需求、設(shè)計(jì)測試用例。
• 不恰當(dāng)?shù)脑O(shè)計(jì)：UX制作出酷炫的設(shè)計(jì)圖，卻并不一定是用戶真正期望的，或者技術(shù)實(shí)現(xiàn)的成本過高。因此，一方面，要在開發(fā)之前與用戶Review設(shè)計(jì)圖，并按照用戶的反饋及時(shí)更新;另一方面，在每一張Story卡開始開發(fā)之前，由BA、UX、QA及Dev一起Kick Off Story，通過討論和澄清，使得團(tuán)隊(duì)成員對需求和設(shè)計(jì)達(dá)成一致。一旦發(fā)現(xiàn)問題，要及時(shí)更新Story卡和設(shè)計(jì)圖。
• 代碼及邏輯錯(cuò)誤：單元測試、Code Review、Desk Check都是用來發(fā)現(xiàn)代碼及邏輯錯(cuò)誤的有效手段。因此，開發(fā)提交代碼后，要先執(zhí)行單元測試、只有當(dāng)單元測試通過之后，才可以將代碼部署到QA測試環(huán)境;然后按照Story的AC逐條與QA和BA進(jìn)行Desk check。除此之外，開發(fā)團(tuán)隊(duì)要每天堅(jiān)持Code Review，以便發(fā)現(xiàn)代碼邏輯及編碼規(guī)范方面的問題。這些過程中發(fā)現(xiàn)的Defects都應(yīng)該盡快修復(fù)。
• Story卡測試中發(fā)現(xiàn)的問題：Story卡測試時(shí)發(fā)現(xiàn)的問題，無論其嚴(yán)重程度如何，基本上都要在當(dāng)前迭代修復(fù)。QA可以與Dev面對面溝通，也可以將Defect添加到Story的Comment里面，再將Story重新拖回In Dev狀態(tài)，或者在物理看板上添加一張物理卡片。但無論哪種形式，都需要在早會(huì)時(shí)提及，以便有效地跟蹤Defect進(jìn)度。
• 回歸測試中發(fā)現(xiàn)的問題：普遍來講，回歸測試發(fā)現(xiàn)的問題，優(yōu)先級要低于Story的開發(fā)。因此，QA需要在電子看板或者Defects管理系統(tǒng)中提交一條Defect記錄，然后與BA溝通，在最合適的時(shí)間Assign給Dev。但如果該Defect造成系統(tǒng)崩潰或者Block了某些功能的使用，就應(yīng)該立即修復(fù)它。
• 非功性測試發(fā)現(xiàn)的問題：非功能性測試一般是在每個(gè)Release上線之前做，發(fā)現(xiàn)的問題也要在Release之前修復(fù)。同樣需要在電子看板或者Defects管理系統(tǒng)中提交Defect記錄，但要注意其優(yōu)先級。
• UAT用戶驗(yàn)收階段的反饋：在UAT階段，開發(fā)團(tuán)隊(duì)向用戶Showcase，或者由用戶來做用戶驗(yàn)收測試。此時(shí)，用戶會(huì)提出一些反饋。由QA和BA對這些反饋進(jìn)行分析，如果是功能層面的問題，在看板上建成卡片，并在上線前修復(fù)。如果是需求層面的問題，就將其添加到需求列表中，以便安排在之后的迭代計(jì)劃中。
• 生產(chǎn)上的問題：生產(chǎn)上的問題優(yōu)先級是最高的。但是與用戶反饋一樣，功能層面的問題要立即修復(fù)，用戶體驗(yàn)上的問題要添加在需求列表中。

Defects對質(zhì)量管理的啟示

Defects并不是獨(dú)立存在的，它或多或少反映出了項(xiàng)目管理和開發(fā)過程中存在的問題，這些問題都可能對質(zhì)量產(chǎn)生影響。比如：線上問題的走勢，是否能夠反映出產(chǎn)品質(zhì)量的變化;分析每個(gè)迭代Defects的數(shù)據(jù)及產(chǎn)生的原因，有助于發(fā)現(xiàn)開發(fā)過程中出現(xiàn)的問題，及時(shí)地進(jìn)行風(fēng)險(xiǎn)把控。

我以自己所在項(xiàng)目為例，說一說Defects給質(zhì)量管理和團(tuán)隊(duì)管理帶來的啟示。

1. 通過線上問題走勢，分析產(chǎn)品質(zhì)量的變化

2017年8月，我們接到A遺留系統(tǒng)，到10月份累計(jì)在生產(chǎn)環(huán)境發(fā)現(xiàn)歷史遺留問題21個(gè)。按照優(yōu)先級，每個(gè)月修復(fù)一定的數(shù)量。截止2018年7月，發(fā)現(xiàn)的歷史遺留問題高達(dá)46個(gè)，只剩余2個(gè)還未修復(fù)。Defects數(shù)量在減少，產(chǎn)品質(zhì)量在逐步提升。

除此之外，我們對歷史遺留問題和新引入問題做了對比，這10個(gè)月的線上問題中，歷史遺留問題占85%，新引入問題占15%，可見仍有部分沒能在開發(fā)過程中發(fā)現(xiàn)，使其流到線上。要對這些問題具體分析：其嚴(yán)重程度如何、產(chǎn)生的原因是什么、為什么在開發(fā)過程中沒有發(fā)現(xiàn)、后續(xù)有怎樣的改進(jìn)措施。

當(dāng)然，最好能對生產(chǎn)上的“運(yùn)維類問題”和“功能類問題”加以區(qū)分，以便采取更恰當(dāng)?shù)母倪M(jìn)措施。

2. 分析迭代Defects情況，討論改進(jìn)措施

除了分析線上問題，我還對從2017年10月-2018年7月QA提交的Defects情況做了一個(gè)統(tǒng)計(jì)，觀察每個(gè)月提交的Defects和修復(fù)的Defects情況。

從統(tǒng)計(jì)結(jié)果來看，2018年7月發(fā)現(xiàn)和修復(fù)的Defects數(shù)量均呈明顯的上升趨勢，達(dá)到歷史最高點(diǎn)。因此，有必要對7月份的Defects情況做一個(gè)詳細(xì)的分析，看看究竟是什么原因?qū)е铝诉@些Defects。

我對這些Defects做了一個(gè)初步的分類，并利用Retrospective Meeting的機(jī)會(huì)，與團(tuán)隊(duì)成員一起分析討論。發(fā)現(xiàn)產(chǎn)生問題的原因有以下幾個(gè)方面：

• 本次Release的Story Kick Off和Desk Check做的不夠好。有時(shí)候開發(fā)沒有Kick Off就直接按照自己的理解開始編碼，導(dǎo)致團(tuán)隊(duì)成員沒有對需求達(dá)成一致的理解，做出來的功能出現(xiàn)偏差。有時(shí)候Dev將一堆卡壘在一起做Desk Check，這樣很難逐條覆蓋AC，從而將問題流入QA測試階段。
• 本次的需求比較偏技術(shù)，BA只能從業(yè)務(wù)的角度去編寫Story卡。開發(fā)同學(xué)為了追趕工期，沒能夠添加充分的Tech Task, 也沒能夠堅(jiān)持Code Review，導(dǎo)致出現(xiàn)一些邏輯錯(cuò)誤。
• 單元測試覆蓋率比較低。作為一個(gè)遺留的微服務(wù)系統(tǒng)，某些服務(wù)在之前從未重構(gòu)過，代碼邏輯比較混亂，添加單元測試的難度大、成本高。因此一些本該單元測試階段就能發(fā)現(xiàn)的問題一直流到QA測試階段。
• 本次Release一共一個(gè)月時(shí)間，UI一直到最后一個(gè)禮拜才確定下來，期間反反復(fù)復(fù)的修改不僅花費(fèi)了太多成本，還消磨了Dev的意志，導(dǎo)致出現(xiàn)一些本不該出現(xiàn)的Defects。
• 新人加入，項(xiàng)目工期緊，對上下文信息同步不夠，導(dǎo)致新開發(fā)的內(nèi)容破壞了一些已經(jīng)驗(yàn)證過的功能。

這些原因充分說明了這段時(shí)間項(xiàng)目中存在的問題，我們對此逐條提出了具體的改進(jìn)措施：

• 堅(jiān)決執(zhí)行Story Kick Off和Desk Check敏捷實(shí)踐，在每日站會(huì)時(shí)嚴(yán)格跟蹤每一張Story卡的進(jìn)度。
• 預(yù)定一個(gè)定期會(huì)議，每天下午17:00 - 18:00進(jìn)行Code Review，并每周一人輪班擔(dān)任Owner。
• 將單元測試覆蓋率可視化。同時(shí)，制定項(xiàng)目標(biāo)準(zhǔn)：對于新開發(fā)的內(nèi)容，必須編寫并通過單元測試才能Desk Check;對于歷史遺留模塊，在技術(shù)債墻上添加技術(shù)債卡片，并于每周消化一個(gè)技術(shù)債務(wù)。
• 項(xiàng)目開發(fā)前期要加強(qiáng)與客戶和用戶的溝通，在Story開始開發(fā)之前，確定好UI設(shè)計(jì)，開發(fā)過程中盡量避免大的改動(dòng)。
• 新人加入項(xiàng)目時(shí)，采用結(jié)對編程的方式完成開發(fā)。除此之外，每周在項(xiàng)目內(nèi)進(jìn)行一次技術(shù)分享Session。

當(dāng)然，以上兩點(diǎn)只是我基于A項(xiàng)目舉的一個(gè)例子。實(shí)際上，Defects還給了我們很多啟示，比如，為什么項(xiàng)目老是加班?為什么有些模塊的Defects數(shù)量比較多?如何根據(jù)團(tuán)隊(duì)成員花在Defects上的efforts，制定提升計(jì)劃?然而，每個(gè)項(xiàng)目的情況不一樣，我們應(yīng)該基于自己的項(xiàng)目背景，由團(tuán)隊(duì)成員一起分析深層次的原因，共同制定切實(shí)可行的改進(jìn)措施，從而不斷地提高產(chǎn)品質(zhì)量。

【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號(hào)：思特沃克，轉(zhuǎn)載請聯(lián)系原作者】

戳這里，看該作者更多好文