报BUG的顺序

2010-05-07  胡军红 

也许有人从没有考虑这个问题,觉得测试人员对于报Bug没有顺序而言,发现一个报一个。甚至坚持着这个原则:宁可误报三千,不可漏报一个,积极地汇报着自己发现的所有Bug。结果,慢慢地就发现Dev对自己报的Bug失去了灵敏性,往往自己报的一个Bug,即便有工具的提示也会被开发人员不断地忽略或者推迟。

的确,这是一件令人沮丧的事情。作为测试人员,汇报Bug是自己工作成果之一,在大多数公司甚至就是主要成果。一旦自己的成果被别人忽视,引来的就是测试人员成就感的丧失,继而影响测试的情绪,从而带来测试效率低下的后果。

这个问题其实还是非常普遍的。据我观察,身边很多测试人员(包括刚从事测试工作的我)都犯过或者正犯着这个同样的错误。这个问题的出现很难过多地把责任放在Dev身上,事实上测试人员更需要担负多的责任。

出现这个问题的原因主要是测试人员没有很好的把握Bug的严重性及优先性,没有把握好Dev的心理需求。举例来说,单词拼写错误的严重性比程序在某些情况下功能散失的严重性要轻的多,但是往往可能更好的被发现。可能有人喜欢在测试前几个周期里就喜欢大量报道这类问题,从而让Dev接受类似"服务拒绝攻击似地的Bug报道。而开发人员在测试前期一般对自己代码不具有充分信心,此时更多地是希望测试人员从功能性上提供质量反馈。当然,大量的拼写错误式的Bug列表不断让开发人员出现审美疲劳,对你报的问题逐渐不敏感起来也就不奇怪了。更严重的问题是,大量这类问题的汇报同时也在消费着自己的信誉,给开发人员一种印象:这人根本就找不到问题,只会抓些皮毛的问题扔给我们,让我们忽略他吧。于是你就在不知不觉中,"努力地"把自己扔进了黑名单。

可是作为质量守卫者的测试人员是不应该把这类问题留给用户的。按照上面所说,我们该怎么弄呢?记住,我的标题叫顺序,就暗示了我对Bug汇报持有的观点是:这些Bug是一定要给开发人员接受的,不过不在最初开发人员正渴望修改功能方面问题的时候,而是按照一定的顺序提交给他们。

我推荐一种做法:针对所有你觉得是问题,但又不至于严重影响程序质量或者项目进度的一些问题,把它用你的私人备忘录记录下来,而把功夫主要花在功能、性能等方面的质量反馈上。当你报了几个大问题后,可以一些小的Bug给开发人员;或者在你得知开发人员在修改了几个大问题后出现空档时报他几个小问题,让他们调剂一下。在我的日常工作中,甚至我会把一些极小的问题私底下告知开发人员,让他们纠正——当然我会暗地里跟踪这些问题的修改进程的。一方面开发人员觉得Bug管理系统里自己的Bug会少些,而或多或少对你有些私下交情——比方说更快的反馈你报Bug的修改进度情况或者在讨论中更多的维护你的观点;另一方面,你并没有失去什么,不是么,你的问题也没有被落下。测试人员守卫质量的职责你并没有放弃,你在开发人员心中也具有了更多的信誉。这大概就是Win-Win吧。

扯了这么多,其实最大的总结就是测试不仅是个技术活,还是一个极具心理学挑战的工作。你不仅要和代码打交道,还得和一批优秀的又经常自认不凡到甚至有些自负的开发人员打交道,你得学会在不断提高自己技术的同时还提高自己和他们打交道的技巧。相信你在自己的工作中不断体会,自然会得到自己的一套方法。

 

535°/5159 人阅读/20 条评论 发表评论

苗志伟  2010-05-07

偶的做法就是把某一个流程或者模块的所有bug记录在一起提交,开发人员再针对bug按他自己喜欢的顺序一个个改。

从表象上看,发现的问题不多;从修复问题角度,开发人员也很接受这种做法。


李时卫  2010-05-08

偶们这里是根据Bug的严重程度和优先级来决定啥时候修复,初期一般先把影响流程的,严重功能缺陷报上,报Bug的顺序也没啥特别讲究,回归阶段要求Bug要日清的。


李琴  2010-05-08

我觉得还是都要报的,要想那么多会增加自己的工作量,而且报BUG时就已经给开发设置好了优先级的,项目前期也约定好先解决高中的,再解决低的BUG。


苗田丽  2010-05-08

现在的缺陷管理系统报Bug的时候都会选择严重性的优先级,做为测试人员来说我们根据测试计划执行测试用例,来进行测试活动是我们的责任,不断的维护测试用例,随着测试的不断深入会发现更深层次的bug,也是我们的责任,但是我觉得开发人员愿意先改那个是开发人员个人的工作安排问题。我们的责任就是在现在有时间请允许范围内,把系统的潜在bug数减小到最少。


袁永云  2010-05-08

楼主写的很好,受教了,原来懵懵懂懂也注意过这方面的事就是没有一套很好的理论支持,现在终于知道了。
在我们公司虽然我报Bug的时候都会选择严重性和优先级,也跟他们提过几次但开发不能引起足够的重视经常看到哪个好改先改哪个而延误了一些重要bug的修改进度(虽然老总并不太关心bug的进度)
所以我现在测试的时候,对于新开发的模块,先不管界面的问题先把主要功能按正常操作都跑一遍,再针对重点功能异常测试,最后进行其他功能异常测试,安全性测试,界面测试等。这样提出的bug也就有顺序了。


