51Testing软件测试论坛

标题: 测试人员如何说服他人认可你提交的缺陷？（08-03-28）（获奖名单已公布） [打印本页]

作者: 51testing 时间: 2008-3-28 17:48
标题: 测试人员如何说服他人认可你提交的缺陷？（08-03-28）（获奖名单已公布）

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

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

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

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

作者: Elaine126 时间: 2008-3-28 22:40
标题: 回复 1# 的帖子
其实,有时不需要考虑太多，平时多沟通，认真对待工作，态度端正，问题也就解决了。

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

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

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

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

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

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

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

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

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

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

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

作者: fighting 时间: 2008-3-29 21:58
前提：测试人员对所测的工程非常的熟悉（不熟悉的提问题前最好找个文档或者规范查一下，或者也可以找个这方面的专家确认一下

）
1.功能问题：功能方面的问题在需求规格说明书中都有描述，需求规格说明书是开发人员和测试人员之间共同遵守的规范。除非规格变更，一般不需要说很多开发人员都会修改

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

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

暂时想到这些。。。

作者: cityyard 时间: 2008-3-29 22:31
啊诺~~~这个问题其实非常不好回答，实际情况往往很复杂……
就我个人经验写一点感受吧~~当然了，诸如要写清楚现象，尽量详细报告等是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必须修之类的话不必出自测试人员之口，正如汽车发动机只需要考虑转呀转，具体哪个路口该拐弯也让发动机来考虑就不必了。

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

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

作者: shiruili215 时间: 2008-3-30 00:10
标题: 回复 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都还是愿意去解决的。

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

作者: lanmiaoer 时间: 2008-3-30 08:38
没有这方面的经验有待学习！

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

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

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

作者: sunnyfeng 时间: 2008-3-30 11:24
简单一句话：摆事实，讲道理，冷静对待。

作者: getfly 时间: 2008-3-30 14:31
将bug清楚地重现，让他亲眼看到，然后再说服他！

作者: liangjz 时间: 2008-3-30 23:54
1 确实验证该BUG 确实是一个问题（需求、代码...都可以）

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

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

作者: 懒爸爸测试 时间: 2008-3-31 00:08
对自己测试出来的问题进行截图和屏幕录像。然后再晓之以理，动之以情。。。哈哈哈

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

作者: 艳子 时间: 2008-3-31 11:25
我是一名初做测试的实习生,也遇到类似的问题,很苦闷阁

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

作者: zuojingqin 时间: 2008-3-31 14:15
标题: 回复 1# 的帖子
发生这种情况真是太多见了，我一般不会直接和开发人员争执。好点的方法可以和项目经理，或是你的LEADER一起开会讨论，来确定此次的BUG的优先级，来决定是否在这期修改；

作者: ami冰河 时间: 2008-3-31 14:15
1.基于完善的《需求说明书》，在测试人员对需求说明书有足够了解的基础上，谈论这个问题才能有所依！

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

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

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

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

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

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

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

一点拙见，大家指教

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

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

作者: Chen1981 时间: 2008-3-31 15:56
标题: 回答
我觉得不必想的过于复杂：缺陷，就是缺陷，就需要修改，不存在说服的问题，而是强调各种工程师的职责的问题。

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

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

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

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

作者: jotwins 时间: 2008-3-31 16:33
再現bug的操作過程,以實時說明

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

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

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

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

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

作者: caoqd 时间: 2008-4-1 08:57
要说服他人认可自己提交的缺陷是需要修改的

我认为首先要证明自己提交的缺陷确实是缺陷。
要证明这个问题要从需求说明书、操作说明书等一些可依据的文档着手，对于不符合文档要求的必然是缺陷无疑（至于这些可依据的文档质量这里不做考虑），只要证明了是缺陷就必然要修改；

其次，要给提交的缺陷定严重级别。
缺陷的严重级别是针对缺陷造成的结果以及对客户的使用影响程度来分级别的，自然越严重的缺陷越应该优先考虑修改；

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

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

个人意见，共同学习

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

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

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

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

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

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

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

作者: jacky_zhuang 时间: 2008-4-1 12:45
标题: 说几句
.  竖立团队品牌===平时提交的bug需要有良好的复现概率和清楚的复现步骤条件; 提交的bug有统一的格式和标准; 提交的bug尽量有准确的定位和现象分析,日志跟踪等;

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

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

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

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

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

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

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

