產品問題缺陷庫是研發系統最核心的一個IT系統，所有的測試執行過程都是基於這個系統進行的。問題單庫是一個電子流，由測試人員提交，由開發人員定位解決，最後再由測試人員迴歸測試後關閉。在這個過程中，測試經理、開發經理負責審覈。每個環節中相關的責任人都要填入必要的信息，以保證下一環節的人員能夠順利處理。
問題單基本流程
以下是一個最常見的問題單處理流程：
1.測試人員在測試過程中發現缺陷，提交問題單
說明：測試人員要輸入缺陷所在版本號，缺陷描述，缺陷嚴重程度，導致缺陷出現的操作方法，問題出現時的界面截圖，問題是否可重現（或隨機重現），問題所在模塊。詳細的缺陷描述有助於開發人員精確的定位問題原因所在。其他的信息用於統計並評估版本質量。
2.測試經理審覈問題單
說明：測試經理進行審覈，判斷問題是否合理有效、是否重複，測試人員填寫的信息是否規範、清晰等。
3.開發經理審覈問題單
說明：開發經理從開發的角度審覈問題的有效性和規範性，並指派適當的開發人員進行定位。
4.開發人員定位問題原因
說明：這個階段主要是定位問題原因，但不修改（至少在流程上沒有體現出來），因爲找到的問題原因是否合理需要有開發經理審覈。也許一個問題可以有兩種修改的方法，開發人員和開發經理可能有不同的看法，這時候不應該倉促着手修改。
5.開發經理審覈問題定位的正確性
說明：同上
6.開發人員實施修改
說明：開發人員應該把修改的代碼作爲附件貼在電子流上，或者如果是採用ClearCase配置庫，開發人員應該在配置庫上創建以問題單號命名的分支，並在電子流中知會管理員。不管哪種方式，開發人員還應該將問題單號、描述、修改方法和修改文件列表按指定的格式填寫清楚。因爲配置管理員在合入問題的時候，需要將這些描述作爲備註加入，以便後續的追溯。
7.配置管理員合入問題單
說明：這個環節不完全是一個機械性的動作。多個開發人員有可能同時修改一個文件併產生衝突，這需要配置管理員來判斷和解決。根據版本發佈計劃，不一定所有的問題都在同一個版本中合入，配置管理員也會做一定的控制。
8.新版本發佈時開發人員驗證問題單修改情況
說明：新版本發佈時，開發組進行內部驗證，開發人員需要驗證問題是否已經解決，因爲多個環節的配合可能出現偏差，可能的原因有：代碼修改錯誤、CMO忘記合入、代碼衝突、版本製作出錯。
9.測試經理接收修改後的問題單
說明：這個環節中，測試經理指派適當的測試人員進行迴歸測試。
10.測試人員執行迴歸測試後歸檔問題單
說明：迴歸測試，如果不通過，會將問題單打回開發人員重新修改。迴歸測試不通過是很嚴重的問題。
11.問題單歸檔
說明：問題單解決以後不會被簡單刪除，而是被歸檔起來，作爲後續重複問題等的參考。有些問題作爲已知缺陷或者無效問題不被解決，也是需要被歸檔下來，可供日後有爭議的時候參考。
爭議問題單裁決
另外一個重要的問題單處理流程是爭議問題單裁決。如果開發經理認爲測試人員提交的問題單無效，可以將問題單提交給變更控制委員會（CCB）進行裁決。變更裁決委員會由系統工程師、開發經理、測試經理等組成，組長是系統工程師。在充分討論以後，組長如果裁決該問題單爲無效，可以在電子流上給出結論，並將問題單歸檔。
問題單複製
還有一個流程是問題單的複製。對於需要跨團隊解決的問題單，開發經理在保留本問題單庫中問題單的同時，將問題單複製給其他團隊，只有其他團隊解決了問題單，本問題單庫的問題單才能被關閉。
問題單統計
通過從電子流上導出統計信息或報表，開發和測試團隊可以 評估每個版本的質量，如產生多少問題單、這些問題單的嚴重程度（致命、嚴重、一般、提示），當然，問題單是否可重現也是評估的一個要素。對於幾個連續版本，問題單的收斂趨勢理論上應該符合一定的經驗規律。如果前兩個版本問題單很多，第三個版本突然大幅度下降，管理人員有理由懷疑中間是否存在貓膩，開發經理是否和測試經理達成私下妥協。如果之前的版本問題單很少，後面沒有合入重要修改但問題單數量卻飆升，是否是測試組之前測試不充分？或者開發組出了什麼問題？