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

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

[align=right][email=webmaster@51testing.com][b][color=red]" 每周一问"问题征集[/color][/b][/email][/align]

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

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

[table=371][tr][td=4,1,371][align=center][font=宋体][size=2][color=#ff0000]获奖名单[/color][/size][/font][/align][/td][/tr][tr][td][align=center][font=宋体][size=2][color=#0000ff]奖项[/color][/size][/font][/align][/td][td][align=center][font=宋体][size=2][color=#0000ff]获奖名单[/color][/size][/font][/align][/td][td][align=center][font=宋体][size=2][color=#0000ff]奖励[/color][/size][/font][/align][/td][td][align=center][font=宋体][size=2][color=#0000ff]答案链接[/color][/size][/font][/align][/td][/tr][tr][td][align=center][font=宋体][size=2][color=#000000]一等奖[/color][/size][/font][/align][/td][td][align=center][font=宋体][size=2][color=#000000]cityyard[/color][/size][/font][/align][/td][td][align=center][font=宋体][size=2][color=#000000]当当购物卡50元[/color][/size][/font][/align][/td][td][align=center][font=宋体][size=2][color=#000000][url=http://bbs.51testing.com/viewthread.php?tid=110037&page=1#pid927595][font=宋体][size=2][color=#000000]10#[/color][/size][/font][/url][/color][/size][/font][/align][/td][/tr][tr][td=1,2][align=center][font=宋体][size=2][color=#000000]二等奖[/color][/size][/font][/align][/td][td][align=center][font=宋体][size=2][color=#000000]walker1020[/color][/size][/font][/align][/td][td=1,2][align=center][font=宋体][size=2][color=#000000]300论坛积分[/color][/size][/font][/align][/td][td][align=center][font=宋体][size=2][color=#000000][url=http://bbs.51testing.com/viewthread.php?tid=110037&page=1#pid927162][font=宋体][size=2][color=#000000]4#[/color][/size][/font][/url][/color][/size][/font][/align][/td][/tr][tr][td][align=center][font=宋体][size=2][color=#000000]duola1119[/color][/size][/font][/align][/td][td][align=center][font=宋体][size=2][color=#000000][url=http://bbs.51testing.com/viewthread.php?tid=110037&page=3#pid932429][font=宋体][size=2][color=#000000]45#[/color][/size][/font][/url][/color][/size][/font][/align][/td][/tr][tr][td=1,3][align=center][font=宋体][size=2][color=#000000]三等奖[/color][/size][/font][/align][/td][td][align=center][font=宋体][size=2][color=#000000]xixihahahu[/color][/size][/font][/align][/td][td=1,3][align=center][size=2][color=#000000][font=宋体]100论坛积分
[/align][/font][/color][/size][/td][td][align=center][font=宋体][size=2][color=#000000][url=http://bbs.51testing.com/viewthread.php?tid=110037&page=1#pid927246][font=宋体][size=2][color=#000000]6#[/color][/size][/font][/url][/color][/size][/font][/align][/td][/tr][tr][td][align=center][font=宋体][size=2][color=#000000]土土的豆豆[/color][/size][/font][/align][/td][td][align=center][font=宋体][size=2][color=#000000][url=http://bbs.51testing.com/viewthread.php?tid=110037&page=2#pid931992][font=宋体][size=2][color=#000000]39#[/color][/size][/font][/url][/color][/size][/font][/align][/td][/tr][tr][td][align=center][font=宋体][size=2][color=#000000]贝贝酷[/color][/size][/font][/align][/td][td][align=center][font=宋体][size=2][color=#000000][url=http://bbs.51testing.com/viewthread.php?tid=110037&page=4#pid934775][font=宋体][size=2][color=#000000]63#[/color][/size][/font][/url][/color][/size][/font][/align][/td][/tr][/table]

与开发人员良好的沟通： 测试执行过程中，当你提交了问题报告单，可能被开发人员无情驳回，拒绝修改。这时候，只能对开发人员晓之以理，做到有理、有据，有说服力。首先，要定义软件缺陷的标准原则，这个原则应该是开发人员和测试人员都认可的，如果没有共同认可的原则，那么开发人员与测试人员对问题的争执就不可避免了。此外，测试人员打算说服开发人员之前，考虑是否能够先说服自己，在保证可以说服自己的前提下，再开始与开发人员交流。

回复 1# 的帖子

其实,有时不需要考虑太多，平时多沟通，认真对待工作，态度端正，问题也就解决了。

1，和开发人员达成共识：开发人员的开发工作和测试人员的测试工作的出发点是一致的，都是为了给公司创造利益。达成这个共识后，开发人员就不会对测试人员和测试人员的工作有抵触情绪；再在这个认识的基础之上，和开发人员一起讨论如何修改代码他们的Effort比较小（如果你有一定的开发能力）、何时进行修改（由于各种原因，可能需要稍后进行一起修改）等。

2，与开发人员建立良好的关系，包括私人关系。如果你的能力强，开发人员可能会把某些工作交给你，让你帮忙做。这时可以积极接受，尽最大肯能帮助它们。我的一个同事曾发现某个Bug是由于没有写对一个业务逻辑比较复杂的SQL语句，于是他自己写了，就把开发人员一直困扰的这个问题解决了。从此以后，开发人员就非常支持我们的工作了。

3， 系统和软件最终是要交付给客户的。只有他们认可了，同意付款了，开发人员和测试人员的工作才算有意义。因此，我们测试人员一定要站在客户的角度去使用软件，去测试人员。我们要考虑客户会怎么样使用，他们可能会遇到什么问题。这样可以减少许多直到交付给客户后才会发现的问题。从这一点上来说，我们也要让开发人员站在客户的角度去理解为什么这个Bug一定要修改。曾经有许多UI上的错误，开发人员举手之劳就修改了。可是就是不修改，他们认为不需要。我就是让他们先把自己设想为一个客户来使用此系统，然后说服他们去修改的。

4，如果有条件，建议拿出你的数据和证据去说明为什么一定要修改它。如，进行性能测试后的测试报告数据、经客户确认的需求说明书等。

总之，既要让开发人员知道你是站在他的立场上考虑问题的，同时又要站在客户的角度来说明为什么需要修改这个缺陷。

[[i] 本帖最后由 walker1020 于 2008-3-29 01:16 编辑 [/i]]

1，        和开发人员达成建立合作默契
2，        和开发人员随时讨论
3，        与开发人员建立良好的关系
4，        和开发人员合作完成项目。
5，        同理心
6，        讲数据
:lol

1.测试人员需要仔细描述缺陷的复现过程。对于复现过程复杂的缺陷，我一直采用使用录像软件录制缺陷复现的过程，并作为flash附件放到缺陷库中。开发人员都很欢迎。当然他们最欢迎的是面对面的沟通，这是人性。
2.测试人员需要不断学习，拥有跟开发人员沟通的资本。为了跟开发人员更好的沟通，我的知识领域从PC到小型机，从windows到Unix，编程语言更是无所不包。以前是使用delphi来开发，我就要学习delphi的语法和编程；现在使用java，我就熟悉java的语法和web编程。开发的财务软件就要熟悉财务知识并精通需求；开发的是工控软件就要熟悉工控常识。不求精通，但求熟悉。我个人觉得这是情感认可上征服开发人员的必备条件。
3.测试人员要有比开发人员强得多的质量意识，不仅要意识到严重缺陷的风险，更要将这些风险明确无误的传达给开发人员。例如在企业管理软件开发中，由于一些缺陷会导致数据混乱，这类缺陷在软件短期的使用中往往不明显，开发人员通过后期的SQL更新数据库也能解决。但是测试人员最好要有钻研精神，向开发人员指出缺陷的根本原因是软件缺陷而不是用户误操作，如果不及时修正，会形成不正确的企业报表，导致无可挽回的损失。
4.软件不可能做到零缺陷，正确的划分缺陷等级，使得开发人员能够在有限的时间里解决严重的缺陷。开发人员一直在从事创造性的开发工作，为了赶在项目期间完成所有功能已经殚精竭虑，如果功能还有一大半没有开发完毕，已开发的功能又有大量缺陷，心情会显得异常焦躁。其实大量的缺陷经过仔细分类，大部分是中等缺陷或修饰性错误，只有一小部分是致命缺陷和严重缺陷。给每类缺陷不同的修复周期，相信开发人员能够及时处理。
5.研发中心制定可操作的考核标准。现在大部分的缺陷都是缺陷管理系统管理起来的，每个开发人员都会在开发过程中在缺陷管理系统中留下自己开发产生的缺陷及修改记录，针对开发产生的缺陷和遗留的缺陷进行奖罚考核，能够从根本上提高开发人员的积极性。我原所在单位就进行过这样的管理制度，有一次100%的开发人员都得到了不同程度的加薪，而另外最严重的一次一个开发人员由于拖延修改缺陷被罚去300RMB的奖金。虽然第五条是我最不愿意看到施行的管理制度，但是却是最客观和可操作性的。

如果真遇到这样的问题，那公司的项目管理肯定不正规。
首先，测试人员，只提供测试结果，给出完整，清晰的report。我想他是没权利去强迫某个人去修自己提交的bug。
项目经理干吗呢？ 在我们这里，是测试人员，rd老大，PM一起review bug，确定优先级，然后rd根据这个来修。

我想如果出现rd和qa因为修哪个bug而直接争执，那项目失败的可能性就真的很大了。 rd和qa沟通是因为如何修bug，而不是修哪个bug。

补种：
前提是你提交的bug的确是bug，并且描述的也没问题。 如果报的bug不能复现，描述让人不理解，那就不用再谈，测试人员的工作质量太差。

前提：测试人员对所测的工程非常的熟悉（不熟悉的提问题前最好找个文档或者规范查一下，或者也可以找个这方面的专家确认一下:) ）
1.功能问题：功能方面的问题在需求规格说明书中都有描述，需求规格说明书是开发人员和测试人员之间共同遵守的规范。除非规格变更，一般不需要说很多开发人员都会修改

2.主观判断问题：比如用户体验、界面不友好等有很大一部分的主观判断因素在里面时，级别最好不要太高，一般是“建议”级别的问题，这样的问题最好不要在一开始就提出来，因为一般最开始问题比较多，开发人员本来对测试提那么多问题都有一些抵触的情绪，此时提这样的问题会让开发认为这是小问题，可以不修改。一般此类问题最好放在最后提，多跟开发沟通一下，如果确实影响用户体验开发人员都比较容易接受。

3.有时候提的问题开发会告诉你这问题没有办法修改，底层驱动受限之类的。遇到这样的问题最好先与开发沟通，然后可以找开发人员，开发负责人，测试负责人等相关人员一起开会，看这个问题是否要解决，要解决讨论一下解决方案

暂时想到这些。。。

啊诺~~~这个问题其实非常不好回答，实际情况往往很复杂……
就我个人经验写一点感受吧~~当然了，诸如要写清楚现象，尽量详细报告等是QA人员应有素质，这里篇幅原因暂且搁置不谈。

首先，开发方必须提供完整详细的式样书和制限事项。式样书是测试人员测试的基础，测试人员如果按照式样书测试得到了不一样的或者奇怪的结果，那么必然是bug无疑，没有任何可以争论的余地；如果测试人员执行了式样书上没有写的动作，得到了一个奇怪的结果，那么首先去制限事项里面找，如果制限事项写了，那么意味着开发者知道这个问题并且还在开发中，那么OK暂时放过（注意是暂时），如果制限事项也没写，那么再看这个动作是不是用户可能做出来的动作，举个例子如果一个软件的某个命令完全封装在内部，调用时一定会以普通用户身份执行，那么测试人员使用root测试出来的问题就是无效的（注意，当然封装的命令可能因为封装错误用root执行了，但那是另一个bug）；如果测试人员的动作虽然式样书没有，但是却是用户可以做出来的，那么抱歉，这个问题必须修改，而且还要围绕这个被式样书遗漏的问题进行拓展。

其次，测试开始前由开发方review测试方的测试计划，并针对测试方对式样书的疑问答疑。这一点有两个好处，一个是开发方可以尽早指出哪里测试不合理，哪里测试薄弱，另外也可以减少以后因为双方理解上的差异带来的时间浪费。虽然这会占用一点开发人员的时间，但是磨刀不误砍柴工。

第三，建立完备的版本管理系统，这个系统如何建立前面的每周一问已经详细讨论过了，目前要补充的就是，版本管理中必须把式样书和制限事项一起加进去，开发者发布了0_0_1版，其中制限事项是文件数目不能超过1M个，0_0_2版开发者取消了这个制限，那么必须在发布作这个版本的同时写明这一点，测试人员才能据此测试。严格的版本管理可以有效减少纠纷，如果测试人员使用0_0_1版测试1M+1个文件失败，那么是无效测试，如果使用的0_0_2版，那么就是bug必须修复，无可争论。

有了上面三条，大部分问题差不多能解决了，但是还是不行，差在哪里？主要还有两个问题，一个是测试方可能指出一些跟个人喜好相关的地方，比如测试方可能指出GUI一个警告信息窗的字体太暗而且不显眼，不容易被注意到，这类问题无法用上面三条来解决，因为是否容易被看到本身就不好界定；另一个问题就是（尤其是到了测试后期），测试人员连续跑了好几天测试忽然程序死了，再来一次又没事了，告诉开发人员这个现象，开发人员也解决不了，因为很难再现，如果是测试环境问题还好，如果真的是软件缺陷那被用户遇上就很严重，但是这种问题无论是让QA无休止的尝试再现还是让开发者没头没脑的调查都很难说得过去。

于是我们加上一条
第四，仲裁机制。QA和开发者并不直接对话去讨论一个问题是否要修改，我们首先对开发者实行残酷的有罪推定，也就是QA报告的问题开发者都必须修改，如果开发者认为无需修改必须给出理由和证据，围绕这个理由是否成立，QA和开发者双方展开讨论，这个讨论必须每一步都使用缺陷管理工具记录下来。最终要改还是不要改由一个仲裁机构来决定，当然了这个仲裁机构其实就是更上层的管理者，他们手里是日程计划，市场需求，对手状况等，他们根据这些更高层信息决定一个问题是否值得去修。

写到这里细心的读者已经发现，题目问的是怎样去说服，我却大谈测试管理方法。其实我个人觉得，建立一个宏观的良好机制比起一个测试者去唇枪舌剑的和开发人员辩论更加有效，我们追求的是什么，不就是效率么。因此我个人以为真正的测试人员职责就是报告缺陷，至于这个缺陷是否应该被修复先用机制套，套不上再来仲裁，仲裁过程QA leader全程参与，测试人员要做的只是在仲裁过程中客观的回答每一个问到自己的问题，至于什么我认为这个bug必须修之类的话不必出自测试人员之口，正如汽车发动机只需要考虑转呀转，具体哪个路口该拐弯也让发动机来考虑就不必了。

1-测试人员仔细研究需求说明书，确认此缺陷和需求有矛盾的地方
2-缺陷的重现，测试人员要让开发人员了解软件确实存在漏洞，这样加强说服力
3-测试人员应条理清楚的表述缺陷内容，与开发人员良好的沟通，用理服人
4-开发人员实在不修改缺陷，提示他除了问题非测试人员责任

呵呵，小女子见解，不足见量~~~~:)

