在盡量不影響當前項目活動的情況下，可以對測試過程作部分改進，能夠支持建立項目的BUG管理過程，簡述如下：
1.配置角色和權限->新建角色：測試人員
(1)主要配置問題跟蹤權限
(2)提前規划好再在系統中操作，建議不要賦予角色刪除權限，刪除應由項目管理人員操作
2.配置跟蹤標簽->錯誤
(1)保留錯誤的基本屬性：狀態(在工作流程中可以自定義)、指派給、目標版本(如果項目有版本規划)、計划完成日期(測試人員根據任務進度預計修復完成日期，負責修復的開發人員也可以根據任務實際進度修改)
(2)自定義屬性：
錯誤類型
- 需求錯誤
- 功能錯誤(影響了重要的特性、用戶界面、產品接口、硬件結構接口和全局數據結構。並且設計文檔需要正式的變更。如邏輯，指針，循環，遞歸，功能等缺陷)
- 接口錯誤(與其他組件、模塊或設備驅動程序、調用參數、控制塊或參數列表相互影響的缺陷)
- 用戶界面錯誤(屏幕格式，確認用戶輸入，功能有效性，頁面排版等方面的缺陷)
- 提示錯誤(提示的錯誤信息，不適當的數據驗證等缺陷)
- 版本錯誤(由於配置庫、變更管理或版本控制引起的錯誤)
- 性能錯誤(頁面呈現時間過慢))
BUG嚴重等級
- 致命(致命的錯誤，造成系統崩潰、死機，或造成數據丟失、主要功能完全喪失、頁面報錯等)
- 嚴重(指功能模塊或特性沒有實現，主要功能部分喪失，次要功能全部喪失，或致命的錯誤聲明)
- 一般(次要功能模塊喪失、提示信息不夠准確、用戶界面顯示不合理和操作時間長等)
- 細微(一些小問題如有個別錯別字、文字排版不整齊等，不符合操作習慣)
3.配置工作流程->字段權限
(1)角色-開發人員、跟蹤標簽-錯誤：除"指派給"全部設為只讀(配置工作流程->狀態轉換可以根據需要自定義，比如開發人員只能將新建置為已解決或者已關閉)
4.規范測試人員提交BUG過程
(1)主題：【XX模塊】-BUG概述
(2)描述：
測試環境(后續可以根據需要自定義字段-測試環境)
前置條件，比如用戶已登錄
操作步驟
預期結果
實際結果
其他說明
(3)父任務：需求任務
(4)文件：BUG截圖
5.相關影響：
(1)開發人員需要關注被指派的問題，並填寫修復說明，開始可能會遭到部分抵觸
(2)測試人員也有可能產生不適應，而且BUG后期是要與測試人員的考核(激勵為主)結合起來的，不然可能出現有問題不記錄，或者記錄得過於簡單
6.小結：
建議先對測試人員宣講，收集反饋意見，然后在下一個周期較長的需求試行