" 每周一问"问题征集

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

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

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

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

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

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

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

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

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

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

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

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

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-开发人员实在不修改缺陷，提示他除了问题非测试人员责任

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

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 开发有上级的。说服他上级像开发施加压力。这是下策

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

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