在過去的幾個月挑围，我做了一些實踐礁竞，通過整理、討論和分析項目上的Defects情況杉辙，來探索質量管理中的待改進點模捂。最終發(fā)現(xiàn)，Defects實際上給質量管理帶來了很多的啟示。

當然枫绅，要討論Defects泉孩，首先要使團隊對Defects有一致的理解硼端。我查了很多資料并淋，也沒有找到對”Defects”一詞的明確定義，大部分人將”Defects”等同于“Bug”珍昨。

1947年9月9日县耽，Grace Hopper發(fā)現(xiàn)了第一個電腦上的bug。當團隊在Mark II計算機上工作時镣典，搞不清楚為什么電腦不能正常工作了兔毙。經過深度挖掘，才發(fā)現(xiàn)兄春，原來是一只飛蛾誤打誤撞地飛到了計算機內部澎剥，從而引發(fā)了故障。從此赶舆，人們開始用“Bug”（原意是“蟲子”）來稱呼計算機中的隱含的錯誤哑姚。

然而，一個好的軟件產品芜茵，不僅要關注功能本身叙量，還要關注其是否好用、是否安全九串、是否給用戶帶來良好的體驗绞佩、是否幫助用戶實現(xiàn)真正的業(yè)務價值。因此猪钮，從狹義上講品山，Defects是指軟件程序中存在的某種破壞其正常運行的問題或錯誤。從廣義上講烤低，Defects還包含那些沒有達到客戶或用戶期望的質量問題谆奥。具體來說，Defects可以分為以下幾類：

• 程序錯誤: 指程序中存在某種錯誤拂玻，比如邊界酸些、時區(qū)等問題檐蚜，使得系統(tǒng)無法正常工作。
• 性能問題：指由于性能瓶頸所導致的系統(tǒng)缺陷闯第。試想，作為用戶，如果你想要查看一個報表填帽，卻需要花10分鐘來等待加載，你是否會放棄篡腌？
• 安全問題：指軟件安全漏洞，造成信息泄露嘹悼、或使得系統(tǒng)數(shù)據或功能易受攻擊叛甫。
• 兼容性問題：指程序無法在不同的硬件平臺、操作系統(tǒng)杨伙、網絡環(huán)境等中正常運行其监。
• 功能與用戶需求不否：指軟件功能與用戶期望不匹配。比如限匣，用戶期望造一個沙發(fā)抖苦，卻交付了個馬扎。
• 交互體驗不佳：指用戶使用起來不方便米死。譬如锌历，電梯控制面板上的“報警”按鈕和“關門”按鈕緊挨在一起，你是否經常由于”關門”而誤觸了“報警”按鈕哲身？再比如辩涝，你在網頁中填寫了一個長長的表單，點擊“提交”按鈕后勘天，系統(tǒng)提示輸入信息有誤怔揩，卻并沒有告訴你錯誤的哪里，你是會不耐煩地從頭查閱脯丝，還是干脆放棄商膊？

Defects的產生與應對策略

產品質量是團隊共同的責任，軟件開發(fā)是一個過程宠进，任何環(huán)節(jié)都有可能產生質量問題晕拆，但每個環(huán)節(jié)的問題都應該選擇比較恰當?shù)奶幚矸绞健?/p>

在敏捷開發(fā)中，我們以迭代的形式逐步完成產品的開發(fā)材蹬，每個迭代都能以一個可交付的軟件呈現(xiàn)給用戶实幕，從而盡早地獲得用戶反饋，以保證我們交付的軟件是用戶真正期望的堤器。在每個迭代中昆庇，我們所有的開發(fā)都基于用戶故事卡（Story），每一張用戶故事卡都將經歷Analyse闸溃、Design整吆、Code拱撵、Test、Deploy的過程表蝙。

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

image

正如上圖所示集索，Defect分別來自于Sprint階段欲诺、UAT用戶驗收階段以及真正的生產環(huán)境渺鹦。其中毅厚，Sprint階段又細分為：不合理的需求、不恰當?shù)脑O計祠锣、代碼及邏輯錯誤伴网、Story卡測試過程中發(fā)現(xiàn)的問題妆棒、回歸測試中發(fā)現(xiàn)的問題、以及非功能性測試發(fā)現(xiàn)的問題动分。

開發(fā)過程中不同階段的Defects澜公，我們分別采用什么樣的敏捷實踐來應對呢坟乾？

image

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

