经验33 使自己的报告具有可读性，即使对象是劳累和暴躁的人

　　经验34 提高报告撰写技能

　　经验35 如果合适，使用市场开发或技术支持数据

　　经验36 相互评审错误报告

　　经验37 与将阅读错误报告的程序员见面

　　经验38 好的方法可能是向程序员演示所发现的程序错误

　　经验39 当程序员说问题已经解决时，要检查是否真的没问题了

　　经验40 尽快检验程序错误修改

　　经验41 如果修改出现问题，应与程序员沟通

　　如果程序错误修改反复失败，或在开发阶段的后期失败，不要仅仅通过错误报告反馈信息并在跟踪系统中归档，而应该直接找程序员。测试员的语气和态度应该友好、热心。要帮助程序员立即得到信息，并准备随时澄清报告中的任何不清楚的地方，如果程序员想看，应准备随时演示程序错误。

　　经验42 错误报告应该由测试员封存

　　经验43 不要坚持要求修改所有程序错误，要量力而行

　　有两个原因导致不能修改所有错误：一是风险，二是客户不愿意为修改付费，定制、合同软件和内部软件开发尤其是这样。如果不能举出某个程序错误很重要的情况，或发现产品项目相关人员足够积极地支持测试员关于推迟特定程序错误修改的请求，我们建议还是把那个程序错误放在一边，先考虑其它问题。

　　经验44 不要让延迟修改的程序错误消失

　　在测试新版本时首先要考虑测试上一版本遗留下来的问题。

　　经验45 测试惰性不能成为程序错误修改推迟的原因

　　如果测试经理因为修改会影响太多的检查单、脚本或其他测试工作制品，因此要占用太多的管理时间而要求程序员不要修改程序错误（编码错误或设计错误），那么说明测试过程存在致命缺陷。

　　经验46 立即对程序错误延迟决定上诉

　　经验47 如果决定据理力争，一定要赢