文档介绍：精心整理URTracker缺陷跟踪系统在大型外包企业中的应用编者按:本文档的作者是一家大型软件外包企业的管理人员。该企业在全国服务外包企业50强中排在15位以前。为保护客户隐私,我们在此隐去客户的名称。由于本公司的业务是日本外包,而外包会遇到 2个客户——发包方和用户,缺陷管理就变得十分复杂,而且又十分重要重要。在使用URTracker之前,本公司的缺陷管理相当混乱,并且修改效率低下,无迹可寻。因此,公司的领导层决定寻找一种合理的管理工具加以管理, 经过反复比较选择,最终选定了URTracker作为本公司的缺陷管理工具,使用将近两年,效果显着。以下详细介绍一下本公司的 URTracker使用方式。之前的问题在引入URTracker之前,缺陷是使用excel+email 的提交方式——由客户整理缺陷,统一制成excel,并通过email发送到本公司的项目组进行修改。但是这种方式,会遇到很多问题。时间浪费使用excel方式的一大问题就是,如果发现一个缺陷就马上提交的话,不但在收发邮件通知上需要消耗大量工作,而且很难进行跟踪;而如果聚集一定数量,统一提交的话,就会出现测试集体等待修改或者开发集体等待缺陷的阶段性工作时间的浪费。反复严重由于excel的局限,测试无法保证能够完全准确描述缺陷的信息,开发者无法保证能够完全准确描述修改方式,缺陷在开发测试之间来回传递的现象屡有发生,一直无法根除。交流不便测试发现一个缺陷,使用 excel提交到开发那边以后,如果有所补充,需要另起一封邮件加以说明,十分不便。难以跟踪之前的缺陷,经常出现很多漏改漏测的现象。很多缺陷在测试那边提交了,而在开发那边分配修改并几经转手,最终修改的缺陷已经远远少于之前所提交的缺陷,同样的情况下,测试也会出现遗漏的现象。记录保存困难Excel传递过程中,难免出现传递错误或者遗漏,如果配置管理还出现问题,那么以往的缺陷记录很容易就会丢失。统计不便采用excel记录缺陷,一个项目往往需要很多份表格,如果公司的项目又很多,那对于缺陷的统计,经验数据的保留,就需要非常巨大的工作量。流程分类根据不同开发阶段的需要,并且经过不断完善,我们设计了 3种缺陷流程——单元测试流程、系统测试流程、发布后流程。单元测试流程单元测试流程用于开发组内部测试,由开发人员提交并留档,过程中需要经过测试经理以及项目经理审核。系统测试流程由于系统测试基本是由发包方完成,因此在系统测试阶段,相对单元测试,需要对缺陷进行公司内部的预验证。另外,在配置管理的约束下,对发包方提供的版本必须经过基线化,所以,在系统测试流程中,增加了 SCM基线化的环节。发布后流程由于发布后流程中所包含的缺陷均由用户或者发包方代替用户提交,因此,这个流程基本与系统测试流程一样,需要进行 2次确认,不同点是发布后流程需要用户填写产品的版本号以便确认。流程实现单元测试人员与角色参加单元测试的均为公司内部人员,主要有项目经理、测试经理、开发、测试、SCCB、其他。B裁决缺陷的处理方式其他包括SQA、部门经理以及技术经理,用于监控项目缺陷状况流程设计基本流程:测试->测试经理(受付中)->项目经理(PG ン中)->开发(対応中)->项目经理(対応确认中)->测试经理(试験结果报告中)->测试(受入试験中)->关闭(完了)特殊流程:发生原因流程重复缺陷或者非缺陷测试经理(受付中)->测试(取消待)->关闭(取消)缺陷描述不准确或误测测试经理(受付中)->测试(现象确认中)->测试经理(受付中)开发与测试意见发生严重分歧测试经理(受付中)->SCCB(SCCB决済中)->项目经理(PG ン中)测试经理(受付中)->SCCB(SCCB决済中)->测试经理(受付中)项目经理(PG ン中)->SCCB(SCCB决済中)->测试经理(受付中)项目经理(PG ン中)->SCCB(SCCB决済中)->项目经理(PG ン中)缺陷延时修改项目经理(PG ン中)->项目经理(保留)->项目经理(PG ン中)开发认为非缺陷开发(対応中)->项目经理(PG ン中)->测试经理(受付中)缺陷验证未通过测试(受入试験中)->测试经理(试験结果报告中)->项目经理(PG ン中)字段设计字段名出现位置说明