起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識從0到1創建高效的產品缺陷管理流程（1）：缺陷是什么? 如何建立缺陷管理流程？
在任何軟件生命周期中，軟件缺陷的出現幾乎是不可避免的。建立一套有效的缺陷管理流程的目的是為了減少軟件缺陷出現的幾率，并且大幅度降低由于軟件缺陷帶來的負面影響。對于缺陷管理流程的投資，可以大幅度的降低由于返工/修復缺陷導致的人力，財力和時間浪費，同時提升用戶的體驗或者更多用戶留存與產品口碑，并且可以保障產品更準時的交付。
在正式開始談論產品缺陷管理流程建設之前，我們首先介紹下一些基本概念：
軟件Bug和缺陷有什么區別？
什么是Bug?
Bug最初是在軟件行業的計算機用語，是指由于錯誤編碼導致的結果。
缺陷是什么?
缺陷的英文：Defect，缺陷是指不符合最初定義的業務需求，其覆蓋范圍高于Bug,除了錯誤編碼外其他導致不符合最初定義的業務需求問題都屬于缺陷范疇。
這兩個術語Bug和Defect在英文中有非常細微的區別，但在行業中都是需要修復的錯誤，因此一些測試團隊并不對這兩個詞語做細分。
當測試人員執行測試用例時，他可能會遇到與預期結果不一致的測試結果。
測試結果中的這種不一致被稱為軟件缺陷。這些缺陷在不同的團隊中有不同的稱呼，如錯誤，缺陷，Bug，問題等。
缺陷報告應該包括的信息：
當向開發人員反饋缺陷時，您的缺陷報告應該包含以下信息：
- 缺陷ID：缺陷的唯一標識號
- 缺陷描述：詳細描述缺陷，包括發現缺陷的模塊的信息。
- 軟件版本：發現缺陷的軟件程序的版本號。
- 復現步驟：詳細的步驟，以及開發人員可以復現缺陷的屏幕截圖。
- 缺陷提交日期：提交缺陷的日期
- 相關文檔：通過相關的需求、設計、架構文檔并對比，能夠讓人更容易理解，例如產品需求文檔，相關產品原型或者用例文檔等
- 提交人：由誰發現的缺陷。
- 缺陷的狀態：缺陷當前的修復狀態，我們稍后將詳細介紹
- 修復人：修復缺陷的開發人員
- 缺陷關閉日期：缺陷被關閉/解決的日期
- 缺陷等級：描述缺陷對軟件程序的影響的嚴重程度
- 缺陷優先級：優先級與缺陷修復的緊迫性相關。嚴重程度優先級可以是高/中/低，這取決于缺陷修復對應用影響的緊急程度
如果沒有有效的缺陷管理流程會怎么樣？
其實無論團隊是否有花費時間和精力創建缺陷管理流程，缺陷管理流程總歸是會存在的，但這一流程并不一定有效，我見過一些團隊并沒有一套有效的流程，而是通過口頭或者郵件的方式進行著缺陷管理，這些方式可能會導致許多問題，下面我舉一個簡單的實例：
如果像上述的情況一樣通過口頭或者簡單郵件溝通進行缺陷管理，很快事情會變得十分復雜，如果你作為產品經理，想要控制和有效管理缺陷問題，您需要了解一個缺陷的生命周期以及如何建立一套有效的缺陷管理流程。
缺陷管理的流程
為了能夠有效的管理缺陷問題，你需要建設一套有效的缺陷管理流程，以避免上述示例中這種無序混亂的狀態。 本部分將指導您如何將缺陷管理過程應用于項目中。管理缺陷可以分為以下步驟：
（1）發現缺陷：新建
一般缺陷問題有測試團隊根據用例步驟進行測試，如果不能正常通過用例則轉為缺陷問題。但是很多團隊并沒有專門的測試團隊，因此創建問題缺陷的可能來自不同團隊或者來自外部用戶提交的反饋信息。這些缺陷反饋其缺陷狀態應該為“新建”。
（2）開啟
當QA測試團隊或者其他相同職務的團隊確認了反饋的缺陷問題后，比如可以復現，則確認反饋是一個缺陷，并等待分配給開發團隊。
（3）分配
當測試團隊確認缺陷后，應該將問題分配給開發團隊進行缺陷定位和修復工作。
（4）拒絕
如果開發團隊認為提交上來的缺陷并不是真正的缺陷，比如由于緩存，網絡導致的部分文件加載失敗導致的問題等，應將缺陷狀態標記為“拒絕”并指派回測試團隊。測試團隊需要重新測試或者提供更多的缺陷信息。
（5）重復
如果開發團隊收到的缺陷是重復的，或者與其他正在進行中的缺陷問題相似，應將缺陷狀態修改為“重復”
（6）延期
部分不緊急的缺陷問題，可能會隨著日后的產品迭代中進行修復。對于這類缺陷應當標注為“延期”。在這里要注意，并不是所有缺陷都需要立即進行修復。每個缺陷問題在嚴重程度，影響范圍均有不同，因此優先修復的等級也不同。我會在下一篇文章中單獨講解制定優先級別的方法。
（7）等待測試
當開發團隊修復缺陷后，應將缺陷狀態標記為等待測試并由測試團隊進行測試。
（8）關閉
在測試通過后，缺陷狀態修改為“關閉”或者完成。
（9）重新開啟
如果缺陷修復后并沒有通過測試，應標記為重新開啟，并重新啟用分配流程。
重要的缺陷KPI指標
管理學大師德魯克說過：你無法管理那些你無法衡量的事情。 缺陷管理也是一樣，你需要有一些可供參考的指標，以便衡量管理效果. 您可以考慮使用以下兩個簡單的指標來衡量您測試團隊的執行效果：
- 缺陷拒絕率?(Defect Rejection Ratio, 簡稱DRR)：（拒絕的缺陷數量/總測試團隊報告的缺陷數量）*100%
- 缺陷遺漏率?(Defect Leakage Ratio, 簡稱DLR)：（遺漏的缺陷數量/總的缺陷數量）*100%
下面我舉一個簡單的實例：
Bugout的測試團隊在Bugout的一次產品升級測試中，發現了50個Bug并反饋給開發團隊，其中5個經過核實并不是Bug。新版本上線后，收到與本次升級相關的問題反饋10條并確認均為Bug。
缺陷拒絕率（DRR)=5/50=10%
缺陷遺漏率（DLR)=10/(50-5+10)=18.18%
DRR和DLR的值越小，測試執行的質量越好。 什么是可接受的比例范圍？ 可以在項目目標中定義和接受此范圍，也可以參考類似項目的指標。
相關閱讀
從0到1創建高效的產品缺陷管理流程（2）：如何設置合理的Bug處理優先級
從0到1創建高效的產品缺陷管理流程（3）：如果選擇一款Bug管理工具？
#專欄作家#
陳迪，人人都是產品經理專欄作家。Testin云測SaaS運營總監，Bugout缺陷管理產品運營負責人，增長黑客，多年國內和海外互聯網公司運營經驗，專注于SaaS和B2B企業服務行業。
本文原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自 Pixabay，基于 CC0 協議
- 目前還沒評論，等你發揮！
