一、BUG录入：每天下班前录入当天系统的遗留BUG，格式按照现有格式。
二、BUG的处理和关闭
程序员每天花一定时间进行BUG的修改，修改后标记为“已解决”“已修复”;测试员再次测试“已解决”“已修复”的BUG，根据情况标记为“已关闭”或“活动的”。
三、BUG处理方法：三方会审
◆三方会审结果确定原则：少数服从多数。
◆每天上午上班时或上一天测试人员写入BUG后设计/开发者查看“未批准(未经会审)”的BUG，测试人员查看“已解决”的BUG，如果有问题则标记为“问题”并发起项目管理&设计/开发/测试三方一起会审BUG。
◆如果中午之前没有开会则表示所有人认可昨天新填BUG的正确性和优先级，以及昨天BUG解决的正确性。由项目管理人员将“未批准”的BUG状态修改为“已批准”，测试人员将“已解决”的BUG状态改为“已关闭”。
◆如果任何人对BUG的处理结果不同意(比如测试人员认为没有修复而程序员认为已经修复)，可以随时发起三方会审。结果以三方会审结果为准，所有人必须遵守。
◆每次迭代结束清理BUG时，不能遗留优先级为1，2的BUG。
四、BUG的优先级设定原则如下：
1. 优先级为1的(必须马上修改的)：
◆逻辑(包括业务逻辑)出现错误
◆系统崩溃、死机、无法运行、无法部署、影响其它用户使用的错误页面
◆数据损失、败坏或遗失，破坏文档
◆主要功能无法正常使用、主要功能与设计不符
◆阻碍测试工作的继续进行
◆严重安全问题
2.优先级为2的(应该一周内修改的)：
◆绝大多数的辅助功能问题(包括无法使用和与设计不符等)
◆会给用户造成迷惑的非功能性问题,如提示与事实不符。
◆绝大多数的非控制的页面，如只影响本机使用的错误页面。
3.优先级为3的(有时间就修改的)：
◆偶尔出现的、无法重现的功能性问题
◆这阶段不用修改或没有也可以发行的功能性问题
◆不会给用户造成困惑的界面小问题：错字、错误图标、字体大小、没有对齐、颜色等。
五、标记为“问题”的BUG来源：
◆测试人员填写时自己把有问题的(不能确定的)做标记。
◆测试人员有空时相互检查不属于自己填写的BUG，认为有问题(写得不清楚、错误的BUG等)的做标记。
◆程序员和其它开发相关者认为有问题的做标记。
