系统测试中，发包方是测试人员，为了与内部测试人员加以区别，在系统测试阶段，加入了新的角色——日本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上面提出技术疑问，并将这些信息与缺陷库、管理库的信息一同合并到知识库中，成为公司知识积累的平台。
文章来源于领测软件测试网 https://www.ltesting.net/
