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

这个问题其实非常不好回答，实际情况往往很复杂……
@we,{8W6{];Q0就我个人经验写一点感受吧~~当然了，诸如要写清楚现象，尽量详细报告等是QA人员应有素质，这里篇幅原因暂且搁置不谈。
8],_J"r)]
o?y051Testing软件测试网KN)X7`k'u4|;s
首先，开发方必须提供完整详细的式样书和制限事项。式样书是测试人员测试的基础，测试人员如果按照式样书测试得到了不一样的或者奇怪的结果，那么必然是bug无疑，没有任何可以争论的余地；如果测试人员执行了式样书上没有写的动作，得到了一个奇怪的结果，那么首先去制限事项里面找，如果制限事项写了，那么意味着开发者知道这个问题并且还在开发中，那么OK暂时放过（注意是暂时），如果制限事项也没写，那么再看这个动作是不是用户可能做出来的动作，举个例子如果一个软件的某个命令完全封装在内部，调用时一定会以普通用户身份执行，那么测试人员使用root测试出来的问题就是无效的（注意，当然封装的命令可能因为封装错误用root执行了，但那是另一个bug）；如果测试人员的动作虽然式样书没有，但是却是用户可以做出来的，那么抱歉，这个问题必须修改，而且还要围绕这个被式样书遗漏的问题进行拓展。51Testing软件测试网{`oO,s$RM
51Testing软件测试网6@C
ekqp V
其次，测试开始前由开发方review测试方的测试计划，并针对测试方对式样书的疑问答疑。这一点有两个好处，一个是开发方可以尽早指出哪里测试不合理，哪里测试薄弱，另外也可以减少以后因为双方理解上的差异带来的时间浪费。虽然这会占用一点开发人员的时间，但是磨刀不误砍柴工。
ew3b1|9x6F)yP~_051Testing软件测试网@L]!x*f
第三，建立完备的版本管理系统，这个系统如何建立前面的每周一问已经详细讨论过了，目前要补充的就是，版本管理中必须把式样书和制限事项一起加进去，开发者发布了0_0_1版，其中制限事项是文件数目不能超过1M个，0_0_2版开发者取消了这个制限，那么必须在发布作这个版本的同时写明这一点，测试人员才能据此测试。严格的版本管理可以有效减少纠纷，如果测试人员使用0_0_1版测试1M+1个文件失败，那么是无效测试，如果使用的0_0_2版，那么就是bug必须修复，无可争论。
2^zf+d(N051Testing软件测试网Q v)k$s#f9h{
有了上面三条，大部分问题差不多能解决了，但是还是不行，差在哪里？主要还有两个问题，一个是测试方可能指出一些跟个人喜好相关的地方，比如测试方可能指出GUI一个警告信息窗的字体太暗而且不显眼，不容易被注意到，这类问题无法用上面三条来解决，因为是否容易被看到本身就不好界定；另一个问题就是（尤其是到了测试后期），测试人员连续跑了好几天测试忽然程序死了，再来一次又没事了，告诉开发人员这个现象，开发人员也解决不了，因为很难再现，如果是测试环境问题还好，如果真的是软件缺陷那被用户遇上就很严重，但是这种问题无论是让QA无休止的尝试再现还是让开发者没头没脑的调查都很难说得过去。
f _,L5j^3B0
U@/D*B]`sJ0于是我们加上一条
%q!Z
BIt&t'U0第四，仲裁机制。QA和开发者并不直接对话去讨论一个问题是否要修改，我们首先对开发者实行残酷的有罪推定，也就是QA报告的问题开发者都必须修改，如果开发者认为无需修改必须给出理由和证据，围绕这个理由是否成立，QA和开发者双方展开讨论，这个讨论必须每一步都使用缺陷管理工具记录下来。最终要改还是不要改由一个仲裁机构来决定，当然了这个仲裁机构其实就是更上层的管理者，他们手里是日程计划，市场需求，对手状况等，他们根据这些更高层信息决定一个问题是否值得去修。
H A5k#Pm0\0
8IU3pbQn E0写到这里细心的读者已经发现，题目问的是怎样去说服，我却大谈测试管理方法。其实我个人觉得，建立一个宏观的良好机制比起一个测试者去唇枪舌剑的和开发人员辩论更加有效，我们追求的是什么，不就是效率么。因此我个人以为真正的测试人员职责就是报告缺陷，至于这个缺陷是否应该被修复先用机制套，套不上再来仲裁，仲裁过程QA leader全程参与，测试人员要做的只是在仲裁过程中客观的回答每一个问到自己的问题，至于什么我认为这个bug必须修之类的话不必出自测试人员之口，正如汽车发动机只需要考虑转呀转，具体哪个路口该拐弯也让发动机来考虑就不必了。51Testing软件测试网/V-O&i.Hur_u

==================================================================================

,p}I~M)dH+N7f01，和开发人员达成共识：开发人员的开发工作和测试人员的测试工作的出发点是一致的，都是为了给公司创造利益。达成这个共识后，开发人员就不会对测试人员和测试人员的工作有抵触情绪；再在这个认识的基础之上，和开发人员一起讨论如何修改代码他们的Effort比较小（如果你有一定的开发能力）、何时进行修改（由于各种原因，可能需要稍后进行一起修改）等。51Testing软件测试网4~D |b&Y
D x u$~"g1X/u

hEk9fz?
{8X9i%n|02，与开发人员建立良好的关系，包括私人关系。如果你的能力强，开发人员可能会把某些工作交给你，让你帮忙做。这时可以积极接受，尽最大肯能帮助它们。我的一个同事曾发现某个Bug是由于没有写对一个业务逻辑比较复杂的SQL语句，于是他自己写了，就把开发人员一直困扰的这个问题解决了。从此以后，开发人员就非常支持我们的工作了。
1R/P5yU\*mq0
eh@G$Z[,TV03， 系统和软件最终是要交付给客户的。只有他们认可了，同意付款了，开发人员和测试人员的工作才算有意义。因此，我们测试人员一定要站在客户的角度去使用软件，去测试人员。我们要考虑客户会怎么样使用，他们可能会遇到什么问题。这样可以减少许多直到交付给客户后才会发现的问题。从这一点上来说，我们也要让开发人员站在客户的角度去理解为什么这个Bug一定要修改。曾经有许多UI上的错误，开发人员举手之劳就修改了。可是就是不修改，他们认为不需要。我就是让他们先把自己设想为一个客户来使用此系统，然后说服他们去修改的。51Testing软件测试网 ` N^NaD^*UW}r!@4M`
51Testing软件测试网9_M&b}6S(~v`
4，如果有条件，建议拿出你的数据和证据去说明为什么一定要修改它。如，进行性能测试后的测试报告数据、经客户确认的需求说明书等。51Testing软件测试网9X"g@S)P/h1y J

