一、提交测试后的代码改动导致线上BUG
- 在迭代开发之前，应该更深入了解需求与更仔细的设计技术方案，争取在提测前一次做对。
- 在提测后遇到需要更改的部分时，应该暴露问题，组内进行技术与影响范围评估，如果不必要，则在下次版本优化，必要则邮件提交给测试。
二、测试时间节点不明确
- 测试须在提测前2天提供完整的测试用例。（根据两周一迭代计算）
- 测试须要提测前4天进行测试用例评审。（根据两周一迭代计算）
三、UI评审不及时
- UI须在提测前2天开始评审并在提测前完成评审。
四、提测成果不完整
- 开发在获取测试用例后的2天，进行高优先级测试用例自测和功能模块互测，并将测试缺陷与UI评审缺陷全部修复。
- 开发在提测当天或前一天，在测试面前进行功能演示。
五、BUG修复不及时
- 测试须备注BUG的优先级。
- 无特殊情况，开发须每日根据优先级顺序清空名下BUG，避免阻碍第二天测试工作。
六、沟通不足导致需求缺失、无人认领
- 开发、产品、UI之间的协作须拒绝口头协议，以邮件或wiki的方式抄送存档。
- 测试无须跟踪BUG进度，但是须将BUG指给正确的人，如果不知道，指给对应的开发负责人，由负责人分配。
- BUG相关责任人（无论是直接还是间接），须对问题跟进到完全解决为止。
- 高优先级的问题，与问题相关的所有人讨论解决（开发、测试、BA），讨论结果wiki存档。
- 低优先级的问题，每日晚上汇总，第二天晨会统一提出，站会后拉相关责任人一次解决，提升效率。
七、需求评审不充分导致后期工作指数增加
- 需求评审阶段的结束标志：需求问题清空、技术难题方案调研结束、UI图完整。
- 需求评审阶段达成的共识：UI、测试、开发、BA对需求有充分的了解与有完整的文档输出，后续的更改都需同步文档。
八、文档中UI图与原型不符合问题
- UI在设计图须完全按照原型。
- 在需求评审结束后的一切UI改动，须以增量的方式在wiki更新。
- 如果需要提升效率，可以在给对应的开发提供UI之后，每日晚上更新文档。
九、部分功能的测试步骤复杂
- 开发遇到一些需要管理后台修改数据的操作，可以找相关测试寻求帮助。
- 如果无法操作，须在代码层使用全面的模拟数据进行单元测试。
