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

说服开发，修改bug

1.需要说明你提出这个bug 的依据
2.给开发工程师讲清楚，业务的需要，为什么要这样做
3.若不这样做，回带来什么影响及后果

bug单一定要被修改？？

[size=4][b]谁说我们提交的bug单一定要被修改？[/b]
准确的说是bug单一定要被处理（修改、延期修改、驳回）！

关于bug，从它被发现到提交，我们已经通过了组内人员的讨论，并定义了它的优先、严重级别。
对于它的处理，考虑到软件的进度、成本，可能会依据它的级别做出如上的处理方法，这是无可厚非的事情！！

对于严重级别高、优先级别也高的bug，没有到交货期限，却被拒绝，[b]我想有如下几种可能：[/b]

1、以前工作过程中经常出现失误，或小题大作，或无中生有，导致他人轻视，因此对于提交的bug不重视。
2、此次提交的bug在开发看来，不足以去修改，而我们看确实是重大缺陷。原因很可能是项目计划中没有把相关内容基线化，没有一个相同标准。
3、开发人员就是牛，不甩你，也不甩我们的领导。技术尖子不屑看你报告单。

[b]解决[/b]：陈述自己发现的问题时，一定要做到有据可循，言简意赅，定位准确，一针见血！
[b]基于上面问题[/b]
1、要从自己身上找原因，考虑是不是应该努力提高自身素质，赢取他人信任！严肃的提出本次bug单中问题所在，并提出建议性修改方法。
2、停下来，和上面领导商量，是不是应该把一些标准制定的完善一些、或制定一个独立的准则。
3、总有人能劝动那些自以为是的“牛人”，去找他们吧！一物降一物嘛！！

第一次回帖子，请楼主、同仁多指点！
刚入门级选手！[/size][/size]

[b][color=Black][size=5][font=楷体_GB2312]我的感觉是：拿着需求说明书，让BUG再现。用你所能说服的方法去说服别人……当然最好在私下，不行的话在到会上，公开让经理来决定[/font][/size][/color][/b]:)

感觉一般来说不会出现这样的问题吧!
首先,对于测试人员来说,既然是已经提交的BUG,那总体来说就是BUG;
而且对于有疑义的BUG,测试在提交应该和开发做交流,省的提交无效问题单
当然,对于楼主所提的情景,也是可以看到的,但不是很多.
既然是问题,开发就需要修改;
如果测试认为是问题,而开发认为不是问题:对于这样的情况,让老大们考虑去吧
不然要测试老大和软件老大,SE做什么呢?
在有流程或是规范的公司里,应该很少会碰到这样的问题;
:lol 个人意见哦~~~

看到大家都说出了自己的办法，我也来说说我测试两年中解决此类问题的方法。
下面我就列举一下我的办法：
1.针对开发人员懒惰的心态。
开发人员在项目测试初期对于发现的BUG，往往是非常积极的态度，但是随着项目的测试的结束时间的到来，开发人员就会形成一种懒惰的心理（测试人员也不例外），这种懒惰的心理就会使得开发人员面对那种不是崩溃或者严重性的错误进行公认或者设置为不解决。面对这种情况，测试人员唯一的办法就是将BUG信息传达给项目经理，并讲述不修改这个BUG对项目有可能造成的影响，这是解决这种类型问题的最有效办法，懒惰的项目经理除外。
2.针对开发人员对测试人员的个人感情因素
不知道你们遇到过开发人员对测试人员因为个人感情因素，而故意不对你提的BUG进行修改的问题。有些初级开发人员开发的模块，错误多多，单元测试又做的不足，导致了他所负责的模块的BUG远远超出了其他人的数量。项目经理的指责加上自己能力的限制，面对越来月多的BUG产生厌倦，对提BUG的人员产生厌恶，这种问题其实不好解决。每天必须去开发部10趟以上，而且必须和对你有厌恶感的人侃些工作之外的话，如果他怎么说话，你就和屋内其他人侃，营造幽默气氛，并在开玩笑之余讲述测试的困难，侧面说出你的无奈。如果公司有些什么活动的话，是个很好的机会，记住增加沟通。
3.针对需求不符类型的BUG
满足用户的需求是项目质量的分量很重的评价标准，不满足需求用户需求还提什么软件质量。
开发人员只了解自己负责的部分模块，不懂得整体架构，只知道与其他接口取变量，传变量。
测试出的需求不符的BUG必须将需求中提到的需求点粘贴给他看，概要设计中提到的设计粘贴给他看，可以截图给他或者以附件的形式上传给他，这叫有理可证。
4.试运行前三天遇到的问题
项目测试后期，马上就要拿到线程试运行的时候出现的BUG是最关键的，这个时候遗留的BUG也是项目经理最关注的。如果你想让他们把你提的问题修改，那你就把你的问题设置为严重错误，这个时候即使是一个小小的界面问题，我们都有理由认为它是严重的。
5.针对不容易重现的问题
测试过程中不容易重现的问题也是很多的。自己悄悄测试的时候出现了，开发人员一来看，问题就没了，开发人员看不到的问题，他们当然不会改。所以在测试的过程中尽可能的不要忘记3分钟前你所做的一切操作，并且将问题现象截图保留，因为这你是重现BUG和讲述问题的关键。
6.制定BUG提交规则说明书
强制性的规定测试人员提交的BUG，通过BUG提交规则说明书规范测试人员BUG。提高BUG的有效率。并根据BUG提交个则说明书制定开发人员
BUG修改标准，符合标准的必须由开发人员作出处理。
7.服从领导
如果项目经理说不改，你就不必费脑筋想办法让他们改了！

