• 关于bug的沟通


    关于BUG的沟通

      一个人要去做一件事情,一般来说是按照自己的意愿去做的,如果不是自己想做而是被要求这么做的话,心里一定会留下点不愉快,特别是那种有自信有自己主见的人,比如说开发人员,当测试人员发现一个BUG,然后告知开发人员后,开发人员之所以会去修改BUG,是因为他自己认为的确需要修改,而不是因为你提到要改他才改的,所以当他认为不需要修改的时候,肯定是有自己的想法和理由,不妨理解下他们,合理的就可以接受,不合理的话,也不要强制的让他去修改,试着解释给他听,让他心甘情愿的去修改,这才不会让他心里产生不愉快的情绪,开发人员和测试人员彼此间的关系才不会弄得很紧张,如果强制性的让他修改多次的发生,那么开发人员会对测试人员慢慢的产生成见,这样就不好沟通了。

      有时候也许是描述BUG时的语言表达有问题,或者是开发人员的理解能力有问题,描述BUG一遍后,开发人员可能还会有不明白的地方,需要再次沟通,如果当场演示就比较容易理解了。可能我们都没有问题,只是根据自己所知道的信息和对方所知道的有所误差,有些共识还需要互相确认,所以提交BUG时不仅仅是简单的描述一次,而是多次的沟通和确认。

    首先要找需求文档,看有没有对预期结果进行具体说明,从而提高说服力度。其次要确保自己的bug能够重现。
    再次,分析一下自己bug的级别,如果只是建议性的bug可以保留,但是也要在bugzilla等工具上记录;
    如果bug级别比较高,就要跟开发人员有效沟通,耐心讲明这个bug的危害以及重现步骤等,不行就要跟测试经理或者开发经理联系,说过bug的严重性,进行问题评估,一起讨论解决这个问题。
     
    找出是BUG的证据。或者规范强制要求,或者是需求指明,或者是行业标准。
    你判断BUG的理由,如果是严重的BUG且必须FIX的BUG,你可以跟你的测试主管或项目主管提出来,由他们来决策。
  • 相关阅读:
    征集“微软武汉DOTNET俱乐部武汉大学樱花赏”活动内容
    2007上半年微软武汉.NET俱乐部活动预告。
    [微软新技术培训]微软新技术预览之Microsoft Office SharePoint Server 2007
    武汉.NET俱乐部武大赏樱花精彩图片
    [微软新技术培训]微软新技术预览之Visual Studio Team System
    [摘]互联网传说
    python:注释最多的冒泡排序
    《C#线程参考手册》读书笔记(一):定义线程
    【转】C# DateTime 日期计算
    详谈WPF开发中的数据虚拟化
  • 原文地址:https://www.cnblogs.com/heartstage/p/3390998.html
Copyright © 2020-2023  润新知