原文应该无法访问到，这里就不给出链接了。原文的标题是：DO’S and DON’TS in Communication Between Developer and QA Engineer。我做了一些简单的翻译，大家应该可以大概了解到作者的真实想法。本文只是翻译而已，作者的观点仅代表她的个人看法。

在担任 QA 工程师多年后，我决定分享一些有关与开发人员沟通的技巧。

这些不要做

如果不紧急，不要分散开发人员的注意力。不要马上走到他的办公桌前。首先通过 Messenger 询问或提前安排会议。我意识到，一旦自己开始写代码的时候，当有人过来打断我的时候，我需要花费大量的时间和精力才能再次进入之前写代码的沉浸状态，这种中断根本不会增加生产力。

别害怕寻求帮助。你不可能什么都知道，问别人是有没关系的，因为这比假装你很酷要好！不过要确保你理解了答案，不要问同样的问题两次。大家都在同一条船上，如果每个人都有一支桨，我们就可以朝着一个方向前进，这对每个人都有好处。

不要相信开发人员的话。您需要找到证据来证明开发人员对“一切都应该没问题！”或“我只是改了代码中的一个字符串，它不会破坏任何逻辑”的信心。

不要责备。不要固守消极，尝试解决问题，对事不对人。稍后我们可以决定如何避免将来出现类似问题。没有人是完美的，错误是不可避免的。主要目标是有能力做出健康的反应，然后做好自己的工作就好了。

别偷偷摸摸直接给开发人员分配给缺陷。与跟开发人员在未经 QA 批准的情况下关闭bug有异曲同工之妙，这可能会令人生气的。

不要对开发人员进行事无巨细的管理。“你检查缺陷了吗？”，“现在怎么样？”，“你什么时候修复错误？”。这很烦人，他们不能更快地解决问题。只需将自己置于开发人员的位置即可。

别把事事都放在心上，脸皮可以厚一点。不要情绪化，不以物喜，不以己悲，不需要对别人的无意间的言行睚眦必报。你要学会同傲慢的人打交道，它实际上可以应用于任何人。这就是为什么厚脸皮和委婉的表达是必须的。

可以这么做

与开发人员交流知识。让他们了解您的测试方法，为每个与你合作的开发人员找到“access_key”，高告诉他们你会如何进行测试，这可以帮助你避免部分错误。但是，由于一些原因，这并不总是可能的。第一，时间不够。其次，公司流程不允许这样做。最后，开发者出于多种原因不愿意与某人合作。但是，如果你能找到我上面提到的“access_key”，从长远来看，保持健康的关系会容易提升产品质量。

学会说服。如果你想在工作中得到一些非测试方面的提升，这是一项有用的技能。寻求支持并将您的计划变为现实，不过如果你在你的陈述中感到孤独，也许你的计划或想法是有改进空间的。所以，不要为了说服而说服，让别人接受你并不总是正确的事实，学会倾听和倾听你周围的人。

说实话。否则，它会很快毁掉你的声誉。或者这取决于你是一个多么好的骗子，不是每个人都是老罗。

准备好为你提的bug辩护。有时候你必须捍卫需要修复的缺陷的重要性。但是你必须在你的陈述中说明自己的观点，让别人信服。随着时间的推移，这会让你得到其他人的信任并节省公司的资金成本。

在压力下保持冷静。我知道，这很难。当每个人都不断催促你或你的团队时，你很难不乖乖就范。然而，说“不”是我们工作的一部分，即使这不是流行的观点。当然如果有人把你推到墙上或用枪指着你的头，这条规则就不起作用。

与开发人员讨论测试用例。根据我的经验，这很难做到。这需要双方的时间和奉献精神，魅力和测试同学的强大说服力。我已经这样做了一段时间，但我无法采用这种方法。我从与开发人员的此类会谈中看到了巨大的好处。但是，我可能看不到的东西可能会告诉我相反的情况。你怎么认为？

在bug描述中要准确。如果可以，请使用开发人员的语言。在其他情况下，让你的表述尽可能的简单。它应该是瑞典语中的“lagom”。具有良好的规模结构并为开发人员提供足够信息，让别人知道你描述的是到底是什么。

鼓励队友深入了解产品。团队中的这种意识将减少愚蠢的bug数量。根据我的经验，低级的bug会消耗大量精力来报告它们。这些bug最好直接就预防住，让我们专注于更重要的事情。而不是让我们报告错误的*字体大小，*测试的边缘情况、安全性、性能等。

要有耐心。不是每个人都是好相处的，要学会应对困难的、自恋的人。这是适用于任何人的一般性规则。

一旦我开始为这篇文章写想法，我决定记下我自己的想法，然后再与““Lessons Learned in Software Testing. A Context-Driven Approach” —— Cem Kaner、James Bach 和 Bret Pettichord 撰写的一本书做比较。我是故意这样做的，所以这本书不会影响我对这个话题的看法。如果您同意它们，您可以完全阅读他们提供的课程并每天应用它们。

根据我的观察，有些想法已经存在于第 7 章中。它让我感到温暖，因为我获得并放入下面清单中的经历让我想到有人也有同样的想法。

我读过的一些课程实际上不在我的清单上，这意味着我学到了一些新东西，可以尝试将这些课程融入我的 QA 策略中。

你读过我提到的那本书吗？在与开发者的交流中，您有什么样的观察？如果你有什么要补充的，请留言哦。不管你是不是QA。不同的观点永远不会受到伤害。