[[i] 本帖最后由 duola1119 于 2008-4-2 08:52 编辑 [/i]]

回复 1# 的帖子

首先：要确定对需求的掌握等全面、深刻，避免出现理解上的错误，同时和测试沟通时能够做到有理可依，有章可寻。
其次：BUG描述清楚，不存在歧义性，保证开发人员能够很好的理解该BUG。
然后：耐心的和他解释该BUG的原因，会出现的状况已经不修改会造成的危害，一般来说，开发人员不会出现态度很恶劣的情况，但是如果真的出现了，很多情况下也只能忍受，耐心的和他们解释。
实在不行，可以求助于项目经理或者质量管理部门，请求他们帮助你界定该BUG以及説服开发人员，但是要注意方法和态度，不用造成和开发对立的状态。

1.现和开发人员沟通，开发人员如果不修改，转到2
2.找需求人员明确
3.综合考虑是否修改（测试，开发，需求）
4.讨论后认为该问题不需要修改，那么把该BUG写人BUG库中，待问题在被用户提出后，可以有凭证。

我们在平时的测试工作中也遇到了这样的问题，目前正在有力的改善中，主要从以下几方面入手：
1、通过学习，提高测试人员的技术水平，主要体现在几方面：软件测试技术、与软件相关的计算机知识和业务知识、软件行业标准等；掌握了知识就等于掌握了强有力的“证词”，可以与研发人员据理力争；
2、与研发人员做好沟通，表明Bug不修改有可能带来的潜在危害；
3、在原有行业标准的基础上，细化适合自己公司和自己产品的质量标准，用标准来衡量Bug是否有修改的必要；
4、定期开展质量会议，召集测试人员、研发人员、QA、质量经理、客户代表等相关人员，从软件需求和客户角度出发，讨论Bug是否有修改的必要；
目前能做到的差不多就是这些，以后有好的主意再补充吧，也希望能从楼上楼下的各位处学到绝招。

[[i] 本帖最后由 cagemm 于 2008-4-1 20:24 编辑 [/i]]

上面说得都很好哦！
测试工程师不容易，同样开发也不容易；双方需要换位思考，互相体谅；
先要证明自己提的确实是BUG，问题能重现，并且对自己提的问题需要分级，什么是紧急的什么是严重的等等；各级别的修改需要按优先级，先后次序来安排；然后再和开发沟通他不愿意修改的原因，是不认为是bug，还是没时间修改，或目前没能力修改等等；结合bug本身或开发目前的情况来开展沟通行进工作。

站在用户的角度看待问题

我来回答一下，可以么？:loveliness:
首先，听开发人员是因为什么原因而拒绝修改此bug的。如果是因为修改这个bug会带来其他的更多的问题产生，我想开发人员拒绝修改也是有自己的理由的。作为测试人员也应该可以理解。但是站在用户的角度看待这个bug是否影响到了用户的正常使用。

如果没有影响到用户的正常使用，而同时修改此bug的会带来更大的风险，那作为测试人员，应该可以理解。如果影响到用户的正常使用了，即使修改会带来一些风险，那也必须修改，毕竟客户是上帝嘛！如果在这样的情况下，开发人员还是拒绝修改，直接发mail给PM，让PM及其其他项目负责人会议决定，并且沟通用户是否需要修改，我想测试流程是最重要的！

