大型外包企業(yè)的缺陷管理

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

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

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