流程描述：
1、 測試人員發現bug提交給開發。
2、 開發人員判斷是否是bug。
3、 如果是bug，進行修改，修改完成後更改bug狀態爲已解決。
4、 如果不是bug，退回給測試人員並描述退回原因，或爲設計如此，或爲外部原因，或者不能重現。
5、 開發人員修改完成的bug，由測試人員進行驗證，確認修改正確，關閉bug。
6、 驗證未通過的bug重新激活，開發人員繼續修改，直至驗證通過，關閉bug。
7、 測試人員需要對開發人員退回的bug進行確認。
8、 確認不是bug關閉。
9、 如與開發人員意見不一致，認爲是bug，需提交項目負責人仲裁。
10、項目負責人確認是bug由開發人員修改，不是bug由測試人員關閉。
注：除提交項目負責人仲裁環節外，其他環節都可以在禪道上完成。
二、 各角色應關注的狀態
開發人員：激活、重新打開
激活：開發人員要對處於激活狀態的bug進行處理，處理後將其狀態置成“已解決”、“設計如此”、“無法重現”、“外部原因”、“重複bug”或“延期處理”。
重新打開：重新打開的bug是已解決的bug經過測試人員驗證，未修改正確，需要繼續修改。
測試人員：已解決、無法重現、設計如此、外部原因、延期處理
已解決：測試人員發現狀態爲“已解決”的BUG，要及時驗證，如果確實已解決，要將其置爲“關閉”。否則“重新打開”
無法重現：測試人員發現狀態爲“無法重現”的BUG，要及時修改，把步驟描述清楚，並將其狀態置爲“重新打開”。
設計如此：測試人員發現狀態爲“設計如此”和“外部原因”的BUG，要及時通知項目經理，由項目經理來決定是否修改；對“延期處理”的問題要進行定期跟蹤，如發現問題沒有按註釋進行修改要及時通知開發人員或彙報給相關負責人。
項目經理：設計如此、外部原因、延期處理
設計如此：因爲這些BUG都是測試人員和開發人員有爭議的BUG，因此項目經理必須及時關注這些BUG，及時給出合理的定奪，如果不需修改把狀態置成“關閉”，如果需要立刻解決置成“重新打開”，否則置成“以後解決”。同時，項目經理也要關注“延期處理”的BUG，以免其被漏掉或遺忘從而影響到項目上線。
三、 缺陷嚴重級別及類型定義
u 致命錯誤包括：
1． 造成系統崩潰、死機
2． 造成程序非法退出、死循環、通訊中斷或異常
u 嚴重錯誤包括：
功能不符數據流錯誤程序接口錯誤密碼明文顯示
u 一般錯誤包括：
界面錯誤打印內容、格式錯誤輸入限制未放在前臺進行控制刪除操作未給出提示輔助說明描述不清楚顯示格式不規範長時間操作未給用戶進度提示
u 建議（非缺陷）
1． 修改後可獲得更好的用戶體驗
四、 缺陷優先級定義
1、 高：導致測試暫停，無法進行；必須立即解決，優先級高於開發工作。
2、 中：導致部分功能無法測試；需要優先解決，解決週期2天。
3、 低：不影響測試的進行；可在方便時解決，解決週期3-5天。
五、 必須注意的問題
開發人員不能直接關閉bug，關閉bug必須由測試人員完成。在進行問題處理的時候必須要添加註釋，描述不是問題的原因、以後解決的計劃版本時間等等。大家在處理自己的問題時，即使這個問題不是自己的程序引起，也最好不要把問題置之不理，因爲這個問題是在你這塊表現出來的，到底哪裏出問題應該比較清楚，跟其他相關人溝通相對比較容易，這樣可以降低溝通成本，勁量做到“首位責任制”或“問題到此爲止”
項目線上Bug處理流程
