大型外包企业的缺陷管理Word文档格式.docx
- 文档编号:7266580
- 上传时间:2023-05-08
- 格式:DOCX
- 页数:15
- 大小:140.32KB
大型外包企业的缺陷管理Word文档格式.docx
《大型外包企业的缺陷管理Word文档格式.docx》由会员分享,可在线阅读,更多相关《大型外包企业的缺陷管理Word文档格式.docx(15页珍藏版)》请在冰点文库上搜索。
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アサイン中)
缺陷延时修改
项目经理(保留)->
开发认为非缺陷
缺陷验证未通过
3.1.3.字段设计
字段名
出现位置
说明
説明
对缺陷的描述
再現方法
重现缺陷所需的操作步骤
種類
缺陷类型,包括:
缺陷、新需求、需求变更,需求确认
修正したファイル
项目经理(対応確認中)
修改的文件列表
対応方法
修改的方式
其他步骤采用系统自带的标题和内容进行描述。
3.2.系统测试
3.2.1.人员与角色
系统测试中,发包方是测试人员,为了与内部测试人员加以区别,在系统测试阶段,加入了新的角色——日本SE。
另外,基于配置管理的需要,为发包方提供的版本需要经由SCM基线化以后才能发出,所以,系统测试流程中还加入了另外一个角色——SCM。
分配发包方的验证人员
验证缺陷的修改
日本SE
SCM
基线化以后处理相关版本的缺陷
3.2.2.流程设计
日本SE->
测试经理(TSアサイン中)->
测试(対応確認中)->
SCM(バージョン管理)->
日本SE(受入試験中)->
日本SE(取消待)->
缺陷内部预测试未通过
缺陷发包方验证未通过
3.2.3.字段设计
测试经理(TSアサイン中)
3.3.发布后
3.3.1.人员与角色
在人员配置上,发布后流程与系统测试流程的人员配置完全一样(用户与发包方共用一个群组)。
3.3.2.流程设计
测试经理(修正依頼)->
项目经理(現象確認済)->
开发(修正対応中)->
测试经理(テスト依頼)->
测试(テスト実施)->
项目经理(現象確認済)
测试经理(修正依頼)
测试经理发现修改不完整
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文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 大型 外包 企业 缺陷 管理
![提示](https://static.bingdoc.com/images/bang_tan.gif)