系統測試中，發包方是測試人員，為了與內部測試人員加以區別，在系統測試階段，加入了新的角色——日本SE。另外，基于配置管理的需要，為發包方提供的版本需要經由SCM基線化以后才能發出，所以，系統測試流程中還加入了另外一個角色——SCM。
|
角色 |
職責 |
| 項目經理 | 分配缺陷給修改人員 |
| 驗證缺陷修改描述以及邏輯的準確性 | |
| 測試經理 | 驗證缺陷描述以及邏輯的準確性 |
| 分配修改完成之后的驗證人員 | |
| 分配發包方的驗證人員 | |
| 測試 | 提交缺陷 |
| 驗證缺陷的修改 | |
| 開發 | 修改缺陷 |
| SCCB | 裁決缺陷的處理方式 |
| 其他 | 包括SQA、部門經理以及技術經理，用于監控項目缺陷狀況 |
| 日本SE | 提交缺陷 |
| 驗證缺陷的修改并關閉 | |
| SCM | 基線化以后處理相關版本的缺陷 |
3.2.2. 流程設計
基本流程：
日本SE->測試經理（受付中）->測試（現象確認中）->測試經理（受付中）->項目經理（PGアサイン中）->開發（対応中）->測試經理（TSアサイン中）->測試（対応確認中）->SCM（バージョン管理）->測試經理（試験結果報告中）->日本SE（受入試験中）->關閉（完了）
特殊流程：
|
發生原因 |
流程 |
| 重復缺陷或者非缺陷 | 測試經理（受付中）->日本SE（取消待）->關閉（取消） |
| 開發與測試意見發生嚴重分歧 | 測試經理（受付中）->SCCB（SCCB決済中）->項目經理（PGアサイン中） |
| 測試經理（受付中）->SCCB（SCCB決済中）->測試經理（受付中） | |
| 項目經理（PGアサイン中）->SCCB（SCCB決済中）->測試經理（受付中） | |
| 項目經理（PGアサイン中）->SCCB（SCCB決済中）->項目經理（PGアサイン中） | |
| 缺陷延時修改 | 項目經理（PGアサイン中）->項目經理（保留）->項目經理（PGアサイン中） |
| 開發認為非缺陷 | 開發（対応中）->項目經理（PGアサイン中）->測試經理（受付中） |
| 缺陷內部預測試未通過 | 測試（対応確認中）->項目經理（PGアサイン中） |
| 缺陷發包方驗證未通過 | 測試（受入試験中）->測試經理（試験結果報告中）->項目經理（PGアサイン中） |
3.2.3. 字段設計
|
字段名 |
出現位置 |
說明 |
| 説明 | 提交缺陷 | 對缺陷的描述 |
| 再現方法 | 提交缺陷 | 重現缺陷所需的操作步驟 |
| 種類 | 提交缺陷 | 缺陷類型，包括：缺陷、新需求、需求變更，需求確認 |
| 修正したファイル | 開發（対応中）->測試經理（TSアサイン中） | 修改的文件列表 |
| 対応方法 | 開發（対応中）->測試經理（TSアサイン中） |
其他步驟采用系統自帶的標題和內容進行描述。
3.3. 發布后
3.3.1. 人員與角色
在人員配置上，發布后流程與系統測試流程的人員配置完全一樣（用戶與發包方共用一個群組）。
|
角色 |
職責 |
| 項目經理 | 分配缺陷給修改人員 |
| 驗證缺陷修改描述以及邏輯的準確性 | |
| 測試經理 | 驗證缺陷描述以及邏輯的準確性 |
| 分配修改完成之后的驗證人員 | |
| 分配發包方的驗證人員 | |
| 測試 | 提交缺陷 |
| 驗證缺陷的修改 | |
| 開發 | 修改缺陷 |
| SCCB | 裁決缺陷的處理方式 |
| 其他 | 包括SQA、部門經理以及技術經理，用于監控項目缺陷狀況 |
| 日本SE | 提交缺陷 |
| 驗證缺陷的修改并關閉 | |
| SCM | 基線化以后處理相關版本的缺陷 |
3.3.2. 流程設計
基本流程：
日本SE->測試經理（修正依頼）->測試（現象確認中）->測試經理（修正依頼）->項目經理（現象確認済）->開發（修正対応中）->測試經理（テスト依頼）->測試（テスト実施）->SCM（バージョン管理）->測試經理（試験結果報告中）->日本SE（受入試験中）->關閉（完了）
特殊流程：
|
發生原因 |
流程 |
| 重復缺陷或者非缺陷 | 測試經理（修正依頼）->日本SE（取消待）->關閉（取消） |
| 開發與測試意見發生嚴重分歧 | 測試經理（修正依頼）->SCCB（SCCB決済中）->項目經理（現象確認済） |
| 測試經理（修正依頼）->SCCB（SCCB決済中）->測試經理（修正依頼） | |
| 項目經理（現象確認済）->SCCB（SCCB決済中）->測試經理（修正依頼） | |
| 項目經理（現象確認済）->SCCB（SCCB決済中）->項目經理（現象確認済） | |
| 缺陷延時修改 | 項目經理（現象確認済）->項目經理（保留）->項目經理（現象確認済） |
| 開發認為非缺陷 | 開發（対応中）->項目經理（現象確認済）->測試經理（修正依頼） |
| 測試經理發現修改不完整 | 測試經理（テスト依頼）->項目經理（現象確認済） |
| 缺陷內部預測試未通過 | 測試（テスト実施）->項目經理（現象確認済） |
| 缺陷發包方驗證未通過 | 測試（受入試験中）->測試經理（試験結果報告中）->項目經理（現象確認済） |
3.3.3. 字段設計
|
字段名 |
出現位置 |
說明 |
| 説明 | 提交缺陷 | 對缺陷的描述 |
| 再現方法 | 提交缺陷 | 重現缺陷所需的操作步驟 |
| 種類 | 提交缺陷 | 缺陷類型，包括：缺陷、新需求、需求變更，需求確認 |
| 登録番號（奉行） | 提交缺陷 | 產品版本號（奉行） |
| 登録番號（ビルトイン） | 提交缺陷 | 產品版本號（ビルトイン） |
| 登録番號（Addon） | 提交缺陷 | 產品版本號（Addon） |
| 修正したファイル | 開發（対応中）->測試經理（テスト依頼） | 修改的文件列表 |
| 対応方法 | 開發（対応中）->測試經理（テスト依頼） | 修改的方式 |
其他步驟采用系統自帶的標題和內容進行描述。
4. 數據統計
產品版本關閉后，對于某個版本中出現的缺陷分布進行統計，并且收集這些數據進行歸檔。
4.1. 缺陷分布統計
缺陷分布統計就是根據模塊對各模塊缺陷的分布狀況進行統計，由此可以推斷下一階段的工作重點，使測試團隊能夠有針對性的進行測試。
4.2. 缺陷趨勢統計
缺陷趨勢統計是按照時間對缺陷數量進行統計，通過這項統計，測試組可以推斷產品目前的質量狀況，以及需要進行的測試周期的數量。
4.3. 缺陷原因統計
缺陷原因統計是根據項目中缺陷發生原因進行統計，統計完成后，能夠推斷項目的工期變化、工期變化原因以及產品缺陷率，并為其他項目提供參考數據。
5. 拓展計劃
5.1. 管理流程
除了缺陷管理，公司正準備加入部分行政管理，客戶管理和營業管理的流程到urtracker中，使之全面成為公司的日常工作平臺。
5.2. 知識庫管理
公司計劃開啟一個咨詢管理平臺，通過流程實現資源互通，通過事務流程管理，讓每一位員工可以在urtracker上面提出技術疑問，并將這些信息與缺陷庫、管理庫的信息一同合并到知識庫中，成為公司知識積累的平臺。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
