由于本公司的业务是日本外包，而外包会遇到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次确认，不同点是发布后流程需要用户填写产品的版本号以便确认。
