说服开发，修改bug
1.需要说明你提出这个bug 的依据2.给开发工程师讲清楚，业务的需要，为什么要这样做
3.若不这样做，回带来什么影响及后果
bug单一定要被修改？？
谁说我们提交的bug单一定要被修改？准确的说是bug单一定要被处理（修改、延期修改、驳回）！
关于bug，从它被发现到提交，我们已经通过了组内人员的讨论，并定义了它的优先、严重级别。
对于它的处理，考虑到软件的进度、成本，可能会依据它的级别做出如上的处理方法，这是无可厚非的事情！！
对于严重级别高、优先级别也高的bug，没有到交货期限，却被拒绝，我想有如下几种可能：
1、以前工作过程中经常出现失误，或小题大作，或无中生有，导致他人轻视，因此对于提交的bug不重视。
2、此次提交的bug在开发看来，不足以去修改，而我们看确实是重大缺陷。原因很可能是项目计划中没有把相关内容基线化，没有一个相同标准。
3、开发人员就是牛，不甩你，也不甩我们的领导。技术尖子不屑看你报告单。
解决：陈述自己发现的问题时，一定要做到有据可循，言简意赅，定位准确，一针见血！
基于上面问题
1、要从自己身上找原因，考虑是不是应该努力提高自身素质，赢取他人信任！严肃的提出本次bug单中问题所在，并提出建议性修改方法。
2、停下来，和上面领导商量，是不是应该把一些标准制定的完善一些、或制定一个独立的准则。
3、总有人能劝动那些自以为是的“牛人”，去找他们吧！一物降一物嘛！！
第一次回帖子，请楼主、同仁多指点！
刚入门级选手！ 我的感觉是：拿着需求说明书，让BUG再现。用你所能说服的方法去说服别人……当然最好在私下，不行的话在到会上，公开让经理来决定:) 感觉一般来说不会出现这样的问题吧!
首先,对于测试人员来说,既然是已经提交的BUG,那总体来说就是BUG;
而且对于有疑义的BUG,测试在提交应该和开发做交流,省的提交无效问题单
当然,对于楼主所提的情景,也是可以看到的,但不是很多.
既然是问题,开发就需要修改;
如果测试认为是问题,而开发认为不是问题:对于这样的情况,让老大们考虑去吧
不然要测试老大和软件老大,SE做什么呢?
在有流程或是规范的公司里,应该很少会碰到这样的问题;
:lol 个人意见哦~~~ 看到大家都说出了自己的办法，我也来说说我测试两年中解决此类问题的方法。
下面我就列举一下我的办法：
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 编辑 ]
回复 1# 的帖子
首先：要确定对需求的掌握等全面、深刻，避免出现理解上的错误，同时和测试沟通时能够做到有理可依，有章可寻。其次：BUG描述清楚，不存在歧义性，保证开发人员能够很好的理解该BUG。
然后：耐心的和他解释该BUG的原因，会出现的状况已经不修改会造成的危害，一般来说，开发人员不会出现态度很恶劣的情况，但是如果真的出现了，很多情况下也只能忍受，耐心的和他们解释。
实在不行，可以求助于项目经理或者质量管理部门，请求他们帮助你界定该BUG以及説服开发人员，但是要注意方法和态度，不用造成和开发对立的状态。 1.现和开发人员沟通，开发人员如果不修改，转到2
2.找需求人员明确
3.综合考虑是否修改（测试，开发，需求）
4.讨论后认为该问题不需要修改，那么把该BUG写人BUG库中，待问题在被用户提出后，可以有凭证。 我们在平时的测试工作中也遇到了这样的问题，目前正在有力的改善中，主要从以下几方面入手：
1、通过学习，提高测试人员的技术水平，主要体现在几方面：软件测试技术、与软件相关的计算机知识和业务知识、软件行业标准等；掌握了知识就等于掌握了强有力的“证词”，可以与研发人员据理力争；
2、与研发人员做好沟通，表明Bug不修改有可能带来的潜在危害；
3、在原有行业标准的基础上，细化适合自己公司和自己产品的质量标准，用标准来衡量Bug是否有修改的必要；
4、定期开展质量会议，召集测试人员、研发人员、QA、质量经理、客户代表等相关人员，从软件需求和客户角度出发，讨论Bug是否有修改的必要；
目前能做到的差不多就是这些，以后有好的主意再补充吧，也希望能从楼上楼下的各位处学到绝招。
[ 本帖最后由 cagemm 于 2008-4-1 20:24 编辑 ] 上面说得都很好哦！
测试工程师不容易，同样开发也不容易；双方需要换位思考，互相体谅；
先要证明自己提的确实是BUG，问题能重现，并且对自己提的问题需要分级，什么是紧急的什么是严重的等等；各级别的修改需要按优先级，先后次序来安排；然后再和开发沟通他不愿意修改的原因，是不认为是bug，还是没时间修改，或目前没能力修改等等；结合bug本身或开发目前的情况来开展沟通行进工作。
站在用户的角度看待问题
我来回答一下，可以么？:loveliness:首先，听开发人员是因为什么原因而拒绝修改此bug的。如果是因为修改这个bug会带来其他的更多的问题产生，我想开发人员拒绝修改也是有自己的理由的。作为测试人员也应该可以理解。但是站在用户的角度看待这个bug是否影响到了用户的正常使用。
如果没有影响到用户的正常使用，而同时修改此bug的会带来更大的风险，那作为测试人员，应该可以理解。如果影响到用户的正常使用了，即使修改会带来一些风险，那也必须修改，毕竟客户是上帝嘛！如果在这样的情况下，开发人员还是拒绝修改，直接发mail给PM，让PM及其其他项目负责人会议决定，并且沟通用户是否需要修改，我想测试流程是最重要的！
也不知道对不对，胡乱说了一些，大家别见笑啊:L 沟通很重要,从多个角度分析这个bug可能带来的影响,理智的与研发人员沟通.
如果还是不行,则可举出一些曾经出现过的案例(不修改导致的后果),从各个方面摆出事实. 如果真是缺陷，开发人员不修改，应及时向pm反映情况:) 第一步是要让开发认可你提交的缺陷是一个缺陷。
1.提交的缺陷描述一定要清晰，有必要的话可以附上截图。
2.和开发交流的时候注意语气和措辞，并再次客观地描述缺陷的严重性。
3.平时要保持好个人魅力和人际关系。
第二步是要让开发确认这个缺陷是需要修改的。
1.确认你所做的会得到测试Leader的支持。
2.让开发更多地知道这个缺陷的严重性和对系统造成的危害。
3.让开发知道这个缺陷对测试进度所造成的影响程度。
4.如果其他测试也发现类似问题，可一起和开发交流。
5.让测试Leader知道这个缺陷的危害和对测试进度造成的影响程度，并请Leader出面与开发Leader协调。
6.平时要保持好个人魅力和人际关系。 的确有些时候你提出的bug开发人员会觉得不以为然,不用修改,他们有时侯就说这个bug不是问题.其实一旦这个问题一旦被客户发现那就会对我们的产品质量大打折扣.
所以但我们遇到这中情况时千万不要冲动,这样反而会使开发人员更加反感.开发人员一般是站在技术和需求的基础上去考虑问题的,而他们往往对业务却不是十分明确,而对于测试人员一般是站在用户的角度上去考虑问题的,所以跟开发者在思想上就有一定的分歧.
对于测试人员我们不是要说服开发者去修改bug而是要以理服人,比如我们可以把开发人员叫过来进行bug重现,或者把出现bug的页面截下来把出现这种bug的操作描述清楚,以便于他们查找bug的原因.
当然良好的沟通很重要,作为一个测试人员具备良好的沟通能力这是很重要的.所以我们平时就要和开发人员建立一种和谐的同事关系,不要把开发部与测试部同事的关系划分的十分仔细.在和开发人员沟通是不要盛气凌人,态度要诚恳.相信有效的沟通一定会让我们拥有良好的工作氛围.
答复：作为测试人员如何说服他人认可你提交的缺陷是需要修改的？
我认为其实概括起来就是两句话“流程保证，实力说话”。1、 流程保证
缺陷的处理如果总是让测试人员去说服开发人员去修改的话，这说明流程方面有问题。如果有一个规范的缺陷处理流程，那么这个问题就会比较少的出现，具体来讲，可以在缺陷管理规范或项目公约中具体规定，什么类型的缺陷必须修复（例如流程类，数据类错误），什么类型的缺陷可以不处理（例如一些产品建议），这样就可以减少这种是否修改的争议。另外还有缺陷审核机制和缺陷集中会审（例如微软的BUG三方会议），这样对于是否修改由更高级别，更有经验的人来判断，不但节省时间，而且风险较小。在我目前服务的企业，对于缺陷的开发打回，还有严格的流程规定，例如打回后测试人员可以提交给哪类更高级别的人员处理等。因此，我认为流程保证是解决的根本之道。
有些企业可能不能做到这么规范，或测试人员实际是处在一个弱势地位怎么办。很遗憾，这是目前许多测试人员所面临的现状，那我想除了我下面将要谈到的一点“实力说话”以外，在流程方面，其实测试人员不妨做一些努力，如与开发人员达成一种类似于流程规定或项目公约一样的约定，这样对解决这个问题也是很有帮助的。最后，争取逐步把这些口头约定或非正式约定转化为规范，或正式规约，开发如果从实际中获益的话，也会全力支持的。
2、 实力说话
有了规范的处理流程，但总会有需要讨论和争议的部分，这是开发和测试的工作性质决定的，就像有些人形容的那样，一个是建造者，一个是破坏者，讨论与争执已经成为了测试工作的一部分。但我们争也要争的有道理，因此就要“实力说话”，这在流程不规范的企业就更加重要。是否修改缺陷，我们可以从客户场景，影响程度，风险等具体方面去分析，这就需要你在这方面有实力，有经验，说白了，就是有话语权。你说的有道理，有根据，这是说服别人的基本条件，因此还是需要我们不断积累经验，强化测试技能和业务知识，从而说服开发作出修改。如果仅仅针对说服开发修改缺陷这个问题来说，从本人以往经验来看，功能、性能方面的错误往往没太多，太大的争议，对于一些边界和极端的操作测试，或涉及到易用性和人机交互的缺陷争议的比较多，因此在这方面的实力积累尤为重要。
还有一点需要说明的是，对于“实力”来讲，除了测试、开发技能，业务知识外，沟通和交流也是一个不可忽视的重要能力，如何有技巧，有策略的进行问题沟通，这个就非一朝一夕所能练就的，但目前测试人员又特别需要这种能力去推动事情的解决，因此平时这方面需要注意积累，当然在往下谈，可能有些说远了。
如果上述两方面都欠缺的话（这是许多初涉测试的人员所面临的问题），该如何应对呢？我想不妨寻求一些必要的帮助（如更高级别人员，更有经验人员），这样既推动了问题的解决，又学习到了宝贵的经验，只要勤思考，总会有适合你的一些办法。
良好的操作记录习惯＋与开发的沟通＋客户的角度去讲述该问题的重要性
良好的操作记录习惯＋与开发的沟通＋客户的角度去讲述该问题的重要性 1 测试人员对自己的工作要专业，对于每个bug的处理有责任感。2 与开发人员，项目经理，客户多沟通，真诚的交流。 首先应该明确一点，测试人员与程序员或设计人员应该是平级的，因此不应该由测试人员来说服程序员或设计人员，标准流程应该是向项目负责人及销售人员提出，由他们站在项目的立场上协调解决。因此最重要的是说服项目负责人，让他明白该缺陷可能对项目产生什么样的影响。然后由项目负责人向设计人员或程序员下达修改指令会比较容易一些。如果项目负责人无法确定该问题是否重要，也可以通过召开项目核心成员会议来对该问题进行充分的讨论。一般在项目管理中比较忌讳测试人员直接将修改任务下达给程序员，因为可能有些问题在该项目中可能不是问题或者项目负责人有其他更合理的考虑。之所以要通知销售人员是因为他与客户的距离最近，最了解客户的真实意图。如果能够争取他的支持，在讨论会上你会增加一个重要的盟友。尤其是他如果在你发言的时候附和的话，别人就很难提出反对意见了。至于程序员和设计人员，只要和他们保持较好的个人关系就可以了，没必要和他们发生直接的冲突。 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交涉。 4#讲得不错，顶一个
