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

艳子

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

juzi0613

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

zuojingqin

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

ami冰河

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

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

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

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

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

shenlake

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

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

lucky_snow

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

一点拙见，大家指教

hcn302

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

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

Chen1981

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

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

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

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

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

jotwins

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

luming

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

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

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

zx198774

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

用户名密码

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

caoqd

要说服他人认可自己提交的缺陷是需要修改的

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

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

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

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

个人意见，共同学习

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

null2

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

fengyun32

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

tidy_wwwww

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

bht2000

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

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

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

jacky_zhuang

.  竖立团队品牌===平时提交的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、学会适当反驳技巧，更应该学会尊重别人
如，开发人员认为你提交的这个不是问题。首先，一开始应该有了个缺陷标准。再者，在此基础上，不必针锋相对，仅需让有争议的缺陷重现后，代测试、开发组长或项目经理、需求提出方，三方鉴定，通常客户大都会支持测试一方，毕竟系统软件质量优先嘛。如果根本是开发人员狡辩，那么在众人面前，开发组长/主管自己会给出合理解释，并尽快修复缺陷的。省去测试方很多麻烦，大家都和和气气，不是很好么？还有就是尊重。如果你重视了开发人员的工作，尊重了他们的工作。他们同样也会尊重你的工作。因为人都有被别人认为重要的需要。彼此尊重了，相信没有人会对你提出的意见不虚心倾听的。
　　综上方法进行对话，相信各位会有个好的结果。^_^

kevin_swpi

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

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

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

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