也不知道对不对，胡乱说了一些，大家别见笑啊:L

沟通很重要,从多个角度分析这个bug可能带来的影响,理智的与研发人员沟通.
如果还是不行,则可举出一些曾经出现过的案例(不修改导致的后果),从各个方面摆出事实.

如果真是缺陷，开发人员不修改，应及时向pm反映情况:)

第一步是要让开发认可你提交的缺陷是一个缺陷。
      1.提交的缺陷描述一定要清晰，有必要的话可以附上截图。
      2.和开发交流的时候注意语气和措辞，并再次客观地描述缺陷的严重性。
      3.平时要保持好个人魅力和人际关系。

第二步是要让开发确认这个缺陷是需要修改的。
      1.确认你所做的会得到测试Leader的支持。
      2.让开发更多地知道这个缺陷的严重性和对系统造成的危害。
      3.让开发知道这个缺陷对测试进度所造成的影响程度。
      4.如果其他测试也发现类似问题，可一起和开发交流。
      5.让测试Leader知道这个缺陷的危害和对测试进度造成的影响程度，并请Leader出面与开发Leader协调。
      6.平时要保持好个人魅力和人际关系。

的确有些时候你提出的bug开发人员会觉得不以为然,不用修改,他们有时侯就说这个bug不是问题.其实一旦这个问题一旦被客户发现那就会对我们的产品质量大打折扣.
      所以但我们遇到这中情况时千万不要冲动,这样反而会使开发人员更加反感.开发人员一般是站在技术和需求的基础上去考虑问题的,而他们往往对业务却不是十分明确,而对于测试人员一般是站在用户的角度上去考虑问题的,所以跟开发者在思想上就有一定的分歧.
      对于测试人员我们不是要说服开发者去修改bug而是要以理服人,比如我们可以把开发人员叫过来进行bug重现,或者把出现bug的页面截下来把出现这种bug的操作描述清楚,以便于他们查找bug的原因.
     当然良好的沟通很重要,作为一个测试人员具备良好的沟通能力这是很重要的.所以我们平时就要和开发人员建立一种和谐的同事关系,不要把开发部与测试部同事的关系划分的十分仔细.在和开发人员沟通是不要盛气凌人,态度要诚恳.相信有效的沟通一定会让我们拥有良好的工作氛围.

答复：作为测试人员如何说服他人认可你提交的缺陷是需要修改的？

我认为其实概括起来就是两句话“流程保证，实力说话”。

1、 流程保证

缺陷的处理如果总是让测试人员去说服开发人员去修改的话，这说明流程方面有问题。如果有一个规范的缺陷处理流程，那么这个问题就会比较少的出现，具体来讲，可以在缺陷管理规范或项目公约中具体规定，什么类型的缺陷必须修复（例如流程类，数据类错误），什么类型的缺陷可以不处理（例如一些产品建议），这样就可以减少这种是否修改的争议。另外还有缺陷审核机制和缺陷集中会审（例如微软的BUG三方会议），这样对于是否修改由更高级别，更有经验的人来判断，不但节省时间，而且风险较小。在我目前服务的企业，对于缺陷的开发打回，还有严格的流程规定，例如打回后测试人员可以提交给哪类更高级别的人员处理等。因此，我认为流程保证是解决的根本之道。

有些企业可能不能做到这么规范，或测试人员实际是处在一个弱势地位怎么办。很遗憾，这是目前许多测试人员所面临的现状，那我想除了我下面将要谈到的一点“实力说话”以外，在流程方面，其实测试人员不妨做一些努力，如与开发人员达成一种类似于流程规定或项目公约一样的约定，这样对解决这个问题也是很有帮助的。最后，争取逐步把这些口头约定或非正式约定转化为规范，或正式规约，开发如果从实际中获益的话，也会全力支持的。

2、 实力说话