作者: kevin_swpi 时间: 2008-4-1 14:50
这个话题其实我们应该先弄清楚一个事实，那就是你这个缺陷是否是真正意义上的缺陷（如是和需求相违背还是需求中不明确等）

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

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

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

作者: guanxiaoqin 时间: 2008-4-1 15:21
标题: 说服开发，修改bug
1.需要说明你提出这个bug 的依据
2.给开发工程师讲清楚，业务的需要，为什么要这样做
3.若不这样做，回带来什么影响及后果

作者: 毛头 时间: 2008-4-1 16:21
标题: bug单一定要被修改？？
谁说我们提交的bug单一定要被修改？
准确的说是bug单一定要被处理（修改、延期修改、驳回）！

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

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

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

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

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

作者: songwj0806 时间: 2008-4-1 17:21
我的感觉是：拿着需求说明书，让BUG再现。用你所能说服的方法去说服别人……当然最好在私下，不行的话在到会上，公开让经理来决定

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

个人意见哦~~~

作者: duola1119 时间: 2008-4-1 17:33
看到大家都说出了自己的办法，我也来说说我测试两年中解决此类问题的方法。
下面我就列举一下我的办法：
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.服从领导
如果项目经理说不改，你就不必费脑筋想办法让他们改了！

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

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

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

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

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

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

作者: 卧龙公子 时间: 2008-4-1 22:01
标题: 站在用户的角度看待问题
我来回答一下，可以么？

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

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

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

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

作者: gforg 时间: 2008-4-2 09:47
如果真是缺陷，开发人员不修改，应及时向pm反映情况

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

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

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

作者: buzz 时间: 2008-4-2 14:37
标题: 答复：作为测试人员如何说服他人认可你提交的缺陷是需要修改的？
我认为其实概括起来就是两句话“流程保证，实力说话”。

1、流程保证

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

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

2、实力说话

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

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

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

作者: hhyghr 时间: 2008-4-2 16:57
标题: 良好的操作记录习惯＋与开发的沟通＋客户的角度去讲述该问题的重要性
良好的操作记录习惯＋与开发的沟通＋客户的角度去讲述该问题的重要性

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

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

作者: lzz 时间: 2008-4-2 18:18
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交涉。

作者: liulinzhu 时间: 2008-4-2 20:16
4#讲得不错，顶一个

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

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

作者: 贝贝酷 时间: 2008-4-3 11:26
热忱并且耐心（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 ）
外交手段和适应能力不能替代谨慎的需要。开发人员经常会找借口说因为他们没有意识到（或者你没有告诉他们）那个错误有多严重所以他们拒绝修复它。用足能够清楚展示风险和问题严重性的方法设计你的错误报告和测试文档。甚至更好的办法是召开一个会议并且向他们解释那些问题。

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

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

作者: sunny_f 时间: 2008-4-3 17:14

原帖由 jacky_zhuang 于 2008-4-1 12:45 发表
. 竖立团队品牌===平时提交的bug需要有良好的复现概率和清楚的复现步骤条件; 提交的bug有统一的格式和标准; 提交的bug尽量有准确的定位和现象分析,日志跟踪等;

. 竖立制度保证===和pm及dev leader有良好 ...

里面有bug:是树立不是竖立呵呵

作者: gxc2 时间: 2008-4-4 03:42
测试人员不仅仅是做测试的，她是一个服务类型的行业，前面技术支持与客户，后面才是开发人员，她是个纽带。

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

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

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

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

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

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

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

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

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

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

作者: ajoo 时间: 2008-4-5 16:29
以理服人，如果不行那就欺蒙拐骗好了，只要能达到效果就行

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

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

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

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

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

作者: muerte 时间: 2008-4-7 12:54
拿出数据.来证明他这么做是不合理的

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

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

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

作者: red-hat 时间: 2008-4-8 14:10
这么多获奖的啊!!哈哈,羡慕

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

作者: jinpeng99 时间: 2008-4-11 15:46
学习了

作者: sinakevin 时间: 2008-4-16 13:06
简单的说：
1、和开发有个好的关系，有一点BUG他们可能就会帮你修的
2、证据，需求方面的证据

其他同志，多补充

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

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

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)