URTracker缺陷跟蹤系統在大型外包企業中的應用編者按：本文檔的作者是一家大型軟件外包企業的管理人員。該企業在全國服務外包企業50強中排在15位以前。為保護客戶隱私，我們在此隱去客戶的名稱。由于本公司的業務是日本外包，而外包會遇到2個客戶——發包方和用戶，缺陷管理就變得十分復雜，而且又十分重要重要。在使用URTracker之前，本公司的缺陷管理相當混亂，并且修改效率低下，無跡可尋。因此，公司的領導層決定尋找一種合理的管理工具加以管理，經過反復比較選擇，最終選定了URTracker作為本公司的缺陷管理工具，使用將近兩年，效果顯著。以下詳細介紹一下本公司的URTracker使用方式。之前的問題在引入URTracker之前，缺陷是使用excel+email的提交方式——由客戶整理缺陷，統一制成excel，并通過email發送到本公司的項目組進行修改。但是這種方式，會遇到很多問題。時間浪費使用excel方式的一大問題就是，如果發現一個缺陷就馬上提交的話，不但在收發郵件通知上需要消耗大量工作，而且很難進行跟蹤；而如果聚集一定數量，統一提交的話，就會出現測試集體等待修改或者開發集體等待缺陷的階段性工作時間的浪費。反復嚴重由于excel的局限，測試無法保證能夠完全準確描述缺陷的信息，開發者無法保證能夠完全準確描述修改方式，缺陷在開發測試之間來回傳遞的現象屢有發生，一直無法根除。交流不便測試發現一個缺陷，使用excel提交到開發那邊以后，如果有所補充，需要另起一封郵件加以說明，十分不便。難以跟蹤之前的缺陷，經常出現很多漏改漏測的現象。很多缺陷在測試那邊提交了，而在開發那邊分配修改并幾經轉手，最終修改的缺陷已經遠遠少于之前所提交的缺陷，同樣的情況下，測試也會出現遺漏的現象。記錄保存困難Excel傳遞過程中，難免出現傳遞錯誤或者遺漏，如果配置管理還出現問題，那么以往的缺陷記錄很容易就會丟失。統計不便采用excel記錄缺陷，一個項目往往需要很多份表格，如果公司的項目又很多，那對于缺陷的統計，經驗數據的保留，就需要非常巨大的工作量。流程分類根據不同開發階段的需要，并且經過不斷完善，我們設計了3種缺陷流程——單元測試流程、系統測試流程、發布后流程。單元測試流程單元測試流程用于開發組內部測試，由開發人員提交并留檔，過程中需要經過測試經理以及項目經理審核。系統測試流程由于系統測試基本是由發包方完成，因此在系統測試階段，相對單元測試，需要對缺陷進行公司內部的預驗證。另外，在配置管理的約束下，對發包方提供的版本必須經過基線化，所以，在系統測試流程中，增加了SCM基線化的環節。發布后流程由于發布后流程中所包含的缺陷均由用戶或者發包方代替用戶提交，因此，這個流程基本與系統測試流程一樣，需要進行2次確認，不同點是發布后流程需要用戶填寫產品的版本號以便確認。3.1.單元測試人員與角色參加單元測試的均為公司內部人員，主要有項目經理、測試經理、開發、測試、SCCB、其他。角色職責項目經理分配缺陷給修改人員驗證缺陷修改描述以及邏輯的準確性測試經理驗證缺陷描述以及邏輯的準確性分配修改完成之后的驗證人員測試提交缺陷驗證缺陷的修改并關閉開發修改缺陷SCCB裁決缺陷的處理方式其他包括SQA、部門經理以及技術經理，用于監控項目夬陷狀況流程設計基本流程：測試-＞測試經理（受付中）-＞項目經理（PG7^^^中）-＞開發（對血中）-＞項目經理（對廟確認中）-＞測試經理（試殿結果報告中）-＞測試（受入試殿中）-＞關閉（完了）特殊流程：發生原因流程重復缺陷或者非缺陷測試經理（受付中）-＞測試（取消待）-＞關閉（取消）缺陷描述不準確或誤測測試經理（受付中）-＞測試（現象確認中）-＞測試經理（受付中）開發與測試意見發生嚴重分歧測試經理（受付中）-＞SCCB（SCCB決濟中）-＞項目經理（PG了^^^中）測試經理（受付中）-＞SCCB（SCCB決濟中）—＞測試經理（受付中）項目經理（PG了^^^中）-＞SCCB（SCCB決濟中）-＞測試經理（受付中）項目經理（PG了^^^中）-＞SCCB（SCCB決濟中）-＞項目經理（PG了^^^中）缺陷延時修改項目經理（PG7^^^中）-＞項目經理（保留）-＞項目經理（PG了^^^中）開發認為非缺陷開發（對血中）-＞項目經理（PG7^^^中）-＞測試經理（受付中）缺陷驗證未通過測試（受入試璇中）-＞測試經理（試璇結果報告中）-＞項目經理（PG7寸彳^中）字段設計字段名出現位置說明睨明提交缺陷對缺陷的描述再現方法提交缺陷重現缺陷所需的操作步驟種類提交缺陷缺陷類型，包括：缺陷、新需求、需求變更，需求確認修正L太"彳兒開發（文寸廟中）-＞項目經理（文寸必確認中）修改的文件列表文寸圮、方法開發（寸廟中）-＞項目經理（寸廟確認中）修改的方式其他步驟采用系統自帶的標題和內容進行描述。系統測試人員與角色系統測試中，發包方是測試人員，為了與內部測試人員加以區別，在系統測試階段，加入了新的角色一一日本SE。另外，基于配置管理的需要，為發包方提供的版本需要經由SCM基線化以后才能發出，所以，系統測試流程中還加入了另外一個角色—一SCM。角色職責項目經理分配缺陷給修改人員驗證缺陷修改描述以及邏輯的準確性測試經理驗證缺陷描述以及邏輯的準確性分配修改完成之后的驗證人員分配發包方的驗證人員測試提交缺陷驗證缺陷的修改開發修改缺陷SCCB裁決缺陷的處理方式其他包括SQA、部門經理以及技術經理，用于監控項目缺陷狀況日本SE提交缺陷驗證缺陷的修改并關閉SCM基線化以后處理相關版本的缺陷流程設計基本流程：

