最近在测试时代翻看一些老帖子,发现一些很有意思的东西,收集整理后,把它放到了这里,那天回头看会有另一翻感受。^_^
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、
测试人员不是在找开发人员的错,也不是开发人员的矛盾体。测试人员是帮助开发人员节省精力去找出错误,修改错误的。一个好的开发人员是不会因为测试人员找出他很多错误而烦恼的,因为不断改进错误的同时,是对他的一个提高。
一个好的产品团队是协作良好的开发团队,测试团队以及管理组和设计核心组组成的。