组织过程定义过程.docx
- 文档编号:11565791
- 上传时间:2023-03-19
- 格式:DOCX
- 页数:13
- 大小:125.47KB
组织过程定义过程.docx
《组织过程定义过程.docx》由会员分享,可在线阅读,更多相关《组织过程定义过程.docx(13页珍藏版)》请在冰豆网上搜索。
组织过程定义过程
缺陷管理流程
版本历史
版本/状态
作者
评审者
起止日期
备注
V0.0.1
唐颖
2016-7-7
文档创建
V0.1.0
唐颖
IT中心全员
2016-7-12
Bug处理流程评审
V0.1.1
朴原植、唐颖
IT中心测试组
2016-8-5
填写规范评审
目录
1引言1
1.1文档用途1
1.2适用范围1
1.3名词术语1
2过程目的1
3角色和职责1
4过程概述2
5说明2
5.1Bug属性3
5.2Bug状态4
5.3填写规则5
5.4QA检查要点6
6附录6
1引言
1.1文档用途
本文档用于Bug管理,包括Bug提出、修正、关闭等过程,用于指导产品、开发、测试等工程师在Bug提出、修正、关闭过程的规范性,保证在整个过程中的一致性,便于互相沟通。
1.2适用范围
本过程适用于公司内部存在Bug管理流程的项目。
1.3名词术语
无。
2角色和职责
角色
职责
产品经理
定义并发布产品的版本;
开发经理
协助分析Bug;
开发工程师
分析并修改Bug,完成后,更新Jira中Bug的信息及状态;
测试工程师
提交Bug;
验证开发人员修复的Bug;
更新Bug的信息;
测试经理
协调人员测试;
QA
负责定期检查项目组人员是否按照流程使用Bug管理系统;
3过程概述
注意:
对于测试组提出的Bug、需求方提出的Bug、以及需求等引起的Bug都适用于本流程。
4说明
4.1Bug属性
说明项
Bug属性
属性说明
包含内容
填写说明
项目
产品线名称
包含当前所有项目,心之家远程门诊、心在线web、心在线wap、心会诊web、心会诊app
选择
问题类型
Bug提交类型
缺陷、改进、新功能
选择
主题
Bug的一句话概述
产品线、模块、日期、描述
填写,【产品线-功能模块-提交日期】文字描述
优先级
表时Bug修改时优先级
严重、紧急、重要、普通、轻微
选择
影响版本
当前测试时的版本号
包含当前项目所有的版本号
根据当前版本填写
模块
不同的项目有不同的模块
选择
经办人
Bug负责人
选择bug对应的负责人
描述
Bug描述
清晰、简要的说明Bug产生的现象、是否可以重现,操作流程等
环境
Bug出现的环境
测试环境、开发环境、预上线环境、线上/生产环境
选择
附件
Bug截图或相关文件说明
上传附件
报告人
发现bug的人
自动
状态
Bug当前状态
详情参见“Bug状态”
选择
解决版本
Bug实际修复版本
开发工程师实际修复Bug后填写
4.2Bug状态
缺陷状态的转换分为“开始、进行中、已处理、关闭、延迟”,下表说明了状态的含义,下图具体说明状态之间的转换关系。
属性值
属性定义的解释
说明
开始
新创建的问题、建议的状态。
提交Bug,状态自动设置为“开始”,其中包括需求方、用户反馈的问题
测试工程师、产品经理、开发人员等式可以提交问题
进行中
问题责任人开始着手解决问题。
点击“开始进行”,状态由“开始”转变成“进行中”
产品、开发
已解决
已经解决或找到处理方案。
与解决结果组合使用。
由问题的经办人处理。
关闭
测试工程师或报告人验证Bug,通过后选择“关闭”。
测试工程师或报告人
重新打开
测试工程师或报告人验证Bug,若不通过或不同意则选择“重新打开”。
延迟
当期不解决,后期版本评估,适时纳入范围
只有产品可以设置
4.3Bug解决结果
下图具体说明解决结果的具体含义。
属性值
属性定义的解释
说明
已解决
问题已经被妥当解决或规避
需要测试或报告人确认
很难重现
1.小概率问题,不好复现,需要测试协助找到有效复现的方式
2.复现条件已经消失,需要等待条件成立
需要测试或报告人确认
重复问题
重复的问题
需要测试确认
外部原因
受第三方影响,需要相关人员关注协助处理
需要综合确认
无需解决
问题责任人认为不是问题,不需要解决
需要产品确认
延后处理
因为技术、时间等多种原因,当期预计无法解决
需要产品确认
设计如此
产品设计逻辑如此
需要产品确认
综述,解决结果为已解决,很难复现,由测试或报告人进行验证,确认;解决结果为重复,由测试判断是否重复;解决结果为延期处理、无需解决、设计如此由产品确认;解决结果为外部原因的时候,说明问题由于第三方原因无法继续,需要团队各角色推动问题解决。
4.4填写规则
团队成员在使用Jira(Bug管理系统)时,当提交Bug、分配Bug、修复、验证时需填写并更新的规范如下,请相关负责人对应如下内容进行更新。
4.4.1提交bug
4.4.1.1Web端、Wap端
模板:
项目:
选择项
问题类型:
选择项(缺陷、改进)
主题:
按“【产品线-功能模块-提交日期】文字描述“规范添写
优先级:
选择项(严重、紧急、重要、普通、轻微)
环境:
选择项(开发环境、测试环境、预上线环境、生产环境)
描述:
【产品线-功能模块-提交日期】文字描述
操作系统:
浏览器:
复现率:
发现者:
联系方式:
@
前置条件:
操作步骤:
预期结果:
实际结果:
备注:
示例:
[心会诊web-会诊病例池-20160707]会诊病例池界面具体病例右边的按钮,ui图画的是“详情”,实际写的是“领取病例”
操作系统:
mac
浏览器:
chrome51.0.2704.103
复现率:
100%
发现者:
tester
联系方式:
test@
测试环境:
线上环境
前置条件:
在心会诊的首页登录了专家账号。
操作步骤:
1.点击右上角“我的会诊”。
2.点击会诊大厅上的“我的大厅”,进入会诊病例池界面
3查看具体一个会诊右边的按键。
预期结果:
ui图上显示按键为“详情”
实际结果:
实际按键为“领取病例”
链接:
备注:
界面截图见附件。
4.4.1.2App端
模板:
项目:
选择项
问题类型:
选择项(缺陷、改进)
主题:
平台-产品线-业务名-提交日期]文字描述
优先级:
选择项(紧急、重要、普通、轻微)
环境:
选择项(开发环境、测试环境、预上线环境、生产环境)
描述:
测试版本:
复现率:
测试机型:
发现者:
联系方式:
@
前置条件:
操作步骤:
预期结果:
实际结果:
备注:
示例:
[安卓-心会诊-医生-20160630]文字沟通时选择电话沟通,拨打的号码不是专家的号码而是医生自己的号码
测试版本:
安卓医生端0630测试环境版本
复现率:
100%
测试机型:
魅族pro6
发现者:
tester
联系方式:
test@
前置条件:
手机安装了心会诊医生端。
已成功登录医生账号。
有一个解决中的文字会诊。
操作步骤:
1.点击进入会诊详情页,点击“电话沟通”
预期结果:
拨打专家电话。
实际结果:
拨打了登录的医生账号自己的电话。
备注:
4.4.1.3操作规范
1.提供辅助信息:
崩溃问题需要提供日志,报错问题提供抓包,界面问题需要提供截图。
当log内容较多或偶现的问题,需在log信息中标注发现问题的时间范围,方便开发寻找。
2.概率问题:
偶然出现的问题要操作10次,用出现问题的次数除以操作次数得出复现概率。
3.前置条件:
涉及特殊测试环境的,须在前置条件中标明。
如,身处环境的改变或手机后台运行某些程序等。
4.操作步骤:
要详细明了。
当问题不易描述或操作复杂时,录制视频来表述该问题。
5.特殊情况:
特殊账号问题同步提供测试账号及密码。
6.产品定义:
软件实现与产品需求或交互有明显不符时,提交问题时应粘贴对应的产品和交互文档截图或文档内容。
对于产品和交互未定义的问题,直接提交给对应的产品经理和交互工程师,并在备注中添加“产品未定义/交互未定义”
7.描述:
复制对应页面的网址链接在问题描述中。
8.环境:
问题发现的环境为必填项,线上环境/生产环境,预上线环境,测试环境。
原则为向下测试,若线上环境有问题,需同步验证预上线环境和测试环境,并标注测试结果;若预上线环境有问题,需同步验证测试环境,并标注测试结果。
9.对比信息:
有些问题需要与其它手机对比确认,将对比机的信息和对比结果在备注中说明
4.4.2验证问题
4.4.2.1Web端、Wap端
模板:
测试时间:
测试浏览器:
验证结果:
示例:
测试时间:
2016.07.08-10:
58
测试浏览器:
chrome51.0.2704.103
验证结果:
不复现
4.4.2.2App端
模板:
测试版本:
测试机型:
验证结果:
示例:
测试版本:
consult-expert-v236-07051636-cs
测试机型:
三星I9508V
验证结果:
不复现
4.4.3解决Bug
问题责任人在解决完问题后,要在备注中写清楚原因、解决方案及是否为临时方案。
模板:
【原因】
【解决方式】
是否是临时解决方案
4.4.4更新Bug调查进展
Bug调查过程中每天需要更新备注内容,以共享调查进展。
模板:
[调查进展]XXXXXXXXXXXXX
[概要原因]XXXXXXXXXXXXX
[调查策略](可选)从XXXXXX方面着手调查
[依赖条件](可选)需要XXXX来支持
4.4.5流转Bug
Bug调查过程中发现不是本组的问题,或需要其他Team继续解决的情况,需要转给其他组调查,需要先与拟转人员进行沟通,然后将确认结论备注到Jira里,并写清楚目前调查的状况,流转原因,提供相关信息,如日志,抓包,断点数据,输入与返回,依据的需求、设计文档(最新)等信息。
多人轮序处理问题,由最后一人进行问题的完整验证。
模板:
【调查进展【(可选)XXXXXXXXXXXXX
【原因】(必选)XXXXXXXXXXXXX
【确认结果】(必选)与XXX沟通,此问题……
4.4.6其它解决结果的备注
4.4.6.1外部原因
1.备注写清楚依赖条件,如依赖大连团队提供XX功能,如需要XX设备;
2.定期更新依赖条件的进展,更新模板参考“更新Bug调查进展“。
4.4.6.2重复
要在备注中写上重复bugID
4.4.6.3很难复现
经办人需要先与bug报告人沟通复现方式,如果还不能复现,经办人备注上操作方式及次数,测试观察。
4.4.6.4延期处理、无需解决
与产品同事及相关人员沟通并达成一致,将确认结果、确认人添写在备注中,转给产品确认。
4.5QA检查要点
定期检查Jira上Bug情况:
●项目全部Bug(内部测试、需求方提出等)需要全部录入到Jira(Bug管理系统)中;
●Bug提出、修改、关闭等的状态是否及时更新;
●Bug提出、修改、关闭的状态是否有版本标识、注释说明等;
●Bug填写是否符合规范;
●Bug处理流程是否符合规范。
5预警机制
蓝色预警:
原则:
以经办人为主,尽可能经办人自己处理完所有问题
1.明确bug解决优先级,确保重点bug优先解决
2.经办人调整任务的优先级,优先解决bug
3.早晨9:
30前经办人检查完名下bug,认为自己解决有困难的bug,向组长提出。
由组长协助,协调解决。
中途如果bug持续增加,要及时向组长报告
4.为了避免加班,组长如果能调整其他人支援,要及时调整
5.最迟每天下午17:
00owner向组长报告问题解决状况,必要时组长协调解决。
6.上述措施都不能降低警报级别的话,Owner需要晚上加班处理bug
原则:
组长要充分参与,对bug数量负主体责任
黄色预警:
原则:
组长要充分参与,对bug数量负主体责任
1.明确bug解决优先级,确保重点bug优先解决
2.组长调整组内任务优先级,优先解决bug
3.组长组织相关人员评审bug,早晨10:
00前向经理报告疑难问题,疑难问题由经理协调解决
4.为避免加班,经理根据组内状况,调整其他组的人员支援
5.组长组织分析近三天新提Bug,根据分析结果,与经理讨论是否要采取进一步措施;
6.最迟下午18:
00由组长汇总bug解决状况,在晚例会上同步,必要时经理协调,协助处理问题
7.上述措施都不能降低报警级别的话,小组成员需要晚上加班处理bug
8.如果2天内Bug数量未得到有效控制,小组成员需要周末加班对应
红色预警:
原则:
经理要充分参与,对bug数量负主体责任
1.明确bug解决优先级,确保重点bug优先解决
2.经理调整任务优先级,优先解决bug
3.设定每日bug解决目标,目标到人,每个bug都设定解决期限
4.经理组织相关人员评审bug,早晨10:
30前向PM报告疑难问题,疑难问题由PM协调解决
5.必要时,经理协调其他组的资源,协助解决bug
6.经理组织分析bug爆发原因,会同PM协商采取进一步措施
7.经理每天19:
30组织核实bug解决情况,同步架构组,必要时采取进一步措施
8.小组及相关支援人员晚上加班处理bug
9.周内bug数量不能得到有效控制的话,周末加班对应
6附录
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 组织 过程 定义