回复 11# 的帖子

1、详细清晰的描述出BUG，提交入缺陷库，已经有高级且有经验的测试工程师确定该BUG是真正的缺陷，确定状态为Open；
2、分配解决该BUG的研发人员按照详细的BUG描述已经重现了BUG，但是拒绝修改，这里有几点：
   a、公司或者部门的流程不规范，责任不到人，可能有扯皮推脱责任的情况存在，QA对BUG的跟踪上有些脱节；
   b、研发人员个人原因，承认是BUG嫌麻烦或者不好处理之类；
   c、研发认为不是问题，就是这样的做的之类；
3、
    上面的a情况在小公司应该是经常出现的，对于这样的情况，尽量和研发搞好关系，私人关系好是最好，说服研发修改缺陷；如果研发实在拒绝修改，将问题告知测试经理和项目经理，BUG状态保留，大家如果都没有反应，这样测试人员只能到此，可能多做也无意；
    上面的b种情况测试人员可以先和研发人员讨论，阐述BUG的严重程度，用户的需求或者行业标准，并积极参与分析缺陷产生的原因，打消研发消极处理态度；最好多了解些项目的相关信息，视BUG严重程度、项目进度、程序发布紧急程度等因素而定，如果能够说服修改BUG最好，如果项目紧急，BUG不严重，可在以后版本修改，最后邮件或者报告抄送给相关项目以及测试人员告知情况；
    上面的c种情况就要难处理，首先要对方承认这个确实是BUG，有需求文档、产品说明书、规格说明等文档参考，具体实现的功能说明等资料都可能派上用场，诱导研发站在用户的角度是看待这个问题，演示给研发看，并请他进行这类操作来重现问题，也可以请周围的同事参与讨论或者操作，以他们的实际感受来说服研发修改BUG，如果修改，沟通成功；如果不能修改，找相关的项目经理讨论这个BUG，由项目经理和研发讨论，如果还不行，问题反馈给测试经理项目经理就OK了，一切都由他们商讨；

    当然在交流的过程中大家要相互理解，尊重对方，不要有过激的言语，平时多加强感情的交流，只要是敬业的开发人员，在一个流程比较规范的工作环境下，对于出现的被认为是缺陷的BUG都还是愿意去解决的。