• 不合理的需求: 由于QA往往有不同于BA的視角，提早與BA Pair完善Story AC (Acceptance Criteria）宗兼。此時發(fā)現(xiàn)的問題要及時補充到Story卡上。這樣殷绍，不僅能夠盡早地發(fā)現(xiàn)需求上的不合理或遺漏主到，還有助于QA深入理解需求、設計測試用例畔师。
• 不恰當?shù)脑O計：UX制作出酷炫的設計圖看锉，卻并不一定是用戶真正期望的塔鳍，或者技術實現(xiàn)的成本過高。因此腔寡，一方面放前，要在開發(fā)之前與用戶Review設計圖郑兴，并按照用戶的反饋及時更新情连；另一方面，在每一張Story卡開始開發(fā)之前虫几，由BA辆脸、UX螃诅、QA及Dev一起Kick Off Story，通過討論和澄清倘是，使得團隊成員對需求和設計達成一致。一旦發(fā)現(xiàn)問題叨粘，要及時更新Story卡和設計圖升敲。
• 代碼及邏輯錯誤：單元測試轰传、Code Review绸吸、Desk Check都是用來發(fā)現(xiàn)代碼及邏輯錯誤的有效手段设江。因此叉存，開發(fā)提交代碼后，要先執(zhí)行單元測試稿存、只有當單元測試通過之后瓣履，才可以將代碼部署到QA測試環(huán)境练俐；然后按照Story的AC逐條與QA和BA進行Desk check。除此之外燕锥，開發(fā)團隊要每天堅持Code Review悯蝉，以便發(fā)現(xiàn)代碼邏輯及編碼規(guī)范方面的問題鼻由。這些過程中發(fā)現(xiàn)的Defects都應該盡快修復厚棵。
• Story卡測試中發(fā)現(xiàn)的問題：Story卡測試時發(fā)現(xiàn)的問題窟感，無論其嚴重程度如何柿祈，基本上都要在當前迭代修復哩至。QA可以與Dev面對面溝通菩貌，也可以將Defect添加到Story的Comment里面，再將Story重新拖回In Dev狀態(tài)虚茶，或者在物理看板上添加一張物理卡片嘹叫。但無論哪種形式诈乒，都需要在早會時提及怕磨，以便有效地跟蹤Defect進度。
• 回歸測試中發(fā)現(xiàn)的問題：普遍來講员帮，回歸測試發(fā)現(xiàn)的問題捞高，優(yōu)先級要低于Story的開發(fā)帜消。因此，QA需要在電子看板或者Defects管理系統(tǒng)中提交一條Defect記錄辈讶，然后與BA溝通贱除，在最合適的時間Assign給Dev。但如果該Defect造成系統(tǒng)崩潰或者Block了某些功能的使用碍讯，就應該立即修復它扯躺。
• 非功性測試發(fā)現(xiàn)的問題：非功能性測試一般是在每個Release上線之前做录语，發(fā)現(xiàn)的問題也要在Release之前修復。同樣需要在電子看板或者Defects管理系統(tǒng)中提交Defect記錄虽缕，但要注意其優(yōu)先級氮趋。
• UAT用戶驗收階段的反饋：在UAT階段江耀，開發(fā)團隊向用戶Showcase，或者由用戶來做用戶驗收測試摧冀。此時，用戶會提出一些反饋建车。由QA和BA對這些反饋進行分析，如果是功能層面的問題潮罪，在看板上建成卡片领斥，并在上線前修復月洛。如果是需求層面的問題，就將其添加到需求列表中嚼黔，以便安排在之后的迭代計劃中。
• 生產上的問題：生產上的問題優(yōu)先級是最高的疫赎。但是與用戶反饋一樣捧搞，功能層面的問題要立即修復，用戶體驗上的問題要添加在需求列表中陌僵。

Defects對質量管理的啟示

Defects并不是獨立存在的创坞，它或多或少反映出了項目管理和開發(fā)過程中存在的問題题涨，這些問題都可能對質量產生影響。比如：線上問題的走勢巡雨，是否能夠反映出產品質量的變化席函；分析每個迭代Defects的數(shù)據及產生的原因茂附，有助于發(fā)現(xiàn)開發(fā)過程中出現(xiàn)的問題，及時地進行風險把控乒验。

我以自己所在項目為例蒂阱，說一說Defects給質量管理和團隊管理帶來的啟示录煤。

1. 通過線上問題走勢，分析產品質量的變化

2017年8月了嚎，我們接到A遺留系統(tǒng)响委，到10月份累計在生產環(huán)境發(fā)現(xiàn)歷史遺留問題21個。按照優(yōu)先級夹囚，每個月修復一定的數(shù)量荸哟。截止2018年7月，發(fā)現(xiàn)的歷史遺留問題高達46個舵抹，只剩余2個還未修復劣砍。Defects數(shù)量在減少刑枝，產品質量在逐步提升。

