原文应该无法访问到,这里就不给出链接了。原文的标题是: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。不同的观点永远不会受到伤害。