有了规范的处理流程，但总会有需要讨论和争议的部分，这是开发和测试的工作性质决定的，就像有些人形容的那样，一个是建造者，一个是破坏者，讨论与争执已经成为了测试工作的一部分。但我们争也要争的有道理，因此就要“实力说话”，这在流程不规范的企业就更加重要。是否修改缺陷，我们可以从客户场景，影响程度，风险等具体方面去分析，这就需要你在这方面有实力，有经验，说白了，就是有话语权。你说的有道理，有根据，这是说服别人的基本条件，因此还是需要我们不断积累经验，强化测试技能和业务知识，从而说服开发作出修改。如果仅仅针对说服开发修改缺陷这个问题来说，从本人以往经验来看，功能、性能方面的错误往往没太多，太大的争议，对于一些边界和极端的操作测试，或涉及到易用性和人机交互的缺陷争议的比较多，因此在这方面的实力积累尤为重要。

还有一点需要说明的是，对于“实力”来讲，除了测试、开发技能，业务知识外，沟通和交流也是一个不可忽视的重要能力，如何有技巧，有策略的进行问题沟通，这个就非一朝一夕所能练就的，但目前测试人员又特别需要这种能力去推动事情的解决，因此平时这方面需要注意积累，当然在往下谈，可能有些说远了。

如果上述两方面都欠缺的话（这是许多初涉测试的人员所面临的问题），该如何应对呢？我想不妨寻求一些必要的帮助（如更高级别人员，更有经验人员），这样既推动了问题的解决，又学习到了宝贵的经验，只要勤思考，总会有适合你的一些办法。

良好的操作记录习惯＋与开发的沟通＋客户的角度去讲述该问题的重要性

良好的操作记录习惯＋与开发的沟通＋客户的角度去讲述该问题的重要性

1 测试人员对自己的工作要专业，对于每个bug的处理有责任感。
2 与开发人员，项目经理，客户多沟通，真诚的交流。

首先应该明确一点，测试人员与程序员或设计人员应该是平级的，因此不应该由测试人员来说服程序员或设计人员，标准流程应该是向项目负责人及销售人员提出，由他们站在项目的立场上协调解决。因此最重要的是说服项目负责人，让他明白该缺陷可能对项目产生什么样的影响。然后由项目负责人向设计人员或程序员下达修改指令会比较容易一些。如果项目负责人无法确定该问题是否重要，也可以通过召开项目核心成员会议来对该问题进行充分的讨论。一般在项目管理中比较忌讳测试人员直接将修改任务下达给程序员，因为可能有些问题在该项目中可能不是问题或者项目负责人有其他更合理的考虑。之所以要通知销售人员是因为他与客户的距离最近，最了解客户的真实意图。如果能够争取他的支持，在讨论会上你会增加一个重要的盟友。尤其是他如果在你发言的时候附和的话，别人就很难提出反对意见了。至于程序员和设计人员，只要和他们保持较好的个人关系就可以了，没必要和他们发生直接的冲突。

1)首先，公司需要要明确清晰的defect处理流程
  2)提交的缺陷要描述清楚，没有歧义，例如：填写缺陷的分类、摘要、详细描述、重现步骤、出现频率、严重性、优先权、所属模块、所属版本等信息,如果有必要的话，可以在附件中添加测试数据，问题页面截图及相关的log记录。
  3)做好step 1，相信大部分的defect应该可以被解决。当然一些出现频率低的defect,developer可能需要tester帮忙重现，这时tester需要耐心的重现defect,保存log记录
  4)有时developer认为该defect不是问题，这时tester需要与developer直接沟通，根据function specification等标准文档说服developer解决问题
  5)有类defect是属于suggestion,描述defect的时候需要描述清楚系统当前处理方式，存在什么问题，按建议修改后，会如何处理等等。对于这类问题，PM有时会分派下属的developer在这个版本中修改，有时会将问题置为已确认、公认等状态，在下个版本或某个合适的时候再修改；也有时会将问题打回。
  6)升级defect 对于PM打回或不予解决的问题，如何你有异议，可以直接与PM沟通，不行的话，可以向上报告，说服test manager,由test manager与PM交涉。

4#讲得不错，顶一个

我们要先设定一个前提就是，我们提交的故障确实是需要修改的。
首先，良好的沟通是前提。如果测试人员和开发人员一直保持良好的关系，采取合理的沟通那么，说服对方的可能就很高。
其次，需要让开发人员了解这个问题的严重性，并完全的复现这个问题。
再次，如果还是不能说服他那么只能提交项目经理，让项目经理判断问题。

