既然無法完全阻止缺陷的出現，那如何確保已發生的缺陷得到有效的處理，如何利用已有缺陷來指導質量內建過程，是我們需要考慮的，也就是缺陷管理的內容。
敏捷測試原則中有一條是：預防缺陷，而不是關注缺陷的數量。在敏捷開發中，雖然我們采取了各種措施預防缺陷的發生，例如精準的自動化測試、代碼檢視、故事卡驗收等等，但是并不能保證沒有缺陷發生，一個零缺陷的產品也不現實。既然無法完全阻止缺陷的出現，那如何確保已發生的缺陷得到有效的處理，如何利用已有缺陷來指導質量內建過程，是我們需要考慮的，也就是缺陷管理的內容。本文以某實際項目的缺陷管理為例，結合自己的所思所想，講述缺陷的記錄、流轉和分析。
1. 缺陷記錄
1.1 哪些缺陷該被記錄？
在記錄缺陷前，我們要理清楚需要記錄的缺陷有哪些，是不是每一個缺陷都應該被記錄。一般來講，缺陷分為兩類：一類是迭代內缺陷，即在迭代新功能開發時，故事驗收或測試階段發生的缺陷；另一類則是生產缺陷，我們是允許生產缺陷的存在的，但前提是缺陷影響范圍可控，或者可以在用戶發現前發現缺陷（測試右移），并且要具備快速修復或者回滾的能力。
對于迭代內缺陷，一般發現階段分為故事卡驗收階段，功能測試階段，回歸測試階段。對于故事卡驗收階段發現的缺陷，是否需要記錄可視情況而定，一般而言不需要記錄，因為此時故事卡仍在開發階段，開發同學仍然工作在這張卡上，上下文充足，修復缺陷成本較低，可以直接備注在卡片上，等下一次故事卡驗收的時候再驗證是否修復。對于測試階段和回歸測試階段的缺陷，建議記錄下來，因為此時開發這張卡片功能的開發同學已工作在其他卡片上，沒有辦法及時修復該缺陷，或者修復該缺陷的或許是其他開發人員，那么就需要將缺陷記錄下來便于跟蹤。
對于生產缺陷，每一個都應該被重視并且深入分析，故需要記錄下來。
1.2 記錄工具
在選擇缺陷記錄工具的時候，要考慮以下幾點：
（1）該工具是否支持協同工作？
缺陷和故事卡一樣重要，是各個角色都需要關心的事情，即意味著各個角色都需要能夠查看、操作缺陷記錄工具，所以缺陷記錄工具需要支持協同工作。
（2）該工具是否容易學習？
基于第一點，團隊成員均需要操作該工具，不管是否有技術背景，所以需要一個學習成本低的工具。
（3）該工具是否易于跟蹤缺陷狀態？
缺陷和故事卡一樣存在流轉狀態，也會有不同的人員工作在該缺陷上（開發人員、測試人員），所以記錄工具最好具有狀態流轉標識，當然你也可以手動記錄其狀態，但能讓工具幫你做的事情為什么不利用工具呢？
（4）該工具是否能清晰記錄缺陷？
下一小節會講到缺陷記錄的要素，選擇的工具需要能清晰表達這些要素。
（5）該工具是否便于統計分析？
缺陷管理中很重要的一部分是缺陷分析，缺陷分析當然是基于數據的，這些數據可以手動收集，如果工具能自動幫你做一些統計那是最好的。
所選擇的工具不一定需要具備以上提到的所有特征，但是支持協同工作、易于跟蹤缺陷狀態和清晰記錄缺陷是必不可少的，其余特征可根據項目情況而定。我所在的項目選擇的記錄工具是看板，是項目基于Jira定制化開發的一個協同辦公系統，在這里我們可以將其視為和Jira無異。我們在故事卡的泳道下面新建了一個跟蹤缺陷卡的泳道，一個缺陷記錄一張卡片，這樣大家就可以像操作故事卡一樣操作缺陷卡。它支持添加自定義標簽的，標注卡片優先級，添加附件，充分滿足缺陷關聯的內容。也支持導出卡片數據，對之后的缺陷分析十分有幫助。
使用Jira記錄缺陷，主要是便于查看缺陷狀態，但隨著迭代的完成，缺陷卡片會被歸檔，每張卡片也是獨立的，不利于集中查看和查詢。這樣的流轉方式對迭代內缺陷是沒有問題的，因為迭代內缺陷一旦修復，后續基本不會有人再去查看關注。但對生產缺陷卻不一樣，每一個生產缺陷都應該被認真對待分析，我們可以將其統一記錄在某個地方，用于之后回顧。我們項目組的做法是將生產缺陷統一記錄在Confluence，便于集中查看，只要滿足協同辦公的軟件都可以，在線WPS的Excel，Google Sheets也是不錯的選擇。
使用Jira/Trello這類集需求跟蹤為一體的工具來記錄缺陷的一大好處是，缺陷記錄和故事卡記錄在統一系統/面板中，方便團隊成員共同查看、維護缺陷，不至于只有QA在關注、維護缺陷。查了下網上有許多專門用于缺陷管理的工具，比如Bugout，集缺陷記錄、跟蹤、統計分析于一體，還可以自定義缺陷記錄模版、統計字段類型等，還是比較靈活。當然還有很多其他很多缺陷管理工具，就不在此贅述了。
1.3 缺陷記錄要素
記錄缺陷有兩個原則：
（1）描述完整，清晰易讀懂
記錄的缺陷卡和故事卡一樣，需要給團隊成員看，所以缺陷卡需要描述完整清晰。
（2）規范化，便于缺陷分析
分析統計總是基于規范的數據結構，所以在記錄缺陷的時候就需要考慮之后缺陷分析需要什么，以此去規范化記錄缺陷。
看板是可以自定義卡片內容模版的，所以定義好模版后，團隊任何人都可以根據模版記錄缺陷。如果使用的工具沒辦法自定義模版，建議和團隊同步記錄規則，或者由QA統一記錄。我們項目組記錄的缺陷主要有以下要素：
a.標題
簡述缺陷內容，清晰明了。
b.描述
缺陷發生環境（DEV/ST/預生產/PRD），相關測試數據（ID/用戶名等），復現步驟，期望結果，實際結果，備注（截圖、日志等）。
c.優先級
在卡片上備注缺陷的優先級，一般是高、中、低。
d.缺陷提交人
在卡片操作記錄里有記錄，如果沒有操作記錄，可以以評論或者參與人的形式添加，以便后續開發人員或QA可以快速找到熟悉上下問的人。
e.缺陷修復人
分配卡片經辦人/參與人員即可。
f.標簽
便于之后的缺陷分析，可以給缺陷打上標簽。針對生產缺陷，我們會標注以下標簽：所屬功能模塊（根據系統自定義）、可識別階段（需求階段/開發階段/測試階段/發布階段/難以識別）、缺陷類型（功能/性能/安全）、影響范圍（大/中/小）。
2. 缺陷流轉
每個缺陷也應該像故事卡一樣，有它完整的生命周期，下面以我們項目組為例講述迭代內缺陷和生產缺陷的流轉過程，當然每個組情況不一樣，可視自身項目組情況而定。
2.1 迭代內缺陷流轉過程
上文講到，迭代內缺陷和故事卡記錄在看板的同一面板的不同泳道，那么缺陷卡的生命周期和故事卡基本是一樣的，如下圖所示：
針對迭代內的缺陷應該在什么時候修復，我們的處理原則有以下幾點：
（1）如果是阻礙開發/測試進度的缺陷，應該被立即修復；
（2）如果是本迭代必須交付的功能相關缺陷，且修復成本高或影響范圍大的缺陷，應該被盡早修復；
（3）如果是本迭代必須交付的功能相關缺陷，但修復成本或影響范圍較小的缺陷，留到迭代后期修復，在上線前2/3天時，我們會在站會結束后團隊所有成員一起回顧板子上仍未修復的缺陷卡，大致同步優先級以及上下文。
2.2 生產缺陷流轉過程
在生產缺陷發生后，我們會先決定其優先級以及處理流程，然后快速修復，并對其深入分析，其流轉過程如下圖所示：
3. 缺陷分析
敏捷測試原則說我們應該預防缺陷而不是關注缺陷的數量，所以對于缺陷分析，我們的出發點是：對已發生的缺陷進行深入分析，從中找到問題所在，以達到預防缺陷的目的。
3.1 分析周期
迭代內缺陷的數量比較多，而且一般大多數都是開發邏輯錯誤造成的，一般而言分析價值不大。如果每個迭代平穩運行，缺陷數量平穩，建議不用特意分析，畢竟分析缺陷是耗時的。如果某個迭代明顯感覺缺陷數量增長，可以針對性對本迭代缺陷進行分析。當然，如果你有充分的時間，可以將缺陷分析作為一項日常工作。而對于生產缺陷，每一個都值得被重視。2.2節講述的流轉過程，其中我們就已經對其進行分析了，分析其問題出在哪兒，然后補充相應的測試。如果想要對生產缺陷進行歸類、趨勢分析，那么就需要有一定的數據才可以，而生產缺陷不常有。所以其分析周期建議是1個月，或者3個月，甚至6個月，視各個項目組的情況而定。
3.2 分析角度
我們組常用的分析角度有以下幾個，不同的項目側重點會有所不同。
（1）缺陷根因
可以將缺陷一一分析后進行歸類，根因可以分類為：需求缺失或者不清晰、技術方案設計問題、代碼邏輯錯誤、測試未覆蓋、環境相關（硬件、軟件、第三方等）。分類后如果某一類問題較突出，則可以針對性產出改進事項。
（2）缺陷發現階段
針對迭代內缺陷，發現階段可以歸類為：故事驗收階段、功能測試階段、回歸測試階段。我們知道，缺陷越早發現修復成本越低，如果分析后發現某一階段出現的缺陷較多，應該去反思是哪個環節錯了，我們是否可以更早的暴露缺陷。
（3）缺陷所屬功能模塊
功能所屬模塊根據系統不同而不同，這一類分析幫助我們思考，某一塊存在的缺陷多是因為存在技術債還是測試覆蓋不夠，可以幫助我們改進質量策略。
（4）缺陷數量趨勢
如果可以，對于迭代內缺陷可以維護一份數量趨勢圖，就不需要我們靠直覺去感受哪個迭代缺陷多，而是有真實的數據作為依據，更具說服力。對于生產缺陷，建議可以維護一份數量趨勢圖，因為生產缺陷數量走勢也是反應我們產品質量的一個重要維度。
（5）缺陷可識別階段
這一分類主要針對生產缺陷，缺陷可識別階段可以歸類為：需求分析階段、開發階段、測試階段、發布階段，難以識別。這樣分類的初衷不在于歸過于某一角色，某一人，而是為了進一步分析是哪一階段的實踐有缺失，需要進一步改善。
（6）缺陷類型
缺陷類型可以歸類為：功能缺陷，性能缺陷，安全缺陷。敏捷項目中的QA需要關注產品各個方面的質量，包括性能、安全等，將缺陷類型劃分清楚，可以指導補充我們薄弱的地方。
這些分析維度并不是一開始就是這樣的，途中經歷過多個版本，有增有減。比如一開始我們沒有“缺陷類型”這個分析維度，將所有的缺陷都歸為功能缺陷，后來逐漸關注平臺的安全問題，以及隨著平臺用戶增加，也出現過性能問題，所以加入了“缺陷類型”這個字段。又例如，我們一直保持著“缺陷所屬功能模塊”這個分析維度，而且比較重視該維度分析，因為通過對它的分析常常能發現一些問題。所以分析維度不是固定一層不變的，是可以根據項目實際情況擇優選擇的。
3.3 分析工具
數據有了，就需要將數據可視化出來，便于分析，便于展示給團隊。我們項目組曾使用過的分析工具有：
（1）Jira
一開始我們使用的Jira記錄缺陷，Jira可以根據卡片自動生成圖表，餅圖、趨勢圖都可以，所以記錄分析一體就很方便。
（2）ppt
到后期，使用看板，看板沒有圖表分析的功能。那么我們就將看板數據導出，然后導入PPT畫圖。只要記錄的缺陷卡片規范，也不是很費時，但沒辦法展示趨勢，只能展示導出階段的數據。
（3）Tableau
是一款商業的數據分析工具，可以畫各種圖，對于展示趨勢圖也很方便。但是上手成本并不低，而且它主要的功能是進行數據分析，畫圖只是它的九牛一毛，用它做缺陷分析有點大材小用的意思了。當然也需要現將缺陷數據從看板導出然后導入Tableau。
（4）定制化開發看板插件
我們項目組缺陷分析的工作在團隊內是得到認可的，分析缺陷比較耗時的問題在迭代回顧會時引起大家的關注。于是通過團隊的努力，我們在迭代內排了一定工作量給開發同學基于看板開發了一款用于卡片分析的插件，該插件可以分析故事卡的工具量、投入比等，也可以統計缺陷數量，按缺陷標簽分析自動生成圖表。算是團隊定制化的插件，也具有一定普適性，列入了看板系統官方推薦插件。如果使用Jira/Trello管理缺陷的團隊，也可以嘗試開發一些定制化的缺陷/故事卡分析插件。
以上就是本人基于項目實踐總結的缺陷管理相關內容，主要在于缺陷管理流程和思路的分析，希望對大家有所幫助，也歡迎大家多多交流。
文/ThoughtWorks蔡群堯
