bug管理流程

内容来自用户:OPW1124Q8I6yo
BUG处理流程说明一、BUG处理流程图：流程描述：1、测试人员发现bug提交给开发。2、开发人员判断是否是bug。3、如果是bug，进行修改，修改完成后更改bug状态为已解决。4、如果不是bug，退回给测试人员并描述退回原因，或为设计如此，或为外部原因，或者不能重现。5、开发人员修改完成的bug，由测试人员进行验证，确认修改正确，关闭bug。6、验证未通过的bug重新激活，开发人员继续修改，直至验证通过，关闭bug。7、测试人员需要对开发人员退回的bug进行确认。8、确认不是bug关闭。9、如与开发人员意见不一致，认为是bug，需提交项目负责人仲裁。10、项目负责人确认是bug由开发人员修改，不是bug由测试人员关闭。注：除提交项目负责人仲裁环节外，其他环节都可以在禅道上完成。二、各角色应关注的状态1.开发人员：激活、重新打开激活：开发人员要对处于激活状态的bug进行处理，处理后将其状态置成“已解决”、“设计如此”、“无法重现”、“外部原因”、“重复bug”或“延期处理”。重新打开：重新打开的bug是已解决的bug经过测试人员验证，未修改正确，需要继续修改。2.测试人员：已解决、无法重现、设计如此、外部原因、延期处理已解决：测试人员发现状态为“已解决”的BUG，要及时验证，如果确实已解决，要将其置为“关闭”。否则“重新打开”无法重现：测试人员发现状态为“无法重现”的BUG，要及
我们团队用日事清做Bug的管理，建立了严谨的规范。bug管理流程为：测试工程师1. 根据规范提交bug；2. 及时验证bug是否已解决；3. 及时关注开发拒绝bug，和相关人员沟通讨论解决方式；测试经理1. 审核测试工程师提交的bug；2. 定期review bug，报告现状，并给出解决意见；开发工程师1. 以优先级为依据分析解决bug开发主管1. 定期 review bug，对bug多的模块加强code review和单元测试；2. 分析bug解决进度，对产品质量及进度进行风险评估；产品1、当开发和测试存在意见分歧时，进行需求确认2、从产品角度划分bug修改的优先级；对于程序员来说，通过日事清的统计功能，可以清楚手头还有多少bug没解决，多少解决后又重新打开的，有没可能修改引发，bug根源，拒绝修复的原因是什么；对于QA来说，通过日事清做bug管理，通过看板和标签制度，可以每一个bug背后的属性，即测试阶段、bug类型、重现规律、严重级别等。程序猿笑了！