张挺  2010-05-09

恩,赞同,总而言之,不是报上去就算了,我们的目标是报上去之后还要开发把bug修复。楼主的思考方向很正确。


张静  2010-05-10

看来楼主的文章,受教了,最近在公司的项目中,上司一直都是只关注UI上的bug,所以对于自己对功能性提的bug一直都不关注.


程守标  2010-05-10

谢谢分享,由于公司小,和开发坐在一起,以前都是一发现问题就让开发确认,每次测试时,也搞的开发挺忙的,开来以后也要多注意这方面的问题


许伟  2010-05-10

赞同!我们公司是按照Bug的严重性的优先级报的


刘小袁  2010-05-10

我们要捍卫的是软件的质量


刘小袁  2010-05-10

楼主说的很好啊,赞一个


李天保  2010-05-10

楼主首先思考了,提出自己的观点,所以给个鲜花先!
但是老夫还是有话要说:
1:优先级的制定,非个人观点来制定。优先级的制定有严格的文档参考标准,什么样的bug为critical,什么样的为Major。有标准可依,你才去按照标准去报告你的bug等级。
2:作为RD,解决bug永远都是按照Bug的等级来进行fix,只有不成熟,不负责任的RD才会Delay.
3:  如文中所说,如果UI上的单词拼写错误之类的bug很多,上报太多,会引起RD的不够重视。富有丰富经验的测试人员,最聪明的做法是将所有UI的此类bug集中为一条,上报至RD。如果一个UI就报一条Bug,不但让RD fix bug不停的去翻看不同地方的文档,更会引起RD的情绪反感。关于这点,有些公司会以Bug数的多少与绩效挂钩,导致测试人员分条的上交bug,实际完全没必要!


任盼  2010-05-10

楼主和楼上的李兄台说得很有道理,这就不止牵扯到测试上的技术活,还有很多测试员应具备的素质问题。但是很多情况下,公司有一种奖励机制,谁发现的bug越多,等级越高,奖金就越多,而且测试一个模块的人员有时候很多,竞争也就愈发的激烈。所以很多的测试员都形成一种发现Bug就报的习惯。所以就和开发方面的形成了一定的矛盾。这个矛盾可以有很多种解决的方式,我建议一方面测试员要从自己这里改正,将中心放在bug的质量上,而不是数量,还是一样的,发现一个报一个,情况肯定会有所好转。第二,发现bug不确定的时候和leader协商,这样一定程度上也能提高自己的bug质量,尽管很多时候觉得自己的bug被leader否定而耿耿于怀,但是这样还是有助于你在Development的信誉。第三,bug管理平台,管理员可以先一步对bug进行甄别,先send一些高等级的,能力好的话就能够均匀的调配好这个工作。有时候这个工作量确实很大,但是有效地甄别能减少Development的疲劳和提高某些测试员在Development的信誉度。最后说一点,在项目的不同时期,bug的等级密度会很不通,项目的开始阶段,中心一定要放在function上,因为这个时候这方面的问题肯定很多,随着项目的进展下去,bug的侧重点一定会转移到低等级的犹如UI,易用,延迟等上面去,这时候重心基本上也就是这写严重性低一些的bug上了。


谢明志  2010-05-11

楼主让我受益匪浅呀,补充点想法,在历史问题(各种历史bug)还没有解决清楚的前,我们给dev报各种新bug都会导致对test bug 的“审美疲劳”。一个运行了1年以上的项目很少没有历史遗留bug的。而dev又没有足够自信fix或者cancel这样的bug,dev只能在priority和workload中痛苦的选择。似乎,没有什么办法不让他们对bug产生审美疲劳呀。


胡军红  2010-05-11

任盼: 楼主和楼上的李兄台说得很有道理,这就不止牵扯到测试上的技术活,还有很多测试员应具备的素质问题。但是很多情况下,公司有一种奖励机制,谁发现的bug越多,等级越高,奖金
说得在理


周文静  2010-05-11

学习了.


朱小玲  2010-05-12

太有道理了,今天才被同事温馨提示,发现的BUG数量和XX挂钩。悲哀。。。以后要多提书面BUG。。55555


郭露  2010-05-12

我以前的公司每次提交bUG的时候都很烦,都在犹豫要不要提交!因为有时候提交上去,结果研发不重视,说不改就不改,口头上说下个版本改,可是在下个版本中她却又不能确定改过,甚至有些功能他们自己都不晓得实现没?甚至有次测试了几轮,结果开会才知道,研发在实现某个功能时自己都不清楚为什么有此功能,导致方法错误,思路错误,功能不完善而重新返工测试。之前的BUG全部不生效。又得重新测试。


金鑫  2010-05-12

谢明志: 楼主让我受益匪浅呀,补充点想法,在历史问题(各种历史bug)还没有解决清楚的前,我们给dev报各种新bug都会导致对test bug 的“审美疲劳”。一个运行了1年以上的项目很少
点睛了一笔,受益


李维敏  2010-05-13

都是经验之谈,牛


登录 后发表评论