大型外包企业的缺陷管理.docx
- 文档编号:26521077
- 上传时间:2023-06-20
- 格式:DOCX
- 页数:15
- 大小:140.59KB
大型外包企业的缺陷管理.docx
《大型外包企业的缺陷管理.docx》由会员分享,可在线阅读,更多相关《大型外包企业的缺陷管理.docx(15页珍藏版)》请在冰豆网上搜索。
大型外包企业的缺陷管理
大型外包企业的缺陷管理
在大型外包企业中的应用
编者按:
本文档的作者是一家大型软件外包企业的治理人员。
该企业在全国服务外包企业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アサイン中〕->项目经理〔保留〕->项目经理〔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上面提出技术疑问,并将这些信息与缺陷库、治理库的信息一同合并到知识库中,成为公司知识积存的平台。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 大型 外包 企业 缺陷 管理