对由本组负责处理的BUG进行管理，通过对BUG的提交、跟踪解释、验证流程进行规范，提高BUG处理效率。
测试团队以及其他团队进行的BUG提交、跟进与解释、验证工作。
-
BUG管理流程
提交BUG要求分类准确、描述简洁、步骤清晰、有实例、复杂问题有据可查（日志或截图）。各部门进行审核，以开发人员的角度来审查提交的BUG，确认测试人员已将BUG描述清楚。具体要求为：
- 一个禅道问题只针对一个Bug。
- 所有BUG必须统一录入禅道系统，不可以口头沟通私下解决。
- 提交BUG前需进行充分测试，尽量排除数据源、网络环境和配置等外部因素，确定提交的BUG是由程序导致的。
- 不允许仅仅用抽象、模糊和主观色彩的词语描述BUG，比如“有错误”、“不太好”、“好像、”“似乎”、“大概之类”。
- 提交人需尽量简洁清晰地描述BUG，描述时应尽可能简洁明了，只解释事实、演示和描述BUG相关的必要细节，避免无关信息。提交人可以写上自己对问题原因的主观分析，但不能和客观描述混杂在一起表述。
- 提交人在提交BUG前，应再次仔细检查报告中是否有可能产生误解的地方。尽量避免使用模糊的、可能产生歧义的主观性词语。
- *产品模块和所属项目：必须填写正确。
- *影响版本：需填写
- *当前指派：指派给对应的研发人员，如果不知道对应的研发人员可以指定给对应的研发负责人，让其分派给具体研发人员。
- *BUG标题：在某种前提下+简述操作过程+最后的结果。如：对会员数据，进行查询，结果无数据显示且无任何提示。
- *重现步骤：【步骤】【结果】【期望】三者写清楚。
- *相关需求：暂时不做要求。
- *相关任务：暂时不做要求。
- *严重程度：BUG级别分为1-4级；
| 严重性 |
Bug等级说明 |
常见现象 |
| 1级 |
无法正常运行，因软件原因导致系统死机、数据丢失等，该级别需要程序员立即修改； |
程序报错无法进行其他业务的运行，引起无响应或者服务器直接宕机等； |
| 功能设计与需求严重不符； | ||
| 数据库发生死锁、数据丢失、数据通讯错误等； | ||
| 2级 |
主要功能丧失，严重影响系统要求或功能的实现，该级别需要程序员尽快修改； |
程序报错但能继续运行； |
| 无法完成功能的正常操作； | ||
| 数据错误； | ||
| 不符合需求定义范围； | ||
| 性能与需求不一致； | ||
| 3级 |
影响系统正常运行，主要功能出现错误，该级别需要程序员修改； |
非常规操作出现错误； |
| 删除操作未给出提示； | ||
| 常规操作未给提示； | ||
| 可编辑区域和只读区域没有区分标志； | ||
| 用户体验较差，操作不方便，但不影响功能实现； | ||
| 数据输入没有边界值限定或不合理； | ||
| 4级 |
操作不合理或者不方便，建议类错误，不影响执行工作功能，对软件的改进意见或建议，该级别问题程序员可时间充足时再修改； |
易用性问题（未给出提示信息或提示信息不统一）； |
| 缺少注释或注释表达不清晰； | ||
| 查询等操作响应时间过长； | ||
| 建议类问题； | ||
| 界面设计不规范，如UI不统一、文字排列不整齐、出现错别字、字体不一致等问题； |
- 附件：对于不易通过文字描述的BUG，提交人应将界面截图作为附件上传；对于崩溃、宕机现象，必须将程序日志作为附件上传。
- 其他内容：都为选填。
在BUG“新建”到“已关闭”期间，尽量使用禅道系统的注释功能进行沟通。
当BUG被以“不必改”、“无法重现”理由关闭，测试人员应仔细阅读研发人员的注释内容，再次检查报告中是否有遗漏和歧义的地方，确认无误后再进行处理。
在问题被研发人员设置为“已解决”后，测试人员应在新版本形成后一周内完成验证或以注释形式说明情况。
- 如果该BUG已解决，则在禅道中关闭问题；
- 如果该BUG仍然出现，则在禅道中反馈问题并说明情况；
- 如果验证过程中发现了新BUG，则在禅道系统中新建问题进行跟踪。