大型外包企业的缺陷管理

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

日本SE-＞测试经理（受付中）-＞测试（现象确认中）-＞测试经理（受付中）-＞项目经理（PG7寸彳^中）-＞开发（文寸庙中）-＞测试经理（TS7寸彳^中）-＞测试（文寸庙确认中）-＞SCM（八一^三^管理）-＞测试经理（试璇结果报告中）-＞日本SE（受入试璇中）-＞关闭（完了）特殊流程：发生原因流程重复缺陷或者非缺陷测试经理（受付中）-＞日本SE（取消待）-＞关闭（取消）开发与测试意见发生严重分歧测试经理（受付中）-＞SCCB（SCCB决济中）-＞项目经理（PG7寸彳^中）测试经理（受付中）-＞SCCB（SCCB决济中）-＞测试经理（受付中）项目经理（PG7寸彳^中）-＞SCCB（SCCB决济中）-＞测试经理（受付中）项目经理（PG7寸彳^中）-＞SCCB（SCCB决济中）-＞项目经理（PG7寸彳^中）缺陷延时修改项目经理（PG7寸彳^中）-＞项目经理（保留）-＞项目经理（PG7寸彳^中）开发认为非缺陷开发（文寸必中）-＞项目经理（PG7寸彳^中）-＞测试经理（受付中）缺陷内部预测试未通过测试（寸必确认中）-＞项目经理（PG7寸彳^中）缺陷发包方验证未通过测试（受入试璇中）-＞测试经理（试璇结果报告中）-＞项目经理（PG7寸彳^中）字段设计字段名出现位置说明睨明提交缺陷对缺陷的描述再现方法提交缺陷重现缺陷所需的操作步骤种类提交缺陷缺陷类型，包括：缺陷、新需求、需求变更，需求确认修正L太"彳儿开发（寸必中）-＞测试经理（TS7寸彳^中）修改的文件列表文寸圮、方法开发（寸必中）-＞测试经理（TS7寸彳^中）修改的方式其他步骤采用系统自带的标题和内容进行描述。发布后人员与角色在人员配置上，发布后流程与系统测试流程的人员配置完全一样（用户与发包方共用一个群组）。

角色职责项目经理分配缺陷给修改人员验证缺陷修改描述以及逻辑的准确性测试经理验证缺陷描述以及逻辑的准确性分配修改完成之后的验证人员分配发包方的验证人员测试提交缺陷验证缺陷的修改开发修改缺陷SCCB裁决缺陷的处理方式其他包括SQA、部门经理以及技术经理，用于监控项目缺陷状况日本SE提交缺陷验证缺陷的修改并关闭SCM基线化以后处理相关版本的缺陷流程设计基本流程：日本SE-＞测试经理（修正依束真）-＞测试（现象确认中）-＞测试经理（修正依束真）-＞项目经理（现象确认济）-＞开发（修正文寸庙中）-＞测试经理（〒久卜依束的-＞测试（〒久卜夹施）-＞SCM（八一^三^管理）-＞测试经理（试璇结果报告中）-＞日本SE（受入试璇中）-＞关闭（完了）特殊流程：发生原因流程重复缺陷或者非缺陷测试经理（修正依束真）-＞日本SE（取消待）-＞关闭（取消）开发与测试意见发生严重分歧测试经理（修正依束的-＞SCCB（SCCB决济中）-＞项目经理（现象确认济）测试经理（修正依束的-＞SCCB（SCCB决济中）-＞测试经理（修正依柬真）项目经理（现象确认济）-＞SCCB（SCCB决济中）—＞测试经理（修正依束真）项目经理（现象确认济）-＞SCCB（SCCB决济中）—＞项目经理（现象确认济）缺陷延时修改项目经理（现象确认济）-＞项目经理（保留）-＞项目经理（现象确认济）开发认为非缺陷开发（寸必中）-＞项目经理（现象确认济）—＞测试经理（修正依柬真）测试经理发现修改不完整测试经理（〒久卜依束真）-＞项目经理（现象确认济）缺陷内部预测试未通过测试（〒久卜加）-＞项目经理（现象确认济）缺陷发包方验证未通过测试（受入试璇中）-＞测试经理（试璇结果报告中）-＞项目经理（现象确认济）字段设计字段名出现位置说明睨明提交缺陷对缺陷的描述再现方法提交缺陷重现缺陷所需的操作步骤种类提交缺陷缺陷类型，包括：缺陷、新需求、需求变更，需求确认登^番号（奉行）提交缺陷产品版本号（奉行）登^番号（匕“卜2）提交缺陷产品版本号（匕、及卜彳^）登^番号(Addon)提交缺陷产品版本号（Addon）修正L太"彳儿开发（文寸必中）-＞测试经理（〒久卜依束的修改的文件列表文寸圮、方法开发（寸必中）-＞测试经理（〒久卜依束的修改的方式其他步骤采用系统自带的标题和内容进行描述。数据统计产品版本关闭后，对于某个版本中出现的缺陷分布进行统计，并且收集这些数据进行归档。缺陷分布统计缺陷分布统计就是根据模块对各模块缺陷的分布状况进行统计，由此可以推断下一阶段的工作重点，使测试团队能够有针对性的进行测试。缺陷趋势统计缺陷趋势统计是按照时间对缺陷数量进行统计，通过这项统计，测试组可以推断产品目前的质量状况，以及需要进行的测试周期的数量。缺陷原因统计缺陷原因统计是根据项目中缺陷发生原因进行统计，统计