作为一名软件测试工程师，日常工作中最常打交道的肯定就是开发和产品经理。有沟通就会问题，有问题难免会有争执。那么你肯定听过这些话：
“这么弱智的 bug 你都测不出来吗？”
“为啥这个功能还没测完就上线了？”
“研发时间不够，你压缩一下测试时间”
“这个 bug 和开发没关系，注意看需求”
听到这些话，分分钟高血压，要说谁是超级背锅侠，那测试肯定当仁不让（要求追加 “背锅费”）
问题的关键来了：作为测试的核心不是看人家的代码写的错不错，本质上要更关注需求。
在开需求评审会的时候，开发和产品往往很容易忽略了测试，他们下意识会认为和下游没有关系。
可是，熟悉业务，熟悉功能，熟悉各种设计是整个研发团队都需要达成信息共同的，而且测试需要站在用户的角度来去考虑他们的设计是否有不合理的地方，并提出自己的建议。
上面说的工作，需要测试去主动，积极参加，多提建设性意见，让其他岗位的人认识到测试的重要性。其次，除了需求评审会沟通之外最频繁应该还是关于 bug 的讨论。
更多内容可以学习《测试工程师 Python 工具开发实战》书籍、《大话性能测试 JMeter 实战》书籍
下面列出几个比较常遇到的沟通问题，仅供大家参考。
解决方式：
先检查自己提交的 bug 描述，看看是否准确，bug 重现步骤是否没有说清楚。bug 应该简明扼要，重点突出。
如果描述存在让人误解的表意，最好改过之前再给对方，如果还是无法解决就当面沟通，事后根据沟通内容来表述内容。遇到概率性的 bug，一定要告诉开发概率是多少，尽可能多的提供重现条件。
解决方式：
需求也是人定的，如果觉得有异议，可以找需求人员了解清楚，为什么这么定，然后把自己的想法告诉他们，看他们怎么决定。
如果被需求说服了当然是最好的，如果自己还是不同意需求的看法，需求又不同意我的提议，那只能听他的，毕竟权力在他那里。不过我们可以把沟通结果备注在这个 bug 下，以后也能有证可查。
解决方式：
测试过程中，我们可以要把客户想象成 “儿童”，用户会如何操作，我们无法列出所有的操作选项，只有尽可能的去覆盖到位。不过也不用过分担心，毕竟用户都是成年人。
开发的思考角度其实仅在于功能是否实现，而测试人员需要考虑的更多，所以也理解开发会说这样的话，但是为了更好的产品体验，多多提出来这类的问题，也是帮助开发进步的一个方式。
双方沟通的多了，也习惯了双方的工作方式和思维模式，那么下一次出现这个问题的时候，会更快更好的解决。
总之：一切站在用户的角度看问题。达成这样的共识，很多问题就不会是问题了。
（但是最后还是没能说服他，第一向领导反映，第二做好沟通的记录，将来备注在测试报告里。）
解决方式：
如果 bug 是由开发的项目经理来分发到程序员，那就是项目经理来面对这样的问题，而不是测试。
当然，项目经理当然有项目经理的处理办法。可是，测试遇到这样的问题怎么办呢，把负责相关内容的开发都邀请到一个讨论组里，让他们自己讨论，这样更清楚，不必在测试这里中转。如果他们都觉得代码没问题，而我也有强有力的截图和真相，那就只有上交给上级领导，让他们来决定怎么解决。
总结起来，测试在工作上要主动询问，态度上不能轻易妥协，习惯上要善于记录细节，方法上软硬兼施，这样才能在职业生涯上一步一个脚印。