原文：Explaining Testing to Them - Helping non-testers understand and support your work （James Bach）
当程序员或经理对测试做出一些无知的解释时，你会有什么感觉？你不喜欢？但是我喜欢，因为至少他们说出来了。我的经验是：我的大部分非测试员同事，无论他们在自己的工作方面有多优秀，他们对我的工作的认识都比较模糊。但是如果他们什么也不说，我也对此束手无策。所以，在某种程度上，我会感觉好些，在我听到他们说一些类似这样的话：“你就是操作每个功能看它是否工作而已，对吧？这有什么难的？”
因为如果他们说出来，或许他们会听一下。如果他们倾听，或许我能给他们提供一个更有用的测试观。也许你认为你的同事们都已经明白测试是怎样工作的，其实不然。你才是测试专家。你喜欢测试，你热爱测试。因为你很在行，项目组中的其他角色的同事在他们专注的区域也非常在行。他们对测试的混淆概念恰好证明他们需要你。
在测试上，往往喜欢区分“我们”和“他们”。对测试进行好的解释会把整个项目组拉到一起。这很重要，因为其他项目组成员，包括经理，他们不会完全支持你的工作，除非他们理解你正在做的事情。
It Starts with Intent and Attitude出发点和态度决定一切
我建议你在做每次解释的时候都抱着这样的相同的目的：使你的同事更加强大和成功，帮助他们做出更有效的决定，并且帮助他们知道如何从你的工作中获取到最多的东西。
如果你解释测试过程的自动化给他们听，那么项目组会使用这些自动化过程的信息来“改进系统”并且从你这里获取更多的信息。如果程序员理解可测试性的好处，他们会设计好产品的可测试性，以便你能压缩测试计划，减轻你的测试复杂度。
注意沟通的技巧，保持做一个学生的心态很重要，“如果我会写程序，能让它自动化地测试这个产品就好了，但是我不知道怎么去做。”听起来会舒服一点。
The Hallway Dialogue走廊对话
一天，我在走廊上遇到开发经理Adam。
Adam说：“我们需要把计划延迟3周。我知道你的计划是在代码冻结后需要8周的时间测试。你能否在5周内完成？我们可能没有那么多的时间测试了。”
我首先想到的是这个家伙对质量不够严肃。但是我很快知道这个想法无益，应该抛弃。另外一个有益的想法浮现在我脑海：也许Adam认为我能控制测试计划的各项因素。
我说：“测试计划不是我控制的，Adam，8个星期是基于产品的复杂度和我们能想到的困难而估算出来的。也许需要8周也许不需要8周，这取决于代码冻结后我们拿到的测试版本的技术状态”。
注意我尝试说明影响测试计划的因素，我希望他会问那些因素是什么，那么我就可以找个白板列个表给他说明。
Adam说：“你不能预测这个计划？”
又一次，我的无益的想法出来了：也许是我错了，也许谁都可以预测计划，就是我不行？但是最后我也让这些消极的想法过去。
有效的回答是什么呢？也许Adam想要一个直接的答案，但是我想尝试把它展开来说，以便把问题的方方面面搞清楚，这样我们的交流才更加富有成功。我还想举些例子来说明问题。
文章来源于领测软件测试网 https://www.ltesting.net/