【测试开发篇】处理人际关系

---

跟开发产生争执怎么办

原则：对事不对人
能让开发人员解决最多Bug的测试人员是最优秀的测试人员

在测试工作中，最常遇到的是和开发人员的PK，作为测试经理还会和项目经理、产品经理的PK进度、 质量。

作为一名测试人员，一般会遇到以下几种情况：

• 这不是bug
• 这个bug的级别太高了
• bug影响不大，暂不修改

遇到争执不要怕，记住批判性思维：清楚–准确、切题–深刻，有意义，有逻辑性–公正、全面

1. 先检查自身，是否bug描述不清楚
   如果能正确地、高质量地录入一个Bug，那么基本上已经成功地与开发人员沟通了一大半的关于Bug的信息。但是总有“书难达意”的耐候，这时就需要测试人员主动与开发人员进行沟通了。 如果测试人员发现在写完一个缺陷后，好像还有很多关于Bug的信息没有表达出来，或者很难用书面语言表达出来时，就应该在提交Bug后，马上找相关的程序员解释刚才录入的Bug，确保程序员明白Bug描述的意思，而不要等待开发人员找自己了解更多的信息。
2. 站在用户角度考虑问题 应该让开发人员了解到Bug对用户可能造成的困扰，这样才能促使开发人员更加积极地、高质量地修改Bug。在争执时，可以问一句：如果你是用户，你可以接受么？

例如：需求要求可以上传图片作为头像，但是没有定义格式。开发人员在上传时限制为只能传png格式的。
站在用户角度考虑一下：png，jpg那种格式更多？是否要用户自己进行格式转换再上传？

3. BUG定级要有理有据
   BUG定级时，不仅要参考BUG级别，还要考虑BUG是否会影响到流程，往往用户的BUG级别和我们的是有区别的，需站在用户的角度定考虑定位级别。
4. 提高自身的技术和业务水平.
   不光要提出问题, 最好也能提出解决方案
   提高自身的业务和技术水平，不但要做到能提出问题，还能够提出解决问题的思路。 这样才能更让人信服。
   在工作中，你会发现同一个bug，资深测试工程师提出和初级测试工程师提出，两者的结果完全不同，两者最大的差别是资深测试工程师往往会提出解决方案。而长此以往，权威性逐渐的建立起来，那么开发人员看到bug的第一反应，就是这是一个bug，而不是这是一个bug吗？

案例：
某网站经常隔几天访问时会出现500错误，但是之后就不会复现。 测试人员会提出问题：网站偶发性出现500错误。
开发人员回答：不常见，不影响使用，暂不修改
资深测试人员提出问题：网站偶发性500错误，查看日志，是由于mysql数据库8小时超时问题造成。需要修改连接池配置定期校验连接
开发人员处理：修改xml，增加校验配置项

5. 开发人员不接受时，不要争吵
   可能你已经经过了多轮沟通，但是开发人员仍然拒不接受。此时可以发起Bug评审。
   Bug评审要注意,缺陷的评审应该包括以下两个层面
   ● 决定如何处理Bug
   ● 分析缺陷产生的原因，找出预防的对策。
   (1)决定如何处理Bug。
   这一方面评审需要项目组各个方面的代表参加，通常不可缺少的是测试代表、开发代表、产品代表。
   测试代表主要从Bug的具体表现、严重程度等方面提供信息，并提出自己对Bug的处理意见。需要注意的是，测试人员不应该一味地要求对Bug进行修改，因为修改可能带来回归的风险，同时带来的是回归测试的工作量，如果时间比较紧迫，修改后剩余的时间若不足以做一次有效的回归测试，可能不修改是个明智的选择。
   开发代表主要从修改缺陷的难度和风险出发，考虑缺陷修改需要付出的代价，以及可能影响的范围、可能引发的风险等，如果决定要修改，还要讨论出修改的初步方案。
   产品代表主要从产品的整体计划、用户的要求等方面对缺陷的修改必要性、缺陷修改的时间和版本提出自己的意见。
   这在微软的做法叫“Bug三方讨论会”，参加者一般是测试人员、开发人员和项目经理。
   (2)分析缺陷产生的原因，找出预防的对策。
   缺陷评审还应该包括原因分析，找出Bug出现的原因，尤其是那些重复出现的Bug。应该找出出现错误的根源，并且制定出相应的预防措施，确保同类型的Bug不再出现。
   例如：有些Bug出现的原因不是简单的“引用为空”之类，而是开发人员的编码不规范或者编程习惯不好而导致，所以必须建立起正确的编程方式才能预防这些错误的出现，否则只是在玩无聊地重复发现相同的Bug的游戏。