在過去的幾個月，我做了一些實踐，通過整理、討論和分析項目上的Defects情況，來探索質量管理中的待改進點。最終發現，Defects實際上給質量管理帶來了很多的啟示。

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

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

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

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

Defects的產生與應對策略

產品質量是團隊共同的責任，軟件開發是一個過程，任何環節都有可能產生質量問題，但每個環節的問題都應該選擇比較恰當的處理方式。

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

那么，在敏捷軟件開發過程中，哪些環節都可能產生Defect呢?

正如上圖所示，Defect分別來自于Sprint階段、UAT用戶驗收階段以及真正的生產環境。其中，Sprint階段又細分為：不合理的需求、不恰當的設計、代碼及邏輯錯誤、Story卡測試過程中發現的問題、回歸測試中發現的問題、以及非功能性測試發現的問題。

開發過程中不同階段的Defects，我們分別采用什么樣的敏捷實踐來應對呢?

上圖以看板的形式展示了Sprint開發中Story卡片流動的過程，以及每個環節的敏捷實踐，這些實踐有助我們發現和改善質量問題：

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

Defects對質量管理的啟示

Defects并不是獨立存在的，它或多或少反映出了項目管理和開發過程中存在的問題，這些問題都可能對質量產生影響。比如：線上問題的走勢，是否能夠反映出產品質量的變化;分析每個迭代Defects的數據及產生的原因，有助于發現開發過程中出現的問題，及時地進行風險把控。

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

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

2017年8月，我們接到A遺留系統，到10月份累計在生產環境發現歷史遺留問題21個。按照優先級，每個月修復一定的數量。截止2018年7月，發現的歷史遺留問題高達46個，只剩余2個還未修復。Defects數量在減少，產品質量在逐步提升。

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

當然，最好能對生產上的“運維類問題”和“功能類問題”加以區分，以便采取更恰當的改進措施。

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

除了分析線上問題，我還對從2017年10月-2018年7月QA提交的Defects情況做了一個統計，觀察每個月提交的Defects和修復的Defects情況。

從統計結果來看，2018年7月發現和修復的Defects數量均呈明顯的上升趨勢，達到歷史最高點。因此，有必要對7月份的Defects情況做一個詳細的分析，看看究竟是什么原因導致了這些Defects。

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

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

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

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

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

【本文是51CTO專欄作者“ThoughtWorks”的原創稿件，微信公眾號：思特沃克，轉載請聯系原作者】

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