公认待CCB
是否修复
不能
能
确认bug
组内评审会
重新打开
1..bug需要符合提交标准，标题清晰明确，描述步骤清晰。2.严重等级、概率性、发现bug版本、模块、环境信息、bug原因分析、测试类型等字段需填写。
阶段
新建
Bug评审
新建bug
结束
1.“bug评审会”上讨论的待公认bug，SE需要准备好公认理由及后续修改方案。
1.bug预期修复时间默认时间规定：严重及以上预期4天修复，次要及以下预期修复2天修复。
测试人员
已修复
确认
bug评审会同意公认后，状态修改为“公认待CCB”，待项目结束前组织CCB成员进行评审
相关规程
组内评审
1.重新打开bug来源：回归失败、申请公认bug未通过评审、有争议bug确认为bug的。
有争议
公认待SE审核
延迟修改
开发人员
有争议bug，需要在摘要中写明争议点
每周一、四进行bug预警，对超过预期修复时间的同事进行统计，每月超过四次记黑事件
由SE组织PO/研发/测试组织模块内bug方案评审会，每周两次。议题包括：1.延迟修改bug修复方案及确定预期修复时间2.里程碑版本修复不了的，申请公认，准备公认理由及后续修复方案。3.跟踪复现bug的复现方法讨论。
1.如修改时间超过预期修复时间，需修改状态为“延迟修改”，修改预期修复时间；2.此过程需SE/PO参与，确定修改方案。
评审
SE/PO
回归
修复回归
1.修复bug需添加备注注明“原因分析”“修改措施”“影响范围”2.回归bug后测试人员需添加回归情况
关闭