一.从客户的角度分析问题的影响程度,说明该缺陷若不修改，会造成多大的影响，对公司造成多大的损失
二.从问题本身角度，提供详细的数据和文档，清晰表明此缺陷确实存在，并且说明严重程度
三.若问题真的不是特别严重（提示性的），可以协商在下个版本中改。

没有这方面的经验 有待学习！

其实流程再好，也难免会碰到类似的问题，个人认为在碰到该问题的时候，可以从以下几个方面入手：
1. 既然提交了Bug，这说明这个问题在测试组内部是得到过充分认可的一个缺陷。如果被开发人员认为不是一个Bug，首先在测试组内部进行讨论，看看开发人员为何认为这不是一个Bug，找到原因之后，再检查我们所提交的报告，看是否存在不足之处，如果有，则加以改正，然后再次ReOpen。
2. 如果在Bug描述上面没有任何问题的情况下，开发人员仍然不认不这是Bug，测试组可以就此Bug从多个角度来说明认为它是Bug的原因。比如，这是根据测试用例，或者测试文档可以直接证明它是一个Bug。
3. 如果没有直接的证据来说明，那么需要测试人员根据以往项目的测试经验，或者站在用户的角度上来举例说明。比如，以前的项目在这个地方是什么样的结果，而现在的结果跟以往项目不符。比如，这个问题在某个版本的Build上面不发生，但是这个上面就发生。比如，在什么样的操作下不发生，而在这种操作下却发生等等等等。

