结合互联网企业，产品技术部的实践，以下对话是QA同学工作过程中耳熟能详的对话，下面处理方式看似诙谐搞笑，其实仔细想想都是奔着把问题解决的方向去沟通的，所谓的“情商”，“沟通表达能力”，处处体现在工作细节当中。
1. 当开发详细询问bug场景
- 错误做法
直接回复开发：“bug管理系统中写得非常明确，自己回去仔细看。
正确做法
首先，询问开发是否已经查看bug管理系统的bug描述和复现步骤。
如果，开发没有查看bug描述，告诉开发在bug系统中已经详细说明bug的复现步骤。如果再有不明确的地方，可以随时沟通。
如果，开发已经查看bug描述，还是有不清楚的地方，那么需要针对有疑问的地方进行详细解释，或者当面沟通。
最后，需要反思自己提交的bug描述和bug复现步骤是否清晰明了。提交bug的时候，做到描述详细，清晰明了。如果是UI方面的bug，可以附上截图。自己附上造成bug 原因更好，有助于开发定位bug。
2. 当开发自测不充分，产品有严重bug阻碍测试
- 错误做法
直接找开发leader反映，或者直接和开发吵架。
正确做法
在提测系统中，将本次提测打回，注明理由“冒烟测试未通过，出现严重bug，阻碍了测试进行”。
找开发沟通，告诉开发冒烟测试未通过。详细告知严重bug复现步骤和发生原因。
并且告知开发，该bug严重影响到了测试工作开展，希望开发修改bug充分自测之后，再提测。
3. 当开发实现的功能不符合产品需求
- 错误做法
按照开发的逻辑走，视而不见。
正确做法
首先自己对产品需求进行客观分析，如果产品需求是合理并且经过事先评审，那么提bug给开发，并且告知开发原因。
如果开发对产品需求有异议，并且执意按照自己逻辑的开发，那么可以拉上产品一起，进行三方沟通，达成最终方案。
4. 当开发偷偷改代码，直接上线出现了bug，求助你时
- 错误做法
开发的锅，自己背。
正确做法
首先，提醒开发进行版本回滚，尽量避免线上影响。
然后，和开发一起找bug，并且分析bug原因。
最后，回顾整个事件，告诉开发直接上线的风险所在。并且推动上线流程体系完善，只有测试完成并且无修改之后才能上线。
5. 当开发修复bug不积极，导致项目延期风险，需要你陪着加班
- 错误做法
让开发独自加班，对项目延期视而不见。
正确做法
首先，还是明确告诉开发，他自身bug修复不及时，导致项目有延期风险。
然后，从项目角度出发，陪同开发加班，对bug进行回归测试和验证，保证质量的情况下，尽量不拖延项目。
6. 当开发因为你的bug误报，鄙视你的时候
- 错误做法
直接怼开发，居然怀疑自己的专业素养，大吵一架。
非得将黑的辩解成白的，坚决否认是bug误报。
正确做法
首先，承认自己的工作失误，然后给开发说抱歉自己误报了。
并且请求开发一起帮忙查找真正的原因。
自己学会总结分析，bug误报的原因。尽量避免再次误报。
努力提升自己的专业素养，树立自己的专业形象。
7. 当开发因排期紧张，有些bug不修复，直接带bug上线
- 错误做法
直接放任开发上线。
正确做法
需要对不修复的bug进行评估，如果是影响范围极小，并且偶现性bug，可以考虑排期的情况下允许上线。
如果bug严重级别较高，并且影响范围大，坚决要求开发进行bug修复。然后才能上线。
8. 测出一个bug时
- 错误回答
1、你这里有一个bug，快修吧
2、你这代码写得也太烂了
3、你又出bug了，怎么回事
正确回答
前提：先排除测试环境、未提测等相关问题；
回答：hi，***，BUG来袭请签收。
9. 当开发不能复现bug的时候
- 错误回答
1、我这可以啊
2、你操作步骤不对吧
3、你看看bug中我的操作步骤
4、这么简单你都复现不了
正确回答
前提一、确认开发与我的当前测试环境是同一版本
前提二、在bug描述的时候清楚的写明bug复现的步骤与输入的参数
回答：这个bug不是一般场景下必现的，操作的步骤有点复杂，我在发现这个bug的时候同样的操作步骤也不是每次都出现，我把发现bug的步骤一一列出来，然后你试着在你的环境下操作一下，如果不能必现，再来我这测试环境看一下，我先保留这个测试的场景。
10. 开发提测明显不符合质量要求
- 错误做法
哎，将就着测吧，通通提bug呗
埋怨开发提测的啥玩意
嘲讽开发，比如你这啥水平啊，是不是技校毕业的
正确做法
开发提测后进行冒烟测试，发现主要流程无法走通，冒烟测试不通过，将冒烟测试报告发送给开发，抄送相关产品负责人员等，将冒烟情况说明在测试报告中，为保障后续的测试进度与流程，望相关开发人员尽快修复问题，保障产品按时提测，进行测试。
11. 当开发推脱忙拒绝case评审时
- 错误回答
1、不评审出了问题你负责啊
2、有啥忙的，平时也不见你这么忙
3、那就不评审了呗
正确回答
测试用例的编写是从需求文档分析中提取本次的测试要点，项目开发过程中对于技术的具体实现是否与产品需求一致，希望你（开发）与产品一起参与一下评审，这样我们从不同的角度去过一遍测试用例，为了保障测试用例的覆盖度，提前将未从技术实现的细节考虑到的用例暴露出来，这方面还就需要你参与一下，如果实在没有时间评审，我们就邮件进行一下用例评审，我将测试用例发出，你看后回复一下邮件也可以。
12. 当开发反复修改bug不正确时
- 错误做法
1、埋怨开发啥水平啊，改了几次还是这样
2、让别的开发替改
3、抱怨，干脆不测得了
正确做法
将这个bug出现的场景参数一一列出，调用的接口等描述出来，查看开发代码，将bug出现的问题帮助定位。
13. 修改bug引起别的bug
- 错误回答
1、让你改一个bug，你还整出2个bug了
2、你这也太不认真了吧
3、再这样下去，测不完了
正确回答
刚才的bug修复之前这块是没问题的，当这个bug修复后，这个模块的这个功能异常，引起了这个问题（将这个问题描述清楚场景），是不是这2个模块耦合度有点高，咱们看看这两个模块吧。
14. 当开发找你复现的bug的时候
- 错误回答
1：操作步骤在那儿，瞎吗
2：必现的bug你都复现不了，撒币吗
3：一个微笑的表情
4：反正 LOG/抓包已经在那儿了，剩下的自己看着办吧
5：你来打我呀，你来打我呀，呵呵呵~~~
正确回答
我操作步骤是不是写的有歧义，这个bug我是这样复现的。。。
写在后面的话：
站在项目角度、客户角度，有问题解决问题，资源总是有限的，一定是有取舍的，至于具体的措辞态度，对人下菜了，毕竟有的开发喜欢攻，有的开发喜欢受
