怎么写bug才能不被开发人员讨厌?

2011-11-30  邓智群 

最近在翻看一些老帖子,发现一些很有意思的东西,收集整理后,把它放到了这里,那天回头看会有另一翻感受。^_^

  Ayi 问: 请问怎么写 bug 才能不被开发人员讨厌?

  davy_chen 答:

  1、描述精确,完整;

  2、简洁,无歧义;

  3、可稳定复现;

  4、利用截图,调试信息等辅助说明;

  5、反馈验证结果及时,变化内容描述详尽。不被开发人员讨厌最主要的是建立威信,也就是你说出的都是真实的,你说有 bug 就确实存在。

  6、若对于很难重现的 Bug 还需要注明该 Bug 在测试过程中出现的几率。

  sww1980 答:

  1、不被讨厌不一定用写 bug 的方式,跟开发人员搞好关系也很重要。

  2、只要有 bug, 开发人员肯定会烦,这时候你的亲和力就尤为重要,让开发人员觉得你不是在挑他的毛病,

  而是想一起开心的把软件做好。

  小颖 答:

  1、如果能够指出 bug 的原因或出处一方面可以让开发人员感觉你的水平比较高,另一方面减少了开发人员找错的时间,他会心服口服。

  2、在有不要抓住一些规范性的错误不放,应该发现一些有深度的错误,功能实现是重要的

  celine 答:

  我觉得沟通很重要,尝试站在开发人员的角度上描述问题,而且要对事不对人。

  gigobin 答:

  1、开发人员喜欢的 bug ,是能够一幕了然知道出现了什么样的问题,然后是一个简洁的复显问题的步骤。 一般我都习惯于先写一个简单的问题的 brief ,一句话,比如:在 xxx 输入某字符后,点击 save 报 500 错误。 然后下面是你的测试端的配置。然后是你的测试平台的情况。这些都是参考。 然后就是第一步怎么做,第二步怎么做,......,然后出现了什么错误。 最好是一个 bug 里面只有一个问题。这样便于大家跟踪状态。

  2、对于交流问题,我觉得如果有一个好的 bug 平台,在一个清楚的 bug 时,很少需要开发人员和测试人员交流。尤其是什么是不是一个问题时,如果开发人员认定不是,不需要太多的纠缠。除非你认为这个将非常有损客户的利益。而且这个时候应该报知测试 leader 去和开发 leader 进行协调。 而且尽量不要去写我认为这个问题是什么引起的,应该怎么改。你只需要保证开发人员能够复显就可以了。过多的涉及这个问题,会牵扯双方的精力。你的任务是发现问题,报告问题,追踪问题而不是解决问题。

  3、测试人员不是在找开发人员的错,也不是开发人员的矛盾体。测试人员是帮助开发人员节省精力去找出错误,修改错误的。一个好的开发人员是不会因为测试人员找出他很多错误而烦恼的,因为不断改进错误的同时,是对他的一个提高。一个好的产品团队是协作良好的开发团队,测试团队以及管理组和设计核心组组成的。

465°/4587 人阅读/7 条评论 发表评论

熊志男  2011-11-30

bug写得简洁,准确,节省很多沟通的时间;不过有的开发人员就是不习惯仔细看bug描述,一有问题,就拉测试人员过来问,或者过来复现bug,也不能养成他们这种坏习惯。


刘俊  2011-12-05

bug描述清晰是首要的,不过开发通常会因为测试总是提一些小问题而感到不耐烦或者生气,因为他们的项目进度很紧,所以他那边火烧眉毛了,你还不停的打断他们,就会产生怨气。我觉得开发和测试能心平气和的讨论问题真的有点困难,毕竟我们测试的出发点,说好听点,是协助开发提高产品质量,说难听点就是找茬。你找他茬,他几次还能笑着和你说,几十次就很难忍受了,呵呵。人之常情


王艺  2011-12-07

确实,不要加“我以为”,“我觉得”,只要把问题摆上桌面就好了,改不改由他们和老大说了算


宋康龙  2011-12-12

一般发现问题,先跟开发沟通下,让他确认是个BUG,然后在提BUG不迟~~

这也是一种手段


孙威  2011-12-20

宋康龙: 一般发现问题,先跟开发沟通下,让他确认是个BUG,然后在提BUG不迟~~

这也是一种手段
但是有的测试人员就是喜欢一发现bug就马上跑过去告诉开发人员...不仅影响自己测试进度,还耽误开发人员思路...
个人比较建议较严重的问题,才去沟通下...说明下操作步骤


杜芳亚  2011-12-28

比较明确的bug直接提交就可以了,有争议的还是要先沟通一下比较好,毕竟可能也可能是自己理解有偏差,如果提交的bug被置为不是bug的多了,测试的威信度也就低了


小窝  2011-12-28

已同步至官方微博


登录 后发表评论