软件测试的目的是尽可能发现并改正被测试软件中的错误，提高软件的可靠性。然而，测试人员发现的缺陷有可能被开发人员有意无意的忽视，如何推动缺陷的修改，是测试人员面对的一项极有意义的工作。那么如何推动开发修改缺陷呢？我们建议：

　　一、扭转研发部领导的思想，提高研发人员的响应速度

　　1. 推动研发领导对测试的认知度，让他们从制度上推动问题的解决。

　　很多研发团队的领导都是销售出生，懂技术的很少，他们和搞技术的想法明显不一样。通过测试培训或讲座的形式，邀请研发团队的领导来旁听，既能搞好部门见的关系，又能推动研发领导的认知，何乐而不为？

　　2. 采用常用的缺陷管理工具，提高缺陷的透明度：

　　使用缺陷管理工具来进行软件日常的管理，测试经理任管理员、公司高层领导、项目经理、开发经理都分配了权限，自己可以登录系统查询相关信息。在测试后期，特别是要发布版本前后，领导们一有空，也随时上去浏览一把，无意识给开发人员施加了较大的压力。如果这个时候还有很多Open的缺陷，开发人员自然不敢怠慢。

　　二、以制度的形式规范测试规范

　　1. 关键是建立一个完善的研发机制：

　　在大多数情况下，是不是软件缺陷或者需不需要修改，怎样修改不是测试人员和开发人员说了算的，应该是靠研发部门的相关制度或相关部门去约束。

　　2. 分清团队成员的具体责任：

　　对于研发团队中的每个成员，必须责任明确，否则像督促缺陷修改这样的事情本来不是测试人员的责任，现在都推到测试人员头上了。很郁闷！！

　　3. 完善测试规范，明确Bug管理制度。

　　4. 把开发人员的修改缺陷的响应速度，记入绩效考核内容：

　　请求领导支持，从制度上把缺陷的修改响应速度作为绩效考核的内容，从根本上约束开发人员。

　　三、测试人员从源头上杜绝无效缺陷的递交

　　1. 测试前细化测试需求，避免递交歧义缺陷：

　　很多研发不愿意修改的缺陷，大部分都是由于需求不明确或者理解歧义引起的。尽量减少提交因理解上的歧义而提交的有争议的缺陷。

　　2. 清楚无歧义的描述Bug，减少随机测试，带来不可重现的Bug：

　　四、正确分析测试中的软件缺陷

　　1. 为递交的每个缺陷准备几条充足的理由：

　　2. 详细分析缺陷给项目带来的各种可能影响或缺陷风险：

　　比如说，我们递交一个缺陷，如果研发的觉的这个缺陷可以修改或可以不修改时。我们一定要给研发分析修改这个缺陷的必要性，不修改，对客户带来哪种可能影响或存在哪些风险。

　　五、做一个聪明的测试工程师

　　1. 注意和研发人员的沟通技巧：

　　谈话时，要注意沟通技巧，要有换位思维的方式，做事情对事不对人，处理事情一定要有一颗宽容的心。只有这样，才能够很好的说服研发去修改Bug。

　　2. 和研发人员搞好私人关系，做研发的听众：

　　比较明智的测试人员，一定要学会倾听研发人员的心声。很多时候，开发人员碰到工作困难的时候，很希望和人倾述，如果测试人员是他的听众，那么你们的关系一定会不错。如果私人关系好了，说服研发修改Bug是很容易的事情。