测试人员如何说服他人认可你提交的缺陷？（08-03-28）（获奖名单已公布）

51testing

" 每周一问"问题征集

        作为一个测试人员经常会遇到程序员或者设计人员拒绝修改你提交缺陷的情况，但是往往到最后这个缺陷会被用户提出，不得已再进行修改，给个人和公司带来一定的负面效果，那么如何说服他人认可你提交的缺陷是需要修改的？欢迎大家各抒己见！

非常感谢各位会员积极参与，截止至4月7日１2：00分，从该贴所有评论中选出部分作出精彩评论的会员予以奖励。礼品和积分将在下周内送出。

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	cityyard	当当购物卡50元	10#
二等奖	walker1020	300论坛积分	4#
	duola1119		45#
三等奖	xixihahahu	100论坛积分	6#
	土土的豆豆		39#
	贝贝酷		63#

badguy

首先，公司会有一套完整的公认的关于缺陷严重级别定义
按对缺陷特点、用户操作影响、模块重要性等来区别，这样，测试人员根据该定义提交不同等级的bug单。而公司对产品的发布会有一定的原则，对不同等级的bug单处理情况，比如严重的缺陷必须修改，建议可保留到下个版本等...
如果遇到开发人员不合作，测试可根据公司定义的缺陷严重级别来说明该bug符合哪一项，为什么属于该类bug，为什么需要修改等。引导开发人员站在用户的角度，更高的要求产品质量
另外，测试人员应该不断补充自己的知识，学习业务架构。对bug的分析要到位，不能总是被开发牵着鼻子走。如果能指出是哪里编码的错误，就修改一下哪里就ok了，相信开发一定会更容易合作。不断的加强自身能力，来树立自己的威信和影响力，这样开发也无法来用各种理由来搪塞，你的建议也更容易被采纳，版本的质量就更在你的掌控之中！

wjb-test

有以下几点：
1.建立完整的软件缺陷规范，明确指出哪些是必须修改的以及轻重缓急
2.将心比心，我们要站在开发者的角度去考虑问题，然后再和开发者交流
3.学习说话的技巧，同样的话在不同的情况下有不同的效果
4.努力提高自身能力，给别人增加信任感

sinakevin

简单的说：
1、和开发有个好的关系，有一点BUG他们可能就会帮你修的
2、证据，需求方面的证据

其他同志，多补充

jinpeng99

学习了

rting

最主要的是要把bug描述清楚，因为这个bug会导致什么问题
采用这样的句式很有效：“由于什么什么操作，会导致什么什么样的问题，或者引起什么后果”

red-hat

这么多获奖的啊!!哈哈,羡慕

yang313172

我是个新人，个人认为要从几个方面入手
首先，测试人员提的bug要有一定的说服力，和需求文档是一致的［因为整个软件的开发都是围绕需求来做的，需求是测试和开发的衡量的重要标准］；
其次，测试人员要和开发人员很好的沟通，良好的人际关系也是促进工作的催化剂；
再次，测试人员要和开发人员的角度站在一起，大家的目的都是为了能更好的完善软件，使软件被发布给客户使用，得到的答案是满意的结果；

hanyancui28

1.我们先确认这个BUG是不是真正的BUG。因为只有自己明白，我们所坚持的是正确的，才能理直气壮的去表达自己的观点。
2.要实事求是，不能针对某个人。我们在表达自己的时候，要从客观的角度出发，不能针对某个人来讲这个BUG，因为，一个BUG的产生，很可能是由各方面的  因素造成的。
3.注重交流，尊重他人。当其他人对我们提出的BUG有不同的看法时，我们首先要认真的听别人的讲述，不能一味的认为，只有自己是对的，当虽人讲完后，再对那人所提出的问题，进行讲解。
4.坚持自己的观点。既然我们认定这是个必改的BUG，我们就要有自己的坚持，用证据来证明自己的说法，正所谓“有理走遍天下”，不能因为对方是资深开发人员，或是自己的上级，就改变自己的看法。

jaling

看了下大家的回答，都很不错！
下面我就个人的经验总结一下：
1.多和开发人员沟通交流,保持良好的同事关系
2.BUG描述一定要清楚
3.要选择提交BUG的时间,如果开发人员手头上有很急,很多任务,这时,提交BUG给他,可能会打断他的思路.所以在提交BUG之前先问下开发人员手上工作的情况
4.当开发人员拒绝修改BUG的时候,千万不能生气或者表现得不耐烦,而和开发人员发生争执,而应该冷静对待,可以等心情好一点的时候再去找开发人员交流,以论证证明这个BUG必须需要修复.
5.要督促和跟踪BUG的修复情况,不要催的太急或者太勤,而应该根据BUG的修复难易程度给予开发人员一个合理的修复时间......

muerte

拿出数据.来证明他这么做是不合理的

zhangfangfang46

1、首先保证提交的bug确实与需求不付，且出现了问题
2、要与认真负责的态度来跟开发人员好好的沟通这里确实存在bug，在开发的实在无法理解的情况下把bug出现的情况给当场显示给开发人员看
3、测试人员应该在平常多增强自己的专业知识和沟通能力，使得开发的能更快的接受我们测试的观点

fen_wu799

