目錄
1 引言
敏捷測試原則中有一條是：預防缺陷，而不是關注缺陷的數量。敏捷團隊中是整個團隊爲質量負責，團隊追求的是整個產品質量的提升，而非傳統的開發人員追求零缺陷，測試人員追求找到更多的缺陷。在敏捷開發中，雖然我們採取各種措施預防缺陷的發生，例如精準的自動化測試、代碼檢視、故事卡驗收等等，但是並不能保證沒有缺陷發生，一個零缺陷的產品也不現實。既然無法完全阻止缺陷的出現，那如何管理髮生的缺陷，如何利用已有缺陷來指導質量內建過程，是我們需要考慮的。
本文以博主在實際項目中的經驗，講述缺陷的記錄、流轉和分析，每個模塊的內容會分別講述迭代內缺陷和生產缺陷的管理。
2 缺陷記錄
2.1 哪些缺陷該被記錄？
在記錄缺陷前，我們要理清楚我們需要記錄的缺陷有哪些，是不是每一個缺陷都應該被記錄。敏捷項目是以迭代爲交付週期，一個迭代週期從兩週到一個月甚至2個月不等，每個迭代都會有新功能的上線。一般來講，缺陷分爲兩類：一類是迭代內缺陷，即在迭代新功能開發時，故事驗收或測試階段發生的缺陷；另一類則是生產缺陷，我們是允許生產缺陷的存在的，但前提是缺陷影響範圍可控，或者可以在用戶發現前發現缺陷（測試右移），並且要具備快速修復或者回滾的能力。
對於迭代內缺陷，一般發現階段分爲故事卡驗收階段，測試階段，迴歸測試階段。對於故事卡驗收階段發現的缺陷，是否需要記錄可視情況而定，一般而言，可以不需要記錄，因爲此時故事卡仍在開發階段，開發同學仍然工作在這張卡上，其上下文充足，修復缺陷成本較低，可以直接備註在卡片上，等下一次故事卡驗收的時候再驗證是否修復。對於測試階段和迴歸測試階段的缺陷，建議記錄下來，因爲此時開發這張卡片功能的開發同學已工作在其他卡片上，沒有辦法及時修復該缺陷，或者修復該缺陷的或許是其他開發人員，那麼就需要將缺陷記錄下來便於跟蹤。
2.2 工具
在選擇缺陷記錄工具的時候，要考慮以下幾點：
- 該工具是否支持協同工作？
缺陷和故事卡一樣重要，是各個角色都需要關心的事情，即意味着各個角色都需要能夠查看、操作缺陷記錄工具，所以缺陷記錄工具需要支持協同工作。 - 該工具是否容易學習？
基於第一點，團隊成員均需要操作該工具，不管是否有技術背景，所以該工具一定是需要學習成本較低的。 - 該工具是否易於跟蹤缺陷狀態？
缺陷和故事卡一樣，是存在流轉狀態的，也會有不同的人員工作在該缺陷上（開發人員、測試人員），所以記錄工具最好具有狀態流轉標識，當然你也可以手動記錄其狀態，但能讓工具幫你做的事情爲什麼不利用工具呢？ - 該工具是否清晰記錄缺陷？
下一小節會講到缺陷記錄的要素，選擇的工具需要能清晰表達這些要素。 - 該工具是否便於統計？
缺陷管理中很重要的一部分是缺陷分析，缺陷分析當然是基於數據的，這些數據可以手動收集，如果工具能自動幫你做一些統計那是最好的。
所選擇的工具不一定需要具備以上提到的所有特徵，但是支持協同工作和清晰記錄缺陷是必不可少的，其餘特徵可根據項目情況而定。
博主所在的項目選擇的工具是jira，jira是一款協同辦公軟件，在敏捷項目中通常被用來記錄故事卡。它支持協同辦公，而且我們項目也使用jira記錄故事卡，我們在故事卡的泳道下面新建了一個跟蹤缺陷卡的泳道，一個缺陷記錄一張卡片，這樣大家就可以像操作故事卡一樣操作缺陷卡。它也支持添加自定義標籤的，標註卡片優先級，添加附件，充分滿足缺陷關聯的內容。它也支持導出卡片數據，對之後的缺陷分析十分有幫助。博主也推薦使用trello，和jira的功能大同小異，當然在線wps的excel也是不錯的選擇。
使用jira記錄缺陷，主要是爲了便於查看缺陷狀態，但會隨着迭代的完成，缺陷卡片會被歸檔，每張卡片也是獨立的，不利於集中查看和查詢。這樣的流轉方式對迭代內缺陷是沒有問題的，因爲迭代內缺陷一旦修復，後續基本不會有人再去查看關注。但對生產缺陷卻不一樣，每一個生產缺陷都應該被認真對待分析，我們可以將其統一記錄在某個地方，用於之後回顧。博主項目組的做法是將生產缺陷統一記錄在confluence，便於集中查看。
2.3 模版
記錄缺陷有兩個原則：
- 描述完整，清晰易讀懂
記錄的缺陷卡和故事卡一樣，需要給團隊成員看，所以缺陷卡需要描述完整清晰。 - 規範化，便於缺陷分析
分析統計總是基於規劃的數據結構，所以在記錄缺陷的時候就需要考慮之後缺陷分析需要什麼，以此去規範戶記錄缺陷。
以博主的項目爲例，我們記錄缺陷的模版主要有以下要素：
- 標題
簡述缺陷內容，清晰明瞭。 - 描述
缺陷發生環境（DEV/ST/UAT/PRD），相關測試數據（用戶名/訂單號等），復現步驟，期望結果，實際結果，備註（截圖、日誌等）。 - 優先級
在卡片上（jira/trello）備註缺陷的優先級，可以是高、中、低，可以自定義。 - 標籤
便於之後的缺陷分析，可以給缺陷打上標籤。以博主項目爲例，針對生產缺陷，會標註以下標籤：所屬功能模塊（根據系統自定義）、可識別階段（需求階段/開發階段/測試階段/難以識別）、缺陷類型（功能/性能/安全）、影響範圍（大/中/小）。
3 缺陷流轉
每個缺陷也應該像故事卡一樣，有它完整的生命週期，本節以博主項目組爲例詳解迭代內缺陷和生產缺陷的流轉過程，當然每個組情況不一樣，讀者可視自身項目組情況而定。
3.1 迭代內缺陷流轉過程
上文講到，迭代內缺陷和故事卡記錄在同一jira面板的不同泳道，那麼缺陷卡的生命週期和故事卡自然是一樣的，如下圖所示：
針對迭代內的缺陷應該在什麼時候修復，我們的處理原則有以下幾點：
- 如果是阻礙開發/測試進度的缺陷，應該被立即修復；
- 如果是本迭代必須交付的功能相關缺陷，且修復成本高或影響範圍大的缺陷，應該被立即修復；
- 如果是本迭代必須交付的功能相關缺陷，但修復成本或影響範圍較小的缺陷，留到迭代後期修復。
3.2 生產缺陷流轉過程
生產缺陷總是值得被引起重視的，我們對其處理流程如下圖所示：
4 缺陷分析
引言中已經提到，敏捷項目中的質量內建關鍵在於預防缺陷，但一個產品不可能零缺陷，既然缺陷已經發生，就要利用好缺陷。對已發生的缺陷進行深入分析，從中找到問題所在，即達到預防缺陷的目的。
4.1 迭代內缺陷分析
4.1.1 分析週期
迭代內缺陷的數量比較多，而且一般大多數都是開發邏輯錯誤造成的，一般而言分析價值不大。如果每個迭代平穩運行，缺陷數量平穩，建議不用特意分析，畢竟分析是耗時的。如果某個迭代明顯感覺缺陷數量增長，可以針對性對本迭代缺陷進行分析。當然，如果你有充分的時間，可以將缺陷分析作爲一項日常工作。
4.1.2 分析角度
對於迭代內缺陷，分析的角度可以有以下幾個：
- 缺陷根因
可以將缺陷一一分析後進行歸類，可以是：需求缺失或者需求不清晰、技術方案設計問題、代碼邏輯錯誤、測試未覆蓋、環境相關（硬件、軟件、第三方等）。分類後如果某一類問題較突出，則可以針對性產出改進事項。 - 缺陷發現階段
缺陷發現階段可以歸類爲：故事驗收階段、功能測試階段、迴歸測試階段。我們知道缺陷越早發現修復成本越低，如果分析後發現某一階段發現的缺陷較多，應該去反思是哪個環節出錯了，我們是否可以更早的暴露缺陷。 - 缺陷所屬功能模塊
功能所屬模塊根據系統不同而不同，這一類分析幫助我們思考，某一塊存在的缺陷多是因爲存在技術債還是測試覆蓋不夠，可以幫助我們改進質量策略。 - 缺陷數量趨勢
如果可以，對於迭代內缺陷可以維護一份數量趨勢圖，就不需要我們靠直覺去感受哪個迭代缺陷多，而是有真實的數據作爲依據，更具說服力。
4.1.3 可視化工具
數據有了，就需要將數據可視化出來，便於分析，便於展示給團隊。博主曾使用過的可視化工具有：
- jira
jira根據卡片自動生成圖標，餅圖、趨勢圖都可以，但好像只有企業定製版纔可以。 - ppt
將jira數據導出，然後導入ppt畫圖。只要記錄的缺陷卡片規範，也不是很費時，但沒辦法展示趨勢，只能展示導出階段的數據。 - tableau
可以畫各種圖，對於展示趨勢圖也很方便，但是一款商業工具，而且上手成本並不低，它主要的功能是進行數據分析，畫圖只是它的九牛一毛，用它做缺陷分析有點大材小用的意思了。
所以呢，其實我也沒有特別好的工具推薦，大家如果有更好的，歡迎交流呀。
4.2 生產缺陷分析
4.2.1 分析週期
再一次強調，每一個生產缺陷都值得被重視，所以應該認真對待每一個生產缺陷。3.2節講述的流轉過程，其中我們就已經對其進行分析了，分析其問題出在哪兒，然後補充相應的測試。如果想要對生產缺陷進行歸類、趨勢分析，那麼就需要有一定的數據纔可以，而生產缺陷不常有。所以其分析週期建議是1個月，或者3個月，甚至6個月，視各個項目組的情況而定。
4.2.2 分析角度
對於生產缺陷，分析的角度可以有以下幾個：
- 缺陷根因
同4.1.2 - 缺陷可識別階段
缺陷可識別階段可以歸類爲：需求分析階段、開發階段、測試階段、發佈階段，難以識別。這樣分類的初衷不在於歸過於某一角色，某一人，在敏捷團隊每個人都會全程參與。而是爲了進一步分析是哪一階段的實踐有缺失，需要進一步改善。 - 缺陷所屬功能模塊
同4.1.2 - 缺陷數量趨勢
同4.1.2，長期的生產缺陷數量趨勢也是反應產品質量的一個關鍵指標。 - 缺陷類型
缺陷類型可以歸類爲：功能缺陷，性能缺陷，安全缺陷。敏捷團隊質量內建需要關注產品各個方面的質量，所以也需要我們進行各種類型的質量內建，包括性能、安全等，將缺陷類型劃分清楚，可以指導我們補充我們薄弱的地方。
4.2.3 可視化工具
同4.1.3