首先是测试人员自己从自身角度出发,把问题的方方面面都考虑清楚,说服别人,首先要能说服自己,在自己都考虑清楚以后,最重要的是根据需求出发,一切违背需求的开发,即使做的再好,也是被认为是错误的,测试人员应牢牢把握住这一基本原则,而且自己需要在技术上有一定的见解,比如一些性能问题上,那些指标是必须达到的,在与开发人员讨论时,应围绕这些公认的技术要点讨论,说服对方,如果实在在需求或者技术实现上有分歧的,可以寻找上一级领导进行评审,让技术上更权威的人来说话,这也是迫不得已的办法,一般情况下,指双方都有相当责任心和技术能力的话,这些问题是可以自行解决的.

热忱并且耐心（Be Cordial and Patient ）
作为一个测试人员，你或许发现使开发人员信服你发现的缺陷是非常困难的。通常，如果一个测试人员找到了一个bug，程序员将准备10个理由。有时让开发人员接受他们的代码是有缺陷的（并且是其他的人发现的）这个事实是很困难的。
开发人员需要来自测试小组的支持，测试小组可以保证发现的新bug是值得关注的，健康的并且对于使产品更好是非常重要的。一个人性的方法是经常帮助测试人员更多的了解编程人员。相信我，不用多久，相同的一个人将站在你身边了并且笑着指出引起bug的错误。热忱将帮助开发人员对你的错误报告说“Yes”。这是重要的第一步。

处事老练（Be Diplomatic ）
试着巧妙地表述你的发现，并且不带任何责备地解释bug。“我确信这是一个很小的bug，你不用花多少时间就可以处理掉。到目前为止这还是一个不错的程序。”开发人员将会跳起来并且拥抱你的bug。
用一种心理方法。有时表扬一下开发人员的工作。为什么大多数开发人员不喜欢我们的错误报告的原因非常简单：就是他们认为我们在诋毁他们的辛勤工作。有些测试人员只在出现问题的时候才和开发人员沟通。对于大多数开发人员而言，软件是他们自己的孩子，而你只是一个妨碍他们的外人。我告诉我的开发人员因为他们我才存在于公司，而且由于我的存在，他们的工作才得以继续。测试人员和开发人员之间的关系是一种共生及互惠的关系。

不要害怕尴尬（Don’t Embarrass ）
没有人喜欢被指出错误。这是人类的天性。试着解释修复那个特别的bug的需要胜于只是用庞大的bug报告向开发人员开火。一连串的缺陷不只会激怒开发人员，而且会使你的辛苦工作对他们来说是无用的。
正象一个人不可能独自测试完一个程序一样，开发人员也不能设计程序没有任何错误，而且在其他事情发生之前，他们需要先了解清楚。有错误是预料之中的事，他们也是过程中的一个正常的部分。

你赢得了一些，你也失去了一些（You Win Some, You Lose Some ）
我知道有些测试人员尽可能将自己的错误报告强硬。他们甚至不听开发人员关于为什么不能修复一个错误和不能实现一个功能的解释。尝试一些可以让自己放松的方法。做到开发人员身边和他一起分析错误的优先级和严重程度。如果开发人员在其不愿变更的背后有一个合理有效的解释，试着理解他。只是确信了解了要在什么地方划定界限以保护你产品最终的质量。

谨慎一些（Be Cautious ）
外交手段和适应能力不能替代谨慎的需要。开发人员经常会找借口说因为他们没有意识到（或者你没有告诉他们）那个错误有多严重所以他们拒绝修复它。用足能够清楚展示风险和问题严重性的方法设计你的错误报告和测试文档。甚至更好的办法是召开一个会议并且向他们解释那些问题。


一个聪明的测试人员是在倾听和执行之间保持平衡的人。如果开发人员不能使你信服错误不应该被修复，那么你的责任就是使他信服要修复错误。