image

除此之外靠娱，我們對歷史遺留問題和新引入問題做了對比像云，這10個月的線上問題中蚂夕，歷史遺留問題占85%，新引入問題占15%百框，可見仍有部分沒能在開發(fā)過程中發(fā)現(xiàn)，使其流到線上柬泽。要對這些問題具體分析：其嚴重程度如何、產生的原因是什么露该、為什么在開發(fā)過程中沒有發(fā)現(xiàn)解幼、后續(xù)有怎樣的改進措施。 當然撵摆，最好能對生產上的“運維類問題”和“功能類問題”加以區(qū)分特铝，以便采取更恰當?shù)母倪M措施鲫剿。

2. 分析迭代Defects情況，討論改進措施

除了分析線上問題雕凹，我還對從2017年10月-2018年7月QA提交的Defects情況做了一個統(tǒng)計枚抵，觀察每個月提交的Defects和修復的Defects情況俄精。

image

從統(tǒng)計結果來看竖慧，2018年7月發(fā)現(xiàn)和修復的Defects數(shù)量均呈明顯的上升趨勢圾旨，達到歷史最高點魏蔗。因此莺治，有必要對7月份的Defects情況做一個詳細的分析，看看究竟是什么原因導致了這些Defects床佳。

image

我對這些Defects做了一個初步的分類砌们，并利用Retrospective Meeting的機會浪感，與團隊成員一起分析討論。發(fā)現(xiàn)產生問題的原因有以下幾個方面：

• 本次Release的Story Kick Off和Desk Check做的不夠好揭斧。有時候開發(fā)沒有Kick Off就直接按照自己的理解開始編碼未蝌，導致團隊成員沒有對需求達成一致的理解萧吠，做出來的功能出現(xiàn)偏差纸型。有時候Dev將一堆卡壘在一起做Desk Check狰腌，這樣很難逐條覆蓋AC琼腔，從而將問題流入QA測試階段踱葛。
• 本次的需求比較偏技術，BA只能從業(yè)務的角度去編寫Story卡甥材。開發(fā)同學為了追趕工期洲赵，沒能夠添加充分的Tech Task, 也沒能夠堅持Code Review商蕴，導致出現(xiàn)一些邏輯錯誤绪商。
• 單元測試覆蓋率比較低俭令。作為一個遺留的微服務系統(tǒng)，某些服務在之前從未重構過部宿，代碼邏輯比較混亂，添加單元測試的難度大、成本高理张。因此一些本該單元測試階段就能發(fā)現(xiàn)的問題一直流到QA測試階段赫蛇。
• 本次Release一共一個月時間，UI一直到最后一個禮拜才確定下來雾叭，期間反反復復的修改不僅花費了太多成本悟耘，還消磨了Dev的意志，導致出現(xiàn)一些本不該出現(xiàn)的Defects织狐。
• 新人加入暂幼，項目工期緊，對上下文信息同步不夠移迫，導致新開發(fā)的內容破壞了一些已經驗證過的功能邪媳。

這些原因充分說明了這段時間項目中存在的問題，我們對此逐條提出了具體的改進措施：

• 堅決執(zhí)行Story Kick Off和Desk Check敏捷實踐，在每日站會時嚴格跟蹤每一張Story卡的進度据悔。
• 預定一個定期會議，每天下午17:00 - 18:00進行Code Review，并每周一人輪班擔任Owner浸赫。
• 將單元測試覆蓋率可視化运敢。同時迄沫，制定項目標準：對于新開發(fā)的內容，必須編寫并通過單元測試才能Desk Check；對于歷史遺留模塊，在技術債墻上添加技術債卡片侧戴，并于每周消化一個技術債務疆拘。
• 項目開發(fā)前期要加強與客戶和用戶的溝通，在Story開始開發(fā)之前翔烁，確定好UI設計白华，開發(fā)過程中盡量避免大的改動厦取。
• 新人加入項目時铡买，采用結對編程的方式完成開發(fā)。除此之外樊拓，每周在項目內進行一次技術分享Session图呢。

當然指蚜，以上兩點只是我基于A項目舉的一個例子。實際上，Defects還給了我們很多啟示，比如石窑，為什么項目老是加班经宏？為什么有些模塊的Defects數(shù)量比較多沪斟？如何根據團隊成員花在Defects上的efforts，制定提升計劃？然而所森，每個項目的情況不一樣滋戳，我們應該基于自己的項目背景肝匆，由團隊成員一起分析深層次的原因能曾，共同制定切實可行的改進措施，從而不斷地提高產品質量。

文/ThoughtWorks 史湘陽