由于本公司的业务是日本外包，而外包会遇到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アサイン中） |
其他步骤采用系统自带的标题和内容进行描述。
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上面提出技术疑问，并将这些信息与缺陷库、管理库的信息一同合并到知识库中，成为公司知识积累的平台。
| 