日本SE-＞測試經理（受付中）-＞測試（現象確認中）-＞測試經理（受付中）-＞項目經理（PG7寸彳^中）-＞開發（文寸廟中）-＞測試經理（TS7寸彳^中）-＞測試（文寸廟確認中）-＞SCM（八一^三^管理）-＞測試經理（試璇結果報告中）-＞日本SE（受入試璇中）-＞關閉（完了）特殊流程：發生原因流程重復缺陷或者非缺陷測試經理（受付中）-＞日本SE（取消待）-＞關閉（取消）開發與測試意見發生嚴重分歧測試經理（受付中）-＞SCCB（SCCB決濟中）-＞項目經理（PG7寸彳^中）測試經理（受付中）-＞SCCB（SCCB決濟中）-＞測試經理（受付中）項目經理（PG7寸彳^中）-＞SCCB（SCCB決濟中）-＞測試經理（受付中）項目經理（PG7寸彳^中）-＞SCCB（SCCB決濟中）-＞項目經理（PG7寸彳^中）缺陷延時修改項目經理（PG7寸彳^中）-＞項目經理（保留）-＞項目經理（PG7寸彳^中）開發認為非缺陷開發（文寸必中）-＞項目經理（PG7寸彳^中）-＞測試經理（受付中）缺陷內部預測試未通過測試（寸必確認中）-＞項目經理（PG7寸彳^中）缺陷發包方驗證未通過測試（受入試璇中）-＞測試經理（試璇結果報告中）-＞項目經理（PG7寸彳^中）字段設計字段名出現位置說明睨明提交缺陷對缺陷的描述再現方法提交缺陷重現缺陷所需的操作步驟種類提交缺陷缺陷類型，包括：缺陷、新需求、需求變更，需求確認修正L太"彳兒開發（寸必中）-＞測試經理（TS7寸彳^中）修改的文件列表文寸圮、方法開發（寸必中）-＞測試經理（TS7寸彳^中）修改的方式其他步驟采用系統自帶的標題和內容進行描述。發布后人員與角色在人員配置上，發布后流程與系統測試流程的人員配置完全一樣（用戶與發包方共用一個群組）。

