需求不明确
测试中遇到需求不明确，文档和原型图的缺失时，应及时联系需求编写人员。（非向开发确认）
需求bug
涉及到需求方面的bug提交给需求经理（如果没有，指给需求编写人员），追踪处理情况。最后根据处理结果，进行测试。如果这期必须处理的，由需求经理下任务给开发，等开发完善后进行测试确认后关闭。如果下期进行修复的，把该bug状态选为“延期处理”，等下期版本测试确认后进行关闭。
开发、UI bug
首先提交到缺陷管理工具（如QC）上，等开发确认bug，如果确认为bug后追踪该bug直到关闭。如果给予否决，应该追问其否决原因，如果确实不为缺陷保留否决状态。如果与开发存在争议的，列出bug清单反馈于测试经理和项目经理予以裁决。
不可复现bug
遇到bug，首要是截图。有图有真相，也是避免遇到灵异缺陷（即复现很难的缺陷）漏报的有效办法。如果不能截图，也应该进行记录。通常做法为，通过描述问题给该模块开发人员进行排查处理，如果不能查到原因，且整个测试阶段结束后都没有再复现该问题，则进行关闭并做好注释。
其他缺陷处理办法
涉及到优化建议、易用性等方面的bug，应该先提交到QC上等待开发处理。处理剩余部分（开发认为存在技术难度、没必要修复的问题）应该与“已否决”状态存在争议的bug一起列成清单由测试经理（测试负责人）发起会议。由测试经理、项目经理和需求经理等共同讨论哪些应该予以修复，哪些不修复，哪些可以延迟修复。
下伦迭代
原则上来说，上轮迭代缺陷都修复和处理后，再进行版本部署进行下轮测试。
上线
经过多伦测试（一般迭代不少于3次）后，缺陷数随着迭代次数而减少，当发现的缺陷数趋近于零时，原则性来说此时不存在严重的功能性问题，比较大的缺陷，剩余的小缺陷数目低于某个值时，此时由测试经理反馈情况给项目经理，项目经理和测试经理共同确定是否予以上线。如果上线存在风险，测试经理具有上线否决权。
bug追踪
首先应该督促开发对BUG进行修复，如果不予以修复的，应该把情况反馈给测试经理和项目经理。 由测试经理（测试负责人）予以协调。
中间衔接问题
项目中间尽量用邮件方式进行沟通。存在风险或重大的里程碑事件应该抄送给项目相关所有负责人员。