|
本帖最后由 caoase 于 2011-3-31 16:15 编辑
测试喜欢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,才是开发的朋友。
写到这里,欢迎拍砖。 |
|