由于本公司的業務是日本外包，而外包會遇到2個客戶——發包方和用戶，缺陷管理就變得十分復雜，而且又十分重要重要。
在使用URTracker之前，本公司的缺陷管理相當混亂，并且修改效率低下，無跡可尋。
因此，公司的領導層決定尋找一種合理的管理工具加以管理，經過反復比較選擇，最終選定了URTracker作為本公司的缺陷管理工具，使用將近兩年，效果顯著。
以下詳細介紹一下本公司的URTracker使用方式。
1. 之前的問題
在引入URTracker之前，缺陷是使用excel+email的提交方式——由客戶整理缺陷，統一制成excel，并通過email發送到本公司的項目組進行修改。但是這種方式，會遇到很多問題。
1.1. 時間浪費
使用excel方式的一大問題就是，如果發現一個缺陷就馬上提交的話，不但在收發郵件通知上需要消耗大量工作，而且很難進行跟蹤;而如果聚集一定數量，統一提交的話，就會出現測試集體等待修改或者開發集體等待缺陷的階段性工作時間的浪費。
1.2. 反復嚴重
由于excel的局限，測試無法保證能夠完全準確描述缺陷的信息，開發者無法保證能夠完全準確描述修改方式，缺陷在開發測試之間來回傳遞的現象屢有發生，一直無法根除。
1.3. 交流不便
測試發現一個缺陷，使用excel提交到開發那邊以后，如果有所補充，需要另起一封郵件加以說明，十分不便。
1.4. 難以跟蹤
之前的缺陷，經常出現很多漏改漏測的現象。很多缺陷在測試那邊提交了，而在開發那邊分配修改并幾經轉手，最終修改的缺陷已經遠遠少于之前所提交的缺陷，同樣的情況下，測試也會出現遺漏的現象。
1.5. 記錄保存困難
Excel傳遞過程中，難免出現傳遞錯誤或者遺漏，如果配置管理還出現問題，那么以往的缺陷記錄很容易就會丟失。
1.6. 統計不便
采用excel記錄缺陷，一個項目往往需要很多份表格，如果公司的項目又很多，那對于缺陷的統計，經驗數據的保留，就需要非常巨大的工作量。
2. 流程分類
根據不同開發階段的需要，并且經過不斷完善，我們設計了3種缺陷流程——單元測試流程、系統測試流程、發布后流程。
2.1. 單元測試流程
單元測試流程用于開發組內部測試，由開發人員提交并留檔，過程中需要經過測試經理以及項目經理審核。
2.2. 系統測試流程
由于系統測試基本是由發包方完成，因此在系統測試階段，相對單元測試，需要對缺陷進行公司內部的預驗證。
另外，在配置管理的約束下，對發包方提供的版本必須經過基線化，所以，在系統測試流程中，增加了SCM基線化的環節。
2.3. 發布后流程
由于發布后流程中所包含的缺陷均由用戶或者發包方代替用戶提交，因此，這個流程基本與系統測試流程一樣，需要進行2次確認，不同點是發布后流程需要用戶填寫產品的版本號以便確認。
文章來源于領測軟件測試網 http://www.kjueaiud.com/