角色職責項目經理分配缺陷給修改人員驗證缺陷修改描述以及邏輯的準確性測試經理驗證缺陷描述以及邏輯的準確性分配修改完成之后的驗證人員分配發包方的驗證人員測試提交缺陷驗證缺陷的修改開發修改缺陷SCCB裁決缺陷的處理方式其他包括SQA、部門經理以及技術經理，用于監控項目缺陷狀況日本SE提交缺陷驗證缺陷的修改并關閉SCM基線化以后處理相關版本的缺陷流程設計基本流程：日本SE-＞測試經理（修正依束真）-＞測試（現象確認中）-＞測試經理（修正依束真）-＞項目經理（現象確認濟）-＞開發（修正文寸廟中）-＞測試經理（〒久卜依束的-＞測試（〒久卜夾施）-＞SCM（八一^三^管理）-＞測試經理（試璇結果報告中）-＞日本SE（受入試璇中）-＞關閉（完了）特殊流程：發生原因流程重復缺陷或者非缺陷測試經理（修正依束真）-＞日本SE（取消待）-＞關閉（取消）開發與測試意見發生嚴重分歧測試經理（修正依束的-＞SCCB（SCCB決濟中）-＞項目經理（現象確認濟）測試經理（修正依束的-＞SCCB（SCCB決濟中）-＞測試經理（修正依柬真）項目經理（現象確認濟）-＞SCCB（SCCB決濟中）—＞測試經理（修正依束真）項目經理（現象確認濟）-＞SCCB（SCCB決濟中）—＞項目經理（現象確認濟）缺陷延時修改項目經理（現象確認濟）-＞項目經理（保留）-＞項目經理（現象確認濟）開發認為非缺陷開發（寸必中）-＞項目經理（現象確認濟）—＞測試經理（修正依柬真）測試經理發現修改不完整測試經理（〒久卜依束真）-＞項目經理（現象確認濟）缺陷內部預測試未通過測試（〒久卜加）-＞項目經理（現象確認濟）缺陷發包方驗證未通過測試（受入試璇中）-＞測試經理（試璇結果報告中）-＞項目經理（現象確認濟）字段設計字段名出現位置說明睨明提交缺陷對缺陷的描述再現方法提交缺陷重現缺陷所需的操作步驟種類提交缺陷缺陷類型，包括：缺陷、新需求、需求變更，需求確認登^番號（奉行）提交缺陷產品版本號（奉行）登^番號（匕“卜2）提交缺陷產品版本號（匕、及卜彳^）登^番號(Addon)提交缺陷產品版本號（Addon）修正L太"彳兒開發（文寸必中）-＞測試經理（〒久卜依束的修改的文件列表文寸圮、方法開發（寸必中）-＞測試經理（〒久卜依束的修改的方式其他步驟采用系統自帶的標題和內容進行描述。數據統計產品版本關閉后，對于某個版本中出現的缺陷分布進行統計，并且收集這些數據進行歸檔。缺陷分布統計缺陷分布統計就是根據模塊對各模塊缺陷的分布狀況進行統計，由此可以推斷下一階段的工作重點，使測試團隊能夠有針對性的進行測試。缺陷趨勢統計缺陷趨勢統計是按照時間對缺陷數量進行統計，通過這項統計，測試組可以推斷產品目前的質量狀況，以及需要進行的測試周期的數量。缺陷原因統計缺陷原因統計是根據項目中缺陷發生原因進行統計，統計