测试如何更有效说服研发去修改bug？（08-10-27）（获奖名单已公布）

testontest

高手总归是高手呀！！经验丰富、思路清晰，很值得我们测试界的同行学习或研究。

hansonhy

根据我个人经历和工作经验来说

1，首先确认这的确是一个BUG，BUG分为两种，一种软件本身存在设计或编码缺陷。这个一般开发都会主动改，因为直接影响软件质量。
  第2种，测试人员认为会设计影响用户操作或功能不符合用户要求的功能。这种情况很可能被拒绝。

2，上报测试经理，在提交缺陷时，写清楚缺陷等级和真实环境什么情况下必定或可能引发这个缺陷，会造成什么样的后果，甚至多大的经济损失。让测试经理去和开发经理开会争论，实际后果大的BUG一般都能通过讨论决定要改。

3，依靠个人口才，跟开发人员讲道理。讲用户使用难处，可能引起产品损失，造成他的奖金蒸发。开发人员如果考虑到改动难度不太大，可能会克服懒惰思想改正。

4，强行争论，吵架，是没什么用的，毕竟以后还要合作。那样以后他不会给你帮助的。

konglingchao062

工作当中经常会遇到这种情况，测试人员发现bug，但是开发人员却并

不承认这是个bug而找理由不去修改。虽然上报经理让经理命令开发人

员修改bug是有效的方法，但是如果找经理的次数过多必然会引起经理

的反感，那么怎么班呢？我认为可采取如下几个步骤：
1.首先你要跟开发沟通，讲明需要修改的必要性。当然要注意沟通的

方式，切忌强行争论，要注意说话的语气等，如“您能告诉我不需要

的修改的原因吗？...”
2.如果开发坚决认为不用修改，那么你要再次分析此bug是不是真正的

bug，如果你觉得是要修改的，那么你写好一个bug备忘单，然后再找

开发沟通（同样是和平商讨），如果他不改，那么让他在bug单上签名

，让他来负责。一般情况下只要让他签字负责，他就会自愿去修改的

。
3.如果你觉得此bug需要上报经理，那么你同样要与开发沟通，商议一

起去找经理，让经理决定该bug是否要修改，或确定修改的优先级。（

你要确保开发人员知道你去找经理，切忌背着开发找经理，这样会影

响你们的合作。）

zengyixun

