如何描述一个BUG
当你发现小哥哥写的代码有BUG，怎么告诉他？（你写的这什么破代码。。我觉得你可能会被一顿暴击）
缺陷描述要素:一个合格的bug描述应该包括以下几个部分：
1、发现问题的版本：知道出现问题的版本，才能够获取对应版本的代码来解决。
2、问题出现的环境：硬件软件？如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。
3、错误重现的步骤：描述问题重现的最短步骤。
4、预期行为的描述：写上正确的预期结果
5、错误行为的描述：描述错误的现象。crash等可以上传log，UI问题可以有截图。
6、其他：BUG优先级、会不会阻塞测试进行等等
7、不要把多个bug放到一起：在无法确认是同一段代码造成的故障时，不要将bug放在一起提交。
如何定义BUG
崩溃、严重、一般、次要、建议
BUG的生命周期
New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。
Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
Rejected：如果认为不是Bug，则拒绝修改。
Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
无效的bug：open->closed open-rejected
与开发闹脾气了应该怎么办：
遇到争执不要怕，记住批判性思维：清楚–准确、切题–深刻，有意义，有逻辑性–公正、全面
1、先检查自身，是否bug描述不清楚
2、站在用户角度考虑问题 应该让开发人员了解到Bug对用户可能造成的困扰，这样才能促使开发人员更加积极
3、BUG定级要有理有据
4、提高自身的技术和业务水平. 不光要提出问题, 最好也能提出解决方案
5、开发人员不接受时，不要争吵,可以发起Bug评审。