总之，最重要的是测试人员和开发人员之间的沟通的有效性。一定要注意沟通的方式和技巧，要本着互相探讨互相商量的原则，要力争把问题讲清楚就可以了。

另外，在碰到这种问题的时候，开发组那边应当有一个专门的小组，来决定此类Bug是否需要修正。
如果测试和开发都有一套比较完备的流程，那么这种问题是可以很好的得到解决的。

简单一句话：摆事实，讲道理，冷静对待。

将bug清楚地重现，让他亲眼看到，然后再说服他！

1 确实验证该BUG 确实是一个问题 （需求、代码...都可以）

2 当BUG 关系到开发的切身利益时，肯定会在乎。这个需要制度保证

3 开发有上级的。说服他上级像开发施加压力。这是下策

对自己测试出来的问题进行截图和屏幕录像。然后再晓之以理，动之以情。。。哈哈哈

正确沟通，让开发人员理解你，说明该问题存在原因，说明不修改会有什么后果，会对软件的使用造成什么影响，让你的立场清楚的说明就可以了，当然我觉得有的时候你的觉得一定需要修改，而开发人员不想修改的时候，是需要一个思想工作的准备的

我是一名初做测试的实习生,也遇到类似的问题,很苦闷阁

1.首先从自我方面,考虑确定这是不是一个bug,也可以通过qa team讨论,是否是bug,是否需要修改,是否可以放到下个版本解决等
2.如果确认是bug,跟开发摆数据,讲道理,用客户角度看待问题,越后期修改bug成本越大,以此劝说开发修改
3.多提升QA的开发知识,尽可能熟悉掌握一些编程语言技巧等