1.建立良好的沟通与交流关系；
2.清晰的bug描述；
3.确保bug再现；
4.产生不可调和的“矛盾”，可向高层反映由高层来决定是否修改；

调皮精灵

1、首先你需要把此问题的复现条件做详细的记录下来。
1、如果是按照平时很常见的功能的问题，我想我们只需要把设计规格拿出来看一下就可以了。，。。我想向这种问题应该开发人员会很少拒绝修改的.
2、在交流的时候我们是需要友好，要客观的看待这个问题，尽量少用你和我的语言，这样容易把两个人放在对立的方面，尽量使用我们或是此问题之类的。
3、开发和测试最有争议的应该是灰色地带的。比如说一些可服务性或是可靠性的，另外是一些异常用例所测试出来的缺陷，对于这种缺陷在公司应该有很明确的文档说明，如果没有相关文档指示，你就需要把这种问题的危害性说出来，如果吧修改会出现什么样的后果。
3、需要制度保证，如果缺陷在客户方面发现了，对于开发也应该负责相应的责任，这样就能保证开发很公正的对待此问题。
4、另外在公司应该有专家组成的评估团队，对于开发和测试不能达到的共同认识的问题，就由她他们决定好了。并不是测试认为的问题都是问题的。。。。有时候还是需要评估的。。。在某公司遇到的问题是问题可能到其他另外一个公司就不是缺陷了。。

retifax_test

这好像是质量流程不规范的公司的通病
1.明确这是一个BUG，自己首先要对需求做到心中有数，查出缺陷时要先确认不是环境配置、版本问题（前提有完善的配置管理流程）或自己的其他原因
2.尽量重现BUG，这样开发人员易于查找原因，不会漫无目的
3.分析缺陷可能的原因，这样有可能帮助开发人员减小工作量，也能增加开发人员的好感
4.与开发人员做好沟通，明确缺陷需要修改以及修改的具体时间
5.私下与开发人员搞好关系，有利于推进问题的解决
6.通过定期不定期的缺陷汇报表明问题的严重程度，由上给开发人员一定压力
7.缺陷严重程度的划分很重要，天天去跟严重程度很低的东西，不仅会让开发人员好感降低，也可能会延误严重缺陷的解决
8.提高自己的技术素养和加深业务知识，不要说外行话，这是得到别人尊重的最起码条件
9.说到底，如果有一个完善的缺陷修改优先级体制和由上至下的质量意识，测试人员跟BUG根本不会这么麻烦。出现这些问题，就是因为测试工程师们根本没有权利去安排其他部门人员的工作量、时间安排、优先级定义等等，就是因为团队由上至下没有形成质量意识，以做出东西为优先，而不是做出高质的东西。当然，我们自己的职业素养也需要提高。

modyzhou

1.自信：首先要有的就是一份自信，当然自信可能来源于很多东西，但是最应该有的确实那一份对自己的信赖产生的自信，那是你在开发人员面前说话的主心骨。你若是连自己都无法相信，那么将是灾难性的。
2.证据：自信不仅来源于对自己能力的信赖，更多的应该来源于无懈可击的证据，各种数据，个个抓图，各种场景下的反应情况，这才是最最重要的，也是最最应该展示的东西，很有可能不用你过多的废话就可以解决问题了。
3.讲话的技巧：以上两点只能是说明你已经做到了对缺陷和自己的把握，但是没有好的语言技巧那么很有可能这些都会泡汤，因为有很多的缺陷都不是很明显的，更有的是可改可不改的，这时候你只要记住一点就行了，也就是你在整个的交流过程中只要关注这点你就会稳于不败之地，那就是“你是在为客户说话的”，你只要以此为观点那么谁都只有认可你的话。

ajoo

以理服人，如果不行那就欺蒙拐骗好了，只要能达到效果就行

光头佬

1.如果要靠说服来让bug得到修改，说明你公司的项目管理机制有问题。
2.其实方法上还是有有技巧。
a.问题的描述上刻意夸大(如果真的是非常小的问题话，不建议此做法）。
b.问题暴露面上扩大化，尽可能让每个相关的人知道，无形中给开发人员施加压力。
c.定时发打电话，发邮件提醒开发人员修改，让他不胜其烦，无发忍受，不得不改。
d.其实最重要的是树立强势的形象，定义自己为用户代表的角色，让整个项目的明白产品品质的重要性。

贱王之王

和开发人员说说下面几点：
1.缺陷的合理性
2.用户的人性化
3.风险性
4.交流修改的时间长短和算法难易情况。

havards

首先,先解决"缺陷是需要修改的证据问题".
测试人员要参考系统需求详细说明书或者软件需求详细说明书,确信缺陷需要修改的说法可以做到有据可依,这样自己的说法才能站得住脚.

其次,解决"如何说服".
拿这个缺陷和开发人员讨论的时候,要尽量做到客观,要就事论事,不要拿人来说事,站在开发人员的角度来说,也许他自己已经意识到有错误了,但是碍于面子不愿意承认的也有,所以这时候要拿前期阶段解决缺陷和产品发布以后所带来的损失的差别来比较.

最后,其实最好的办法是处理好测试和开发的关系,经常沟通,最好一个小的打包环节就review当前的缺陷,这些问题就迎刃而解了.