\0u%gc`%x0总之，既要让开发人员知道你是站在他的立场上考虑问题的，同时又要站在客户的角度来说明为什么需要修改这个缺陷51Testing软件测试网 K/]T/n8\bE ]

X5Rx.C"o,jiR5T0=================================================================================51Testing软件测试网F2k*W)K@{9I

OyTUf5?!H^`O0到大家都说出了自己的办法，我也来说说我测试两年中解决此类问题的方法。
lFw;d{0下面我就列举一下我的办法：51Testing软件测试网I2~+XLy8B
1.针对开发人员懒惰的心态。
dES7kQ*L0开发人员在项目测试初期对于发现的BUG，往往是非常积极的态度，但是随着项目的测试的结束时间的到来，开发人员就会形成一种懒惰的心理（测试人员也不例外），这种懒惰的心理就会使得开发人员面对那种不是崩溃或者严重性的错误进行公认或者设置为不解决。面对这种情况，测试人员唯一的办法就是将BUG信息传达给项目经理，并讲述不修改这个BUG对项目有可能造成的影响，这是解决这种类型问题的最有效办法，懒惰的项目经理除外。
c_1a2@Gh02.针对开发人员对测试人员的个人感情因素51Testing软件测试网&v w-g{^9x(n,S
不知道你们遇到过开发人员对测试人员因为个人感情因素，而故意不对你提的BUG进行修改的问题。有些初级开发人员开发的模块，错误多多，单元测试又做的不足，导致了他所负责的模块的BUG远远超出了其他人的数量。项目经理的指责加上自己能力的限制，面对越来月多的BUG产生厌倦，对提BUG的人员产生厌恶，这种问题其实不好解决。每天必须去开发部10趟以上，而且必须和对你有厌恶感的人侃些工作之外的话，如果他怎么说话，你就和屋内其他人侃，营造幽默气氛，并在开玩笑之余讲述测试的困难，侧面说出你的无奈。如果公司有些什么活动的话，是个很好的机会，记住增加沟通。51Testing软件测试网"quj9j+w[3kj
3.针对需求不符类型的BUG51Testing软件测试网6q-YL'sk
满足用户的需求是项目质量的分量很重的评价标准，不满足需求用户需求还提什么软件质量。51Testing软件测试网5}@y#rW3fZ'w
开发人员只了解自己负责的部分模块，不懂得整体架构，只知道与其他接口取变量，传变量。51Testing软件测试网+r;|9{!WB-S
测试出的需求不符的BUG必须将需求中提到的需求点粘贴给他看，概要设计中提到的设计粘贴给他看，可以截图给他或者以附件的形式上传给他，这叫有理可证。
LY^3@.}G
U04.试运行前三天遇到的问题51Testing软件测试网/f+j]/c.lBl
项目测试后期，马上就要拿到线程试运行的时候出现的BUG是最关键的，这个时候遗留的BUG也是项目经理最关注的。如果你想让他们把你提的问题修改，那你就把你的问题设置为严重错误，这个时候即使是一个小小的界面问题，我们都有理由认为它是严重的。51Testing软件测试网aPj;[ B+yB
5.针对不容易重现的问题
2o5GjH$x x:u c0测试过程中不容易重现的问题也是很多的。自己悄悄测试的时候出现了，开发人员一来看，问题就没了，开发人员看不到的问题，他们当然不会改。所以在测试的过程中尽可能的不要忘记3分钟前你所做的一切操作，并且将问题现象截图保留，因为这你是重现BUG和讲述问题的关键。51Testing软件测试网 bXu'|4Q/h
6.制定BUG提交规则说明书51Testing软件测试网4e ZkaG"tu'I6Ji
强制性的规定测试人员提交的BUG，通过BUG提交规则说明书规范测试人员BUG。提高BUG的有效率。并根据BUG提交个则说明书制定开发人员
}BIEg+x0BUG修改标准，符合标准的必须由开发人员作出处理。
3}.?V\;h+s07.服从领导51Testing软件测试网J4}#d)ra?
如果项目经理说不改，你就不必费脑筋想办法让他们改了！51Testing软件测试网)K.E+@5?Wk_
51Testing软件测试网y7N:b,s%S