回复 1# 的帖子

发生这种情况真是太多见了，我一般不会直接和开发人员争执。好点的方法可以和项目经理，或是你的LEADER一起开会讨论，来确定此次的BUG的优先级，来决定是否在这期修改；

1.基于完善的《需求说明书》，在测试人员对需求说明书有足够了解的基础上，谈论这个问题才能有所依！

2.对项目的实现方法各抒己见，在充分评审的基础上。已自己有力的理解和评审结果进行说服。

3.对缺陷的描述尽可能的完整和完善，让开发人员在看这个缺陷描述的时候，能正确的自己重现出来。

4.在团队开发过程中能积极的进行交流，沟通的多也就避免出现缺陷不被认可的情况。

5.充分评审测试用例，让开发人员了解如何步骤获得如何结果。

程序员拒绝修改某个BUG，我们首先要从源头上找出不愿意修改的原因，再使用对应的策略，根据实际工作经验，主要分为以下两种情况：
1，程序员认为该BUG不会影响最终的版本发布，而修改后可能会引发更大的风险。
在这种情况下确实需要审慎处理，最好首先和产品定义部门的同事先确认一下，你提的BUG优先级如何，在得到产品部同事支持后，可以找到项目经理及其他人员联合评审，BUG修改的影响范围。在得到领导的支持后，修改应该不成问题。
2，程序员认为是个小BUG,根本不需要修改，他还有其他重要的事要做。
这个时候你需要做几件事情，一就是要把BUG发生的后果详细演示给程序员看，然后指出可能引发的其他故障，二找出市场上已经存在的相类似的用户投诉的例子，三帮助定位出精确的故障点，向程序员指出修改这个问题将不会耗费太多时间。这第三点很管用，但有一定难度。

