缺陷庫的創建意義
我們為了降低缺陷修復的成本，應提前做好缺陷管理和跟蹤。
缺陷庫主要存放測試過程中發現的bug，以供相關人員跟蹤解決，目的是更好的完成產品或項目，保證測試產品的質量。
我們都知道，每款軟件都有其缺陷，並且不止一個，但不是所有的缺陷都需要修復。每個缺陷反應的問題是不同的，有的嚴重影響軟件系統運行，必須馬上修復；有些功能存在缺陷，但是對系統影響很小，用戶基本用不到，此類缺陷可以推遲或著不修復。
嚴重程度和優先級是軟件缺陷的兩個重要指標項，在實際項目中，要結合用戶實際使用情況，缺陷的影響程度，把軟件缺陷按缺陷類型、缺陷級別、嚴重程度、優先級別進行劃分。詳細的缺陷管理規範參見附錄“缺陷管理規範”。
缺陷狀態
為了更好的對缺陷進行管理，我們需要先認識軟件缺陷的生命週期，如圖2-1所示。
圖2-1缺陷生命週期
在整個缺陷生命週期中，缺陷狀態主要描述測試人員提交的缺陷所處於的一種狀態情況，用於評估測試和產品的現狀。通過圖2-1缺陷生命週期可以看出，缺陷狀態分為：新建、打開、已解決、已關閉、延後解決、已否決、重新打開。具體內容說明如下：
1）新建：測試人員首次提交缺陷的狀態，需要標明缺陷的嚴重級別等要素。由測試人員改變。
2）打開：研發負責人對新建缺陷的確認，變成打開狀態時，需要同時確定缺陷優先級、解決的研發人員、填寫計劃修復時間，計劃關閉版本。由研發人員改變。
3）已否決：研發負責人認為不是缺陷、描述不清、重複、不採納所提意見建議、或者測試人員提錯，從而拒絕的問題。由研發負責人來設置。
4）已解決：研發人員修改問題後所標識的狀態。由研發人員改變。
5）重新打開：測試人員對缺陷狀態為已解決的問題進行驗證後，沒有驗證通過所標誌的狀態；或者已經修改正確的問題，又重新出現錯誤。由測試人員改變。
6）已關閉：測試人員對修改的問題進行驗證後通過所標誌的狀態。由測試人員改變。
7）延後解決：研發負責人確定是缺陷，但該缺陷不在本階段修復或由於外部因素等情況，延後解決。由研發負責人改變。
人員職責劃分
在缺陷生命歷程途中，對缺陷操作人員職責具體要求如下。
測試負責人：
l 定期審核測試人員提交的缺陷。
l 定期對缺陷庫進行分析，描繪出曲線圖等，報告現狀、預測趨勢。
l 對缺陷狀態為已否決、延後解決等可能影響產品質量的問題，需要實時跟蹤並與項目組相關人員確認。
l 在測試總結報告中給出意見。
研發負責人：
l 確認並分配狀態為新建的缺陷，同時確定缺陷優先級、解決的研發人員、填寫計劃修復時間，計劃關閉版本。
l 有否決性質和延後解決性質的缺陷可召集項目組成員（測試負責人、研發負責人、項目/產品經理）會議討論最終狀態。
l 有可能是需求的問題，分配給產品經理。
項目/產品經理：
l 把握缺陷修復的整體情況，確認研發分配的缺陷修改優先級別是否準確。
l 確認已否決和延後解決的缺陷是否合理，如果有意見,可與項目組成員一起商量定奪，確定最終的缺陷優先級和處理意見。
測試人員：
l 發現並提交缺陷，提交測試過程中發現的問題，並按照規範進行編寫缺陷。
l 時時跟蹤自己所提交的缺陷情況，直至關閉。
l 對於缺陷更改等不清楚的問題，與測試負責人及時交流。
研發人員：
l 確認分配給自己的問題並安排時間修復。
l 修復完成後，把缺陷狀態改為已解決，並在註釋中添加缺陷產生原因及解決大概方法。