由于我做过两年的开发，5年的测试，在测试过程中，自己也做过些测试工具，也有测试人员对我的测试工具来进行测试的经历，所以我首先站在一个开发人员的角度来看，什么样的bug与测试人员能说服我呢？要说这个问题，我们首先要有有一个假定：假定开发人员不是一个神经病（多数其实都不是，如果是，那么应该由人力资源部负责），既然开发人员不是神经病，那么你一定要相信他对于自己所做的模块也是抱着认真负责的态度，希望把功能顺利实现，而不会出现什么意外状况的，所以当有人给我提出一个bug是我确实没有想到的，而又实在的影响到这个模块的功能，我做为一个开发人员会考虑修改这个问题，如果这个问题还有一点点深度，我会更加开心，抱着挑战的态度，也抱着赶快把此功能搞定的急迫心情去修改它，由此得到一个好的绩效与认同，所以像这样的bug，需要测试人员来说服我么？当然不需要。然后再看看什么样的问题我不喜欢，曾经我做过一个测试工具，新来的测试人员对我的工具进行了测试，在测试的同时，也使新人学习了各种业务知识，在这些测试者中，我就很明显的对那种能提出功能性错误，或者我考虑不周造成的错误（这一定要用专业的测试方法才能测出的）的新人，我会报着一种对他的欣赏的态度去修改他提出的问题，而对那些，没事找事，总是按自己的主观意愿提出一些使用上问题的人，给以鄙视，比如新来的测试负责人，在我修改完所有问题后，叫我把下拉框改成tab页，嘿嘿，你喜欢tab页，我就喜欢下拉框，测试部难到没有别的事情做了吗，做这么无聊的事，也就是说，有关操作习惯问题本就是你有你的习惯，我有我的习惯，凭什么就说你的习惯是代表了广大人民群众呢？是吧？
    看了上面一段，相信大家就知道了什么样的问题会得到认同，这样的问题，根本不用你去说服谁，但是，这个世界如果如此简单，就不会有战争了，是吧，所以，我刚才说的只是开发人员的立场，说这些只是让大家明白一个心理特性，并不意味着，开发人员的这种立场在任何场景都是正确的。
    所以，还有一个测试人员的立场问题，对测试而言，我们有各种测试方法去发现bug，有时有的测试方法做出来的测试结果确实发现了问题，但这个问题可能会引发开发人员的反感，这是因为开发人员对测试的工作不了解造成的，比如，我们用边界测试发现一个问题，但开发人员会说，谁会去输入这样的数值呢，在实际工作中，人家是不会这样操作的，所以拒绝修改这样的问题，怎么办呢？这个时候，其实如果一味的让每个测试人员去与每个开发人员讲道理做宣传，其实效率是低下的，而应该把这一类问题记录下来，由测试部门进行一个评估，然后与项目负责人进行沟通，在一个适合的时间点（致命问题、严重问题都改得差不多且还有时间的时候），对此类问题进行一个全面的修改，如果是一个好的公司与部门，还会就此类问题进行总结归类，并对此类问题定义出严重程度与修改的优先等级，如此就完成了一项过程改进，当下个项目出现类似的问题时，一个制度化的结果已经在这里了，开发人员再次见到类似问题，自己就会在已经把致命与严重问题修改完成的情况下，对此种等级的问题再进行修改，而不需要再次做没有必要的沟通了。再比如使用操作性问题，其实就是一种体验测试，如果这种问题由每一个测试人员零星提出，不但没有科学调查与说服力，也会得到开发人员的白眼，所以有关使用方便的问题，也应该单独的当成一个整体事件去做，而立下科学调查的标准化决议，当项目组与测试部与市场都搭成统一标准后，做这些事，还会有阻力吗？
    我看有的人的解决方法是人情世故，有的人的方法则是权利压人，还有的人的方法是每回都去以理服人（以德服人，怎么感觉测试总是低声下气的？难怪人家不改你的问题），还有总总方法，但不是有后遗症，就是回回都要如此，搞得效率低下，所以真正的方法应该是，把一项不太受到开发人员重视，但又确实是不可小视的那些问题，想办法通过外交努力，搭成统一的科学的标准化的制度化的行业规范，当一个制度在这里时，没有人会觉得你是和他过不去，只会觉得，这是制度的要求，我们本就都该这样做，就好像你迟到了，你不会认为是人事MM对你有偏见，也不会认为人事MM水平低，不懂得以人为本的道理吧？当然不会，因为几点上班是一项制度。有人见过搞人力资源的人在网上发贴问：请问人事如何更有效的说服员工们不要迟到呢？呵呵，一家之言哈！
    至于那些根本就不是问题的问题，求求你们千万不要用你和开发人员的好关系，把不是问题的问题给修改了（还好有问题审核与软件配置管理），我的主呀，阿米托佛！

[ 本帖最后由 zengyixun 于 2008-11-1 01:30 编辑 ]

zdlzx

1、征询需求分析人员的意见
因为需求分析人员接触真实的用户操作信息更多，他们可以帮助鉴别部分在业务角度看来确实不可能发生的情况。这种情况下，测试人员即使觉得有从逻辑严密性而言有漏洞，但发生概率很小，而修改比较麻烦或者有风险，开发人员不改动代码更合适。

2、冷处理
如果不是影响很大的问题，不用一定这次要一决雌雄，让对方说服自己。有时简单地定一下，这次就不修，看看上了线之后的一段时间有没有问题。没有人永远都是对的，也许你觉得自己很有道理，但这次经过事实的检验，你的判断不尽准确，亡羊补牢再修bug好了。

3、让高一级的人来决定
如果对于这个bug是重要还是不重要的性质难以取得共识，而一个开发人员和一个平级的测试人员争论不休是很难得到结论的，此时可以让PM或者测试经理介入，看看他们决定怎么做。

haomiaohaiyang

吸取各方精华，顶一下

beckhans

呵呵 拿出你的理由让，开发人员低头！
这是我的做法！

eyec

刚上51Testing就发现这样的好贴，不上51Testing真亏，哈哈！！

starvip-testing

新人看不太懂顶一下

01047418_lzz

牛人啊，我太喜欢你的回答了

qinglu000

学习了