程序员和测试员是对立的两个岗位，发生争吵是在所难免，但我认为平时一定要加强和程序员的沟通，先做好朋友，以后碰到问题时，自然好说话。
同时，测试员也应该提高自身的技能，有很多程序员恃才自傲，瞧不起测试人员，如果测试员自身的素质提高了，自然会得到程序员的尊重，你说的话自然也就有分量了。

1、提供完整详细的bug描述，开发人员根据描述操作能再次重现bug；
2、根据已有的需求文档、设计文档，与程序员沟通，指出此bug的影响范围和严重程度；
3、要求程序员写出详细的拒绝理由，若测试人员不满意，可再次与程序员沟通，若沟通无效，测试员可将此问题反映给测试主管，由测试主管与项目经理协商；

一点拙见，大家指教:loveliness:

提出缺陷，和开发人员讨论要保持对缺陷不对人的态度；
以软件需求规格说明书为依据，摆出以前出现的经典类似问题，用户提供的反馈。
然后从该问题会引起的结果来分析，从用户的角度出发来说明缺陷的严重性。

[[i] 本帖最后由 hcn302 于 2008-3-31 15:49 编辑 [/i]]

回答

我觉得不必想的过于复杂：缺陷，就是缺陷，就需要修改，不存在说服的问题，而是强调各种工程师的职责的问题。

首先，对于一个产品的测试要建立好类似于数据库的defect tracking system，也就是说，测试工程师的职责之一是发现缺陷，然后记录在这个数据库中，并且让相应的开发人员/项目管理人员知道这个缺陷。即使由于某种原因这个缺陷最后没有修改，而被用户提出，这样的系统也会让“渎职“的原因一目了然。

第二，测试工程师的职责之二，原则上就是追踪缺陷的解决过程，一直到被解决为止。如果缺陷是可以重复的，除非领导们觉得可以暂时不用解决，否则必须督促开发人员解决，通过领导给开发人员施加压力也是必需的。如果缺陷不能重复，至少也应该记录下来，等找到重现的方法再解决。

第三，坚持对事不对人，在产品质量的把关上，决不让步。

[[i] 本帖最后由 Chen1981 于 2008-3-31 16:00 编辑 [/i]]

再現bug的操作過程,以實時說明

流程方面的问题吧。
好的流程，可以避免个人的喜恶影响。
比如对于不修改的缺陷，需要评审，这样通过测试、开发、质量保证3方面进行确认，看哪个程序员还嫌麻烦。

要努力造成下面的趋势：程序员不修改缺陷比修改缺陷还要麻烦。

如何让猫吃辣椒，抹在屁股上即可。

1.分析原因。看看为什么开发人员不认可。最好在开发之前能和开发人员达成原则，这样都说的清楚。还要看为什么我认为是缺陷，开发人员不认为是缺陷。是不是理解不一致的原因。只要有耐心，一切都会解决的。

对于缺陷的看法，我认为缺陷这个这个词的含义过于广泛，人为因素比重较大，我觉得每个人的想法都有他的可行性，通过了解对方的意向，在了解相关的需求及开发后所产生的结果中，说明该缺陷的重要性及会带来的影响.为对于开发来说，他的对象是软件的本身是否能达到一个目的，而对于测试人员，软件是一个综合性的东西，涉及很多方面，如果没有达到理想中的一个状态，那就会被视为一个缺陷。站在客户的角度，他们的目标是理想的，一个比较虚的东西，也不排除理想的过度化。做为一个测试员，他的目标也是希望把它理想化，通过确实了解该软件所希望的结果来与开发人员进行沟通，说明缺陷的原因及预期的结果，至于是否与开发人员是否达成共识，须在在需求中加以确认，并且说明此影响所产生的重要性。

[size=3][b]要说服他人认可自己提交的缺陷是需要修改的[/b][/size]
[size=3][/size]
[size=3][b]我认为首先要证明自己提交的缺陷确实是缺陷。
[/b]要证明这个问题要从需求说明书、操作说明书等一些可依据的文档着手，对于不符合文档要求的必然是缺陷无疑（至于这些可依据的文档质量这里不做考虑），只要证明了是缺陷就必然要修改；[/size]
[size=3]
[b]其次，要给提交的缺陷定严重级别。
[/b]缺陷的严重级别是针对缺陷造成的结果以及对客户的使用影响程度来分级别的，自然越严重的缺陷越应该优先考虑修改；

