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