关于BUG的沟通

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

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

首先要找需求文档，看有没有对预期结果进行具体说明，从而提高说服力度。其次要确保自己的bug能够重现。
再次，分析一下自己bug的级别，如果只是建议性的bug可以保留，但是也要在bugzilla等工具上记录；
如果bug级别比较高，就要跟开发人员有效沟通，耐心讲明这个bug的危害以及重现步骤等，不行就要跟测试经理或者开发经理联系，说过bug的严重性，进行问题评估，一起讨论解决这个问题。
 
找出是BUG的证据。或者规范强制要求，或者是需求指明，或者是行业标准。
你判断BUG的理由，如果是严重的BUG且必须FIX的BUG，你可以跟你的测试主管或项目主管提出来，由他们来决策。

最新文章

  1. C语言 关于内存动态分配问题
  2. 从偶然的机会发现一个mysql特性到wooyun waf绕过题
  3. python多线程
  4. BarTender是怎么做出雪花状文字
  5. invoke
  6. C#中方法的调用
  7. ExtJs4 笔记（4） Ext.XTemplate 模板
  8. MySQL存储过程解析
  9. insert 多个values
  10. Exploit用法示例
  11. 你听说过PHP 的面向方面编程吗？
  12. 【C#学习笔记】播放wav文件
  13. POS tagging的解釋
  14. 得于吾师傅的js知识 js类,单写模板,和私有保护的方法
  15. i++ 与 ++i 的从字节码层面看二者的区别
  16. AngularJs学习(1)
  17. 不同分辨率下获取不同js文件
  18. U盘详解
  19. [基础架构]PeopleSoft工作原理（从浏览器发送请求开始）
  20. 《用Java写一个通用的服务器程序》03 处理新socket

热门文章

  1. 图学java基础篇之集合工具
  2. luogu1829 [国家集训队]Crash的数字表格
  3. 了解Windows Server以及Hyper-V许可模式
  4. leetcode 【 Set Matrix Zeroes 】python 实现
  5. python 冒泡排序，快排
  6. Leetcode 557.反转字符串中的单词III
  7. 自己搭建一个记笔记的环境记录（leanote）
  8. python中 in, any 和 all用法
  9. java之LinkedList.add
  10. Python 字典值相加