[b]再次我认为是沟通的技巧。[/b]
与他人沟通时，测试人员只是要说明这个缺陷的存在，不是针对某个人在某些代码段有bug，也不是完全成为一个用户对软件的缺陷表示深恶痛觉，应该和他人（主要是开发人员吧）站在同一个立场一起来分析这个缺陷确实是存在的。

[b]最后是公司的制度。[/b]
公司的测试管理制度要规范，尤其是缺陷的管理，要做到责任落实到个人，不能有责任不明确情况出现，否则也会影响修改提交的缺陷。

个人意见，共同学习[/size]

[[i] 本帖最后由 caoqd 于 2008-4-1 08:59 编辑 [/i]]

1. 明确缺陷定义
2. 建立缺陷管理规范
3. 严格执行规范
4. 提供缺陷的影响范围
5. 如有争议需有测试、开发、项目主管共同处理

BUG要能重现,并能提出该BUG带来的后果!

先对自己要提交的BUG,自己进行分析,该BUG对系统会造成什么后果,并在适当的时间内
给开发人员重现该BUG,并强调该BUG是可再现和经常出现的,而且该BUG在用户使用中是不可接受的;
如果开发人员坚持不修改,只能把BUG提交到开发经理或者自己主管部门,并把BUG的问题重复说明所带来的后果,并再一次重现该BUG;
最后的定夺,我们只能交给了管理层,自己只能做的是能把BUG切实能模拟出来,和说明该BUG带来的后果!

用软件质量铁三角来控制！
技术：重现缺陷，保证缺陷修改的必要性，并控制修改引起的后果
组织：通过公司制度来明确职责，必要时要求领导运用强硬手段，保证缺陷修复过程的顺利实施
流程：为缺陷从被发现到被修复有一个清晰，规范的过程，测试人员在过程中不至于自乱阵脚

俺来说几句:
缺陷需要修改,如果只靠测试人员去说服恐怕是远远不够的.质量保证工作强调的是法治而非人治,还是要从制度流程上去规范,才是比较恰当的办法.
比如:产品正式提交给客户之前,如果有内部评审的话,测试组的意见当然也作为重要的参考依据.如果真的存在争议很强的BUG,必然在评审过程中有所体现,产品不会顺利通过评审.
再比如,项目组要对产品进行回归测试,测试组可以要求项目组反馈上轮测试中对BUG的处理结果,并将此作为回归测试的进入条件;与项目管理部或者QA进行良好的配合,对BUG的处理结果进行记录监控,还可以与人力资源部门联合制定相关制度,将BUG的处理情况纳入到考评体系当中等等.

方法还有很多,不一一赘述.在此给出质量管理的原则(4个凡事),相关制度可以按照以下原则来制定:
凡事有章可循,
凡事有据可查,
凡事有人负责,
凡事有人监督.

[[i] 本帖最后由 bht2000 于 2008-4-1 11:07 编辑 [/i]]

说几句

.  竖立团队品牌===平时提交的bug需要有良好的复现概率和清楚的复现步骤条件;    提交的bug有统一的格式和标准;   提交的bug尽量有准确的定位和现象分析,日志跟踪等;   

.  竖立制度保证===和pm及dev leader有良好的沟通, 对开发和测试工程师不能达成一致的问题, 由marketing/dev/qe leader 和对应开发测试人员 甚至service leader进行多方会议. 避免日常工作造成工程师之间个人恩怨, 让领导们承担更多的沟通义务, 呵呵, 领导吗都是老油子了

.  竖立质量意识===平时加强灌输质量意识, 对反馈应该重视. 让所有人都面向商业

.  竖立统一用语===减少误解概率

.  竖立沟通标准===对所有的问题,一律对事不对人,所有人员平等,不得互相攻击等

总之,应该建立一个面向商业共同奋斗, 开发测试互相为内部客户的观念.
测试尽量为开发提供 描述清楚/复现/定位的bug, 清楚明确的bug性质和后果, 及时准确的状态跟踪和变更
开发尽量为测试提供 准确/详细的修复方案和技术咨询, 及时稳健的修复速度

最后, 领导应该定时team building加润滑油是必要大大的...呵呵

