在任何軟件生命周期中，軟件缺陷的出現(xiàn)幾乎是不可避免的。建立一套有效的缺陷管理流程的目的是為了減少軟件缺陷出現(xiàn)的幾率，并且大幅度降低由于軟件缺陷帶來的負面影響。對于缺陷管理流程的投資，可以大幅度的降低由于返工/修復(fù)缺陷導(dǎo)致的人力，財力和時間浪費，同時提升用戶的體驗或者更多用戶留存與產(chǎn)品口碑，并且可以保障產(chǎn)品更準時的交付。
在正式開始談?wù)摦a(chǎn)品缺陷管理流程建設(shè)之前，我們首先介紹下一些基本概念：
軟件Bug和缺陷有什么區(qū)別？
什么是Bug?
Bug最初是在軟件行業(yè)的計算機用語，是指由于錯誤編碼導(dǎo)致的結(jié)果。
缺陷是什么?
缺陷的英文：Defect，缺陷是指不符合最初定義的業(yè)務(wù)需求，其覆蓋范圍高于Bug,除了錯誤編碼外其他導(dǎo)致不符合最初定義的業(yè)務(wù)需求問題都屬于缺陷范疇。
這兩個術(shù)語Bug和Defect在英文中有非常細微的區(qū)別，但在行業(yè)中都是需要修復(fù)的錯誤，因此一些測試團隊并不對這兩個詞語做細分。
當測試人員執(zhí)行測試用例時，他可能會遇到與預(yù)期結(jié)果不一致的測試結(jié)果。
測試結(jié)果中的這種不一致被稱為軟件缺陷。這些缺陷在不同的團隊中有不同的稱呼，如錯誤，缺陷，Bug，問題等。
缺陷報告應(yīng)該包括的信息：
當向開發(fā)人員反饋缺陷時，您的缺陷報告應(yīng)該包含以下信息：
- 缺陷ID：缺陷的唯一標識號
- 缺陷描述：詳細描述缺陷，包括發(fā)現(xiàn)缺陷的模塊的信息。
- 軟件版本：發(fā)現(xiàn)缺陷的軟件程序的版本號。
- 復(fù)現(xiàn)步驟：詳細的步驟，以及開發(fā)人員可以復(fù)現(xiàn)缺陷的屏幕截圖。
- 缺陷提交日期：提交缺陷的日期
- 相關(guān)文檔：通過相關(guān)的需求、設(shè)計、架構(gòu)文檔并對比，能夠讓人更容易理解，例如產(chǎn)品需求文檔，相關(guān)產(chǎn)品原型或者用例文檔等
- 提交人：由誰發(fā)現(xiàn)的缺陷。
- 缺陷的狀態(tài)：缺陷當前的修復(fù)狀態(tài)，我們稍后將詳細介紹
- 修復(fù)人：修復(fù)缺陷的開發(fā)人員
- 缺陷關(guān)閉日期：缺陷被關(guān)閉/解決的日期
- 缺陷等級：描述缺陷對軟件程序的影響的嚴重程度
- 缺陷優(yōu)先級：優(yōu)先級與缺陷修復(fù)的緊迫性相關(guān)。嚴重程度優(yōu)先級可以是高/中/低，這取決于缺陷修復(fù)對應(yīng)用影響的緊急程度
如果沒有有效的缺陷管理流程會怎么樣？
其實無論團隊是否有花費時間和精力創(chuàng)建缺陷管理流程，缺陷管理流程總歸是會存在的，但這一流程并不一定有效，我見過一些團隊并沒有一套有效的流程，而是通過口頭或者郵件的方式進行著缺陷管理，這些方式可能會導(dǎo)致許多問題，下面我舉一個簡單的實例：
如果像上述的情況一樣通過口頭或者簡單郵件溝通進行缺陷管理，很快事情會變得十分復(fù)雜，如果你作為產(chǎn)品經(jīng)理，想要控制和有效管理缺陷問題，您需要了解一個缺陷的生命周期以及如何建立一套有效的缺陷管理流程。
缺陷管理的流程
為了能夠有效的管理缺陷問題，你需要建設(shè)一套有效的缺陷管理流程，以避免上述示例中這種無序混亂的狀態(tài)。 本部分將指導(dǎo)您如何將缺陷管理過程應(yīng)用于項目中。管理缺陷可以分為以下步驟：
（1）發(fā)現(xiàn)缺陷：新建
一般缺陷問題有測試團隊根據(jù)用例步驟進行測試，如果不能正常通過用例則轉(zhuǎn)為缺陷問題。但是很多團隊并沒有專門的測試團隊，因此創(chuàng)建問題缺陷的可能來自不同團隊或者來自外部用戶提交的反饋信息。這些缺陷反饋其缺陷狀態(tài)應(yīng)該為“新建”。
（2）開啟
當QA測試團隊或者其他相同職務(wù)的團隊確認了反饋的缺陷問題后，比如可以復(fù)現(xiàn)，則確認反饋是一個缺陷，并等待分配給開發(fā)團隊。
（3）分配
當測試團隊確認缺陷后，應(yīng)該將問題分配給開發(fā)團隊進行缺陷定位和修復(fù)工作。
（4）拒絕
如果開發(fā)團隊認為提交上來的缺陷并不是真正的缺陷，比如由于緩存，網(wǎng)絡(luò)導(dǎo)致的部分文件加載失敗導(dǎo)致的問題等，應(yīng)將缺陷狀態(tài)標記為“拒絕”并指派回測試團隊。測試團隊需要重新測試或者提供更多的缺陷信息。
（5）重復(fù)
如果開發(fā)團隊收到的缺陷是重復(fù)的，或者與其他正在進行中的缺陷問題相似，應(yīng)將缺陷狀態(tài)修改為“重復(fù)”
（6）延期
部分不緊急的缺陷問題，可能會隨著日后的產(chǎn)品迭代中進行修復(fù)。對于這類缺陷應(yīng)當標注為“延期”。在這里要注意，并不是所有缺陷都需要立即進行修復(fù)。每個缺陷問題在嚴重程度，影響范圍均有不同，因此優(yōu)先修復(fù)的等級也不同。我會在下一篇文章中單獨講解制定優(yōu)先級別的方法。
（7）等待測試
當開發(fā)團隊修復(fù)缺陷后，應(yīng)將缺陷狀態(tài)標記為等待測試并由測試團隊進行測試。
（8）關(guān)閉
在測試通過后，缺陷狀態(tài)修改為“關(guān)閉”或者完成。
（9）重新開啟
如果缺陷修復(fù)后并沒有通過測試，應(yīng)標記為重新開啟，并重新啟用分配流程。
重要的缺陷KPI指標
管理學(xué)大師德魯克說過：你無法管理那些你無法衡量的事情。 缺陷管理也是一樣，你需要有一些可供參考的指標，以便衡量管理效果. 您可以考慮使用以下兩個簡單的指標來衡量您測試團隊的執(zhí)行效果：
- 缺陷拒絕率?(Defect Rejection Ratio, 簡稱DRR)：（拒絕的缺陷數(shù)量/總測試團隊報告的缺陷數(shù)量）*100%
- 缺陷遺漏率?(Defect Leakage Ratio, 簡稱DLR)：（遺漏的缺陷數(shù)量/總的缺陷數(shù)量）*100%
下面我舉一個簡單的實例：
Bugout的測試團隊在Bugout的一次產(chǎn)品升級測試中，發(fā)現(xiàn)了50個Bug并反饋給開發(fā)團隊，其中5個經(jīng)過核實并不是Bug。新版本上線后，收到與本次升級相關(guān)的問題反饋10條并確認均為Bug。
缺陷拒絕率（DRR)=5/50=10%
缺陷遺漏率（DLR)=10/(50-5+10)=18.18%
DRR和DLR的值越小，測試執(zhí)行的質(zhì)量越好。 什么是可接受的比例范圍？ 可以在項目目標中定義和接受此范圍，也可以參考類似項目的指標。
