由于本公司的业务是日本外包，而外包会遇到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次确认，不同点是发布后流程需要用户填写产品的版本号以便确认。
3. 流程实现
3.1. 单元测试
3.1.1. 人员与角色
参加单元测试的均为公司内部人员，主要有项目经理、测试经理、开发、测试、SCCB、其他。
|
角色 |
职责 |
| 项目经理 | 分配缺陷给修改人员 |
| 验证缺陷修改描述以及逻辑的准确性 | |
| 测试经理 | 验证缺陷描述以及逻辑的准确性 |
| 分配修改完成之后的验证人员 | |
|
测试 |
提交缺陷 |
| 验证缺陷的修改并关闭 | |
| 开发 | 修改缺陷 |
| SCCB | 裁决缺陷的处理方式 |
| 其他 | 包括SQA、部门经理以及技术经理，用于监控项目缺陷状况 |
3.1.2. 流程设计
基本流程：
测试->测试经理（受付中）->项目经理（PGアサイン中）->开发（対応中）->项目经理（対応確認中）->测试经理（試験結果報告中）->测试（受入試験中）->关闭（完了）
特殊流程：
|
发生原因 |
流程 |
| 重复缺陷或者非缺陷 | 测试经理（受付中）->测试（取消待）->关闭（取消） |
| 缺陷描述不准确或误测 | 测试经理（受付中）->测试（現象確認中）->测试经理（受付中） |
| 开发与测试意见发生严重分歧 | 测试经理（受付中）->SCCB（SCCB決済中）->项目经理（PGアサイン中） |
| 测试经理（受付中）->SCCB（SCCB決済中）->测试经理（受付中） | |
| 项目经理（PGアサイン中）->SCCB（SCCB決済中）->测试经理（受付中） | |
| 项目经理（PGアサイン中）->SCCB（SCCB決済中）->项目经理（PGアサイン中） | |
| 缺陷延时修改 | 项目经理（PGアサイン中）->项目经理（保留）->项目经理（PGアサイン中） |
| 开发认为非缺陷 | 开发（対応中）->项目经理（PGアサイン中）->测试经理（受付中） |
| 缺陷验证未通过 | 测试（受入試験中）->测试经理（試験結果報告中）->项目经理（PGアサイン中） |
3.1.3. 字段设计
|
字段名 |
出现位置 |
说明 |
| 説明 | 提交缺陷 | 对缺陷的描述 |
| 再現方法 | 提交缺陷 | 重现缺陷所需的操作步骤 |
| 種類 | 提交缺陷 | 缺陷类型，包括：缺陷、新需求、需求变更，需求确认 |
| 修正したファイル | 开发（対応中）->项目经理（対応確認中） | 修改的文件列表 |
| 対応方法 | 开发（対応中）->项目经理（対応確認中） | 修改的方式 |
其他步骤采用系统自带的标题和内容进行描述。
3.2. 系统测试
3.2.1. 人员与角色
系统测试中，发包方是测试人员，为了与内部测试人员加以区别，在系统测试阶段，加入了新的角色——日本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アサイン中） | 修改的方式 |
其他步骤采用系统自带的标题和内容进行描述。