zoukankan      html  css  js  c++  java
  • 关于bug的沟通

    关于BUG的沟通

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

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

    首先要找需求文档,看有没有对预期结果进行具体说明,从而提高说服力度。其次要确保自己的bug能够重现。
    再次,分析一下自己bug的级别,如果只是建议性的bug可以保留,但是也要在bugzilla等工具上记录;
    如果bug级别比较高,就要跟开发人员有效沟通,耐心讲明这个bug的危害以及重现步骤等,不行就要跟测试经理或者开发经理联系,说过bug的严重性,进行问题评估,一起讨论解决这个问题。
     
    找出是BUG的证据。或者规范强制要求,或者是需求指明,或者是行业标准。
    你判断BUG的理由,如果是严重的BUG且必须FIX的BUG,你可以跟你的测试主管或项目主管提出来,由他们来决策。
  • 相关阅读:
    axios基本用法
    Iframe父子窗口之间的跨域事件调用和传值
    js 比较两个日期的大小
    小程序webview实践
    小程序入口构造工具&二维码测试工具
    小程序无限层级路由方案
    TypeScript基础类型,类实例和函数类型声明
    小程序多业务线融合【完整分包业务接入】
    浅谈React16框架
    CSS Modules 与 scoped 的不一样
  • 原文地址:https://www.cnblogs.com/heartstage/p/3390998.html
Copyright © 2011-2022 走看看