浅谈测试与开发的关系-如何报BUG和BUG量

caoase

测试喜欢BUGS,开发讨厌BUGS。因此，做测试的都希望自己能够每天多发现一些BUG，而开发都希望自己能少收到一些BUG的报告。
      我个人认为，BUG的发现量并不能完全决定测试和开发的工作水平。假设，一个复杂的系统，那么出现BUG的可能就要相对大一些，BUG可能就会比其它较简单的系统多一些。我们不能因为这个系统的BUG多，就武断的认为发现很多BUG的QA是好QA，制造了这些BUG的开发是笨开发。
      那么，除了BUG的发现量，还有什么因素是影响测试人员在开发人员心中的地位和水平的呢？我认为有如下几点：
      1，对系统的熟悉程度，测试不需要和开发比编程水平，但一定要比开发更全面的了解系统，这样才能在一个比较好的高度去纵览软件，从而在发现BUG和更好的和开发去交流。
      2，对BUG的定位程度，严重等级3，风险3，永远写3，永远安全。很多QA习惯了在严重等级和风险研判里写一个中位数，因为这样让他们觉得最保险。但是，假如你永远写3，那么你如何能够理直气壮的告诉开发，这个3的BUG要比那个3的BUG严重，要更快的得到修复？
      3，BUG的简介。有些QA一找到BUG就觉得大功告成，不加太多的思考，就写了个题目上去，开始报BUG了。这样的随意性取的题目，真的和这个BUG匹配真的能够让人从题目上就能很好的理解BUG的主要内容吗？
      4，BUG的重现步骤。开发最不愿意看到的是，QA告诉他有BUG，然后，他按照QA写的步骤，费了九牛二虎之力读懂了QA写的重现方法，再加上一点点想象理解了QA所设定的预期错误结果。可是在这一切之后却发现，BUG没出现。然后，开发要装着很平和的来到QA的位子上，请QA重现给他看，然后在一番捣鼓之后，QA承认重现这个BUG确实很难。我想，这样的QA会很惹人讨厌的。
       BUG在多，也在精准。一个报很多不清不楚BUG的QA，一定是开发的眼中刺，心头刀。一个能够精准的报出BUG，并能够很好的保留或重现现场的QA，才是开发的朋友。
       写到这里，欢迎拍砖。

archonwang

我不喜欢bug。。。

过程令人回味和美妙吧。

a625152353

找到bug后我笑了,开发哭了.

愚人