要说服他人认可你提交的BUG，那就需要你要执着，站在客户角度看问题，不要轻易被他人说服你。前提一定要有耐心，要尊重他们。不能说强制他们去修改。现在有很多测试人员，找到人家的问题，就态度很不好，说人家的能力不好。这样肯定说服不了的。
1、测试人员要执着，站在客户的角度看问题。
通常情况下，如果是需求明确提出的，你提交BUG后，一般开发人员都会修改，不修改情况下就找需求说明书出来。那有根有据的情况，他们肯定会修改的。
很多情况下，都是那些体验上的BUG，易用性上的，不是功能性的。开发人员如果不是很注重体验的话，就会觉得你很挑剔，就会反过来以浪费时间，项目紧之类的理由来说服你。例如，一个按钮的使用，或且一些界面上的排列，图标之类的问题。通常你提出来，他们都会以不必要修改去说服你的。
这种情况下，就看你站在哪方了。如果你从开发人员的角度出来，想着，也对，不修改也没什么问题。修改还要那么麻烦，浪费时间，而且项目又紧，那你就会反过来被他们说服的了。
但如果你站在客户的角度，想着这个不好用，会很影响一个人对这个东西的评价的。你现在不修改，到时客户提出来再修改，那后果就严重了。那你就可以从公司的利益出来，体验不好，对公司的影响，客户的影响来说服他们。特别是交接后，客户又提出这些问题的话，那就需要很大的维护成本了。通常开发人员会被你说服的。
2、从同类软件中对比来说服他们
可以从现有的同类的又优秀的软件中提出对比，让他们看到改与不改的好处。这样他们看到好的地方果真比自己做的好多了，那也会很容易接受你的BUG。
3、业务一定要很精通。
很多情况下，一个开发人员或设计人员，只负责一部分的开发或设计，对整个系统不会很清楚，所以有些东西做出来后，单独去看是不会有问题，但整体上会影响别人的模块。测试人员，很清楚业务上的东西，知道哪里受了影响，受了什么影响，那在说服他的时候就很很容易了。
4、提高自己的开发水平，提高他们对你的认可度和尊重度。
还有一些情况下，就需要你自己具备的说服力。你要使自己在开发人员中，具有说服力，也要提高自己的各方面的水平。很多情况下，开发人员总是觉得测试人员只会随便点击，其它什么都不会。所以提出一些问题，就得不到他们的重视。但如果你也具备一定的开发水平，那在找到问题时，你可以从开发的角度去说服他们，他们看到你的能力，更加容易被你说服，不会说因为看不起你而不肯去修改。

[quote]原帖由 [i]jacky_zhuang[/i] 于 2008-4-1 12:45 发表 [url=http://bbs.51testing.com/redirect.php?goto=findpost&pid=931963&ptid=110037][img]http://bbs.51testing.com/images/common/back.gif[/img][/url]
.  竖立团队品牌===平时提交的bug需要有良好的复现概率和清楚的复现步骤条件;    提交的bug有统一的格式和标准;   提交的bug尽量有准确的定位和现象分析,日志跟踪等;   

.  竖立制度保证===和pm及dev leader有良好 ... [/quote]
里面有bug:是树立 不是竖立 呵呵

测试人员不仅仅是做测试的，她是一个服务类型的行业，前面技术支持与客户，后面才是开发人员，她是个纽带。

其实不能以偏概全，具体软件，具体公司，具体分析。

不管怎么样，我觉得如果大家都从公司投资于客户需求比较分析，得出结果。

有的问题，这样做就很浪费时间，这就需要测试人员对错误的把持度。

[size=5]我认为这个要从很多方面去做，可以同开发人员先沟通，将自己测出来的BUG的图截给他看，如果他还是不认为这个是很严重的错误的时候，只能先报告测试主管，由测试主管根他们的开发主管沟通，让他们的主管去与开发人员沟通，不能根他们开发人员产生矛盾![/size]

我也碰到过这种情况,单纯的bug倒还好说,有的是客户体验性质和人机交互信息的bug,这就比较难讲,因为没有一定的规范.我在这方面的策略如下:
1.如果公司有定义产品需求人员的话,首先和需求沟通,赢得需求的肯定,让需求再出一份补充需求出来(更改的周期比较长,估计可能要到下个版本发布才会改)
2.公司没有需求,就直接和开发人员沟通,这个比较困难的,因为如果是因为人机交互信息有问题,可能每个页面都有相似的问题,更改起来是容易,但是麻烦,很多开发都不愿意改,这时候可以和开发当面交流,告诉他,这么写,如果是客户,会造成什么样的误解,会有什么样的不方便,给他看相似的程序或者网站,告诉他通用的做法是什么,客户通用的理解是什么.
3.如果开发还是拒绝更改(事实上,很多开发都对测试有抵触情绪),可以和测试经理沟通,让测试负责人和开发负责人去说,如果他们达成了共识,改或者不改,就不是我可以决定的了,如果他们决定改,我会很开心.如果决定不改,那我也没办法,在我的职责范围内,能做到的就是如此.

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

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

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

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

回复 1# 的帖子

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

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

自信，证据，讲话的技巧

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

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

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

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

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

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

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

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