软件经理、项目经理以及用户对负责模块的反映;被开发人员拒绝修改，但用户反馈要修改的缺陷，使用测试工具对测试效率的提高或者对其他测试人员的帮助;
三、 测试小组与开发小组的约定：
1、缺陷的管理;
测试人员与开发人员以TD作为交流的依据，因此必须测试人员与开发人员必须每天浏览TD上的缺陷记录，并根据优先级作为开发员修改的依据：
高缺陷状态为Open后，正常情况应在2个工作天内修改完成;如特殊情况，要在备注中注明原因，但也应在3个工作天内完成;在开发修改完成后，正常情况应在1个工作天内完成;如特殊情况，要在备注中注明原因，但也应在2个工作天内完成;
中缺陷状态为Open后，正常情况应在5个工作天内修改完成;如特殊情况，要在备注中注明原因，但也应在8个工作天内完成;在开发修改完成后，正常情况应在2个工作天内完成;如特殊情况，要在备注中注明原因，但也应在5个工作天内完成;
低缺陷状态为Open后，正常情况应在10个工作天内修改完成;如特殊情况，要在备注中注明原因，但也应在12个工作天内完成;在开发修改完成后，正常情况应在5个工作天内完成;如特殊情况，要在备注中注明原因，但也应在7个工作天内完成;
2、版本的管理：
模块开发初期，两周提交一次版本;
模块开发中期：一周提交一次版本;
模块开发后期：2到3天提交一次版本;
附件三：开发期的界定;
提交版本时必须提供本次版本中实现的需求，复杂操作必须提供简单说明，存在约束的功能必须说明，并确定下次提交版本的时间;
提交版本前，必须确保类文件在VSS上是最新的，已check in 的，类文件必须是编译正常的文件;要明确jar包的目录，要引用的库文件;
数据库脚本需要更新时，必须明确提示，并尽可能提供不清空数据的替代方法;
3、需求变更及其他事项的处理：
当需求规约发生变更时，开发人员应及时用邮件通知相关的测试人员和测试经理，如需求变更多大时，应形成文档提交;
文章来源于领测软件测试网 https://www.ltesting.net/
