URTracker缺陷跟蹤系统在大型外包企业中的应用.docVIP

URTracker缺陷跟蹤系统在大型外包企业中的应用.doc

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
URTracker缺陷跟蹤系统在大型外包企业中的应用

URTracker缺陷跟踪系统在大型外包企业中的应用 作者: HYPERLINK /member/showmember.aspx?u=leal leal ?? 提交时间: 2009年5月5日 ?? 更新时间: 2009年5月5日 分类: 流程和应用案例 ?? 关键词: ??阅读次数: 864 ? 本文档的作者是一家大型软件外包企业的管理人员。该企业在全国服务外包企业50强中排在15位以前。为保护隐私,我们在此隐去客户的名称。 ? 由于本公司的业务是日本外包,而外包会遇到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アサイ

文档评论(0)

s4as2gs2cI + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档