　　个人认为，这个其实就是一个如何相处之道的话题。当然，这里先需有定义清楚几个基础因素：
1、缺陷标准（类型）
测试人员与开发人员对于缺陷的理解有所分歧。可以从上级至下级所有同事统一制定一个标准，每个模块/子模块（类型）的缺陷分类和标准定义肯定有所不同，不能简单一个缺陷标准模式。如，WEB测试、手机测试、嵌入式系统软件等缺陷的测试，肯定不一样。
2、缺陷严重性
缺陷当然有重轻之分。根据对于系统质量和客户需求的影响，制定缺陷的严重性划分层次。
3、缺陷优先级
根据缺陷的严重性，定义缺陷的优先级。优先级高的先测试，级别较低的可以稍后再测试。注意，可能严重性低的优先级高！如，这个缺陷是客户无法容忍的、却是小bug。
　　满足缺陷基本要素后，我们再来谈根本问题——人与人之间的有效沟通。
其实，工作当中需要不断沟通才能促进良性循环工作。一旦人与人间有隔阂，那么劲道不往一处使，彼此唯心工作，肯定会相互影响。测试与开发人员是天生的“敌对”势力。如果大家能对事不对人，那么工作已经方便多了。
沟通的技巧：
1、要学会控制自己的逆反情绪
人在听到和自己观点不用的意见的时候，本能的反应就是抵抗。而在这种情绪的带动下，就很难清醒地分析对方的观点，听不进去对方说的任何话语。这个表现往往在开发人员听到测试人员的批评意见的时候。测试人员在开发人员对自己提交的缺陷不屑一顾后，往往更加生气记恨对方，死命找BUG，非整死他们不可。他们不改，先提交一大堆再说。这个是不对的。因为开发人员此时亦有逆反情绪，对你产生敌意。处理这样的问题的时候，首先是自我调节一下情绪，稳定几分钟要把上来的逆反情绪平息下去。然后带着平和的心理去交流报告，这样效果会好些。
2、要学会客观地看待别人的优点，并且客观地看待自己的缺点
测试人员别把开发人员当敌人，他们可是你同事啊！大家都有自己的性格特点和特长。每当你找到bug、提交缺陷时，他们就得重新开发，心情肯定不好。换位思考一下，如果测试人员被批评测试的东西都是垃圾，没什么质量，测什么测。那么你自己也会反驳，认为自己都是对的，别人都是错的。这个就是过多看重了自己的优点，忽视了自身的缺点。
3、学会适当反驳技巧，更应该学会尊重别人
如，开发人员认为你提交的这个不是问题。首先，一开始应该有了个缺陷标准。再者，在此基础上，不必针锋相对，仅需让有争议的缺陷重现后，代测试、开发组长或项目经理、需求提出方，三方鉴定，通常客户大都会支持测试一方，毕竟系统软件质量优先嘛。如果根本是开发人员狡辩，那么在众人面前，开发组长/主管自己会给出合理解释，并尽快修复缺陷的。省去测试方很多麻烦，大家都和和气气，不是很好么？还有就是尊重。如果你重视了开发人员的工作，尊重了他们的工作。他们同样也会尊重你的工作。因为人都有被别人认为重要的需要。彼此尊重了，相信没有人会对你提出的意见不虚心倾听的。
　　综上方法进行对话，相信各位会有个好的结果。^_^

这个话题其实我们应该先弄清楚一个事实，那就是你这个缺陷是否是真正意义上的缺陷（如是和需求相违背还是需求中不明确等）

【合理沟通，用事实说话】
如果是真正意义上的缺陷（如和需求相违背），说服开发或者设计人员的最好办法就是用事实说话，拿出需求进行佐证。当然这里肯定也就需要测试人员具有一定的沟通能力和沟通技巧，因为开发或者设计人员否认你的缺陷也肯定有他们的道理（比如对需求理解不深入，比如设计的其他模块或者功能能够掩饰或者忽略这样的缺陷等），所以适当的沟通技巧，沟通方式是测试人员所必须要掌握的具备的

【各级求证，客户需求第一】
如果不是真正意义上的缺陷（如需求不明确，但实际中可能会有一定的风险），这样的情况我们就可以各级求证，将这样的隐含的风险向开发或者设计人员提出，如果开发或者设计人员和我们没有能达成一致，那作为测试人员就应该将这样的缺陷（风险等分析）发给测试管理人员，请求他们来进行后续的沟通和决策。那么在这样的处理过程中，除了要有一些沟通能力和技巧外，责任心也是很重要的，因为正因为你的责任心或许就能让客户看到该公司在考虑设计产品时候的周全，从而提升公司的形象，抑或是体现出测试人员的作用

这次的论题其实涉及到了很多方面，上面的两点也仅仅是个人意见。
不过最后还是强调一点，作为测试，在这样的情况下，沟通是很重要的，适当的沟通技巧，处事技巧都不能缺少。