测试人员则会对程序员的自我形象造成威胁，他们会打击程序员的那些特征。他们会展示给人们看到那些抽象概念没有用，细节没有被掌握好，或者是问题还没被解决。这一点也不奇怪，然后，程序员往往会把测试员的注意力从那些基础的概念转移出去，把它看成是对他们写的代码的系统的探索，寻找代码错误。代码错误不是什么大问题。一个对代码错误不重视的程序员可能会失去一些威望，但是仍然可能会被认为是优秀的。程序员可能从来不制造代码错误，但是创建笨拙的抽象概念。
现在，对于测试人员而言，寻找代码错误只是工作的一小部分。概念上的错误，例如不恰当的抽象或错误的假设，更加重要。它们会需要付出更多的代价来修正。
这种期望值的不一致会导致强烈的冲突。程序员会认为你在做错误的工作，使用错误的方法。那么现在是时候发现和解释正确的做法的时候了。程序员是无情的问题解决者。（我的妻子，她是个兽医，在见过我的程序员之前对程序员不了解，后来她对我说：“你知道吗？你的朋友对任何事情都有强烈的主张和看法。”）
通过给程序员解释你的工作来避免这些问题。解释可以分成几部分。
解释你的工作与他的工作之间的区别。
表明你拥有程序员不大可能有的技能，完全可以从第一点的原则推理出来。
展示你锻炼出来的那些技能是如何帮助程序员实现他们的完整性的，而不要让他们质疑这些能力。你以不可或缺的方式弥补了控制和驾驭这个世界的能力。
让我以一个特定的例子来描述。这是我在写这篇文章的时候想到的，所以只是在一个开发人员身上试过，但是我想这是我发现的最好的描述我的工作的方法。这里是一个谜题：
那个人的父亲是我的父亲的儿子，
但是我没有任何兄弟姐妹。
这使人迷惑，因为第一行文字描述了下面的情形：

但是这张图与第二行文字描述的相矛盾，因为我的父亲没有其他儿子。
这个谜题很容易解决，如果你意识到文字暗示的“那个人的父亲”除了我之外别无他人。如果是同一个人，你就可以画出下面的图，这与第二行文字不矛盾：

 

接下来，我会期待任何程序员能快速地解决这个谜题 – 毕竟，他们是问题的解决者。但是问题的关键是某人必须在谜题被解决之前创造出谜题。而问题创建的技能是与问题解决的技能不一样的。在这个例子里，谜题的创建者需要把两个情况搅和在一起，知道父亲不涉及他们自己的儿子或者他们自己不一定是那个人的父亲。技巧在于知道如何误导谜题的解决者。
这个例子与软件测试关系挺大的，因为测试人员要做的其中一个事情就是去考虑是否两个不同的名字会跟同一样东西关联。（“如果输入数据的文件跟输出的log文件是一样的呢？代码是否会在重写文件之前读一下？”）
现在，程序员可能会跳出来说，我们也能考虑到这样的情况。他们是通过修改bug学到的。然而，测试员比开发人员更能找出问题来：
这是他们唯一要做的事情。他们看到过很多的bug。他们关于bug的思考会更多。他们花更多的时间在形成问题上。
就像谜题的创建者很清楚谜题的解决者一样，测试人员研究程序员目的是为了洞悉程序员可能忽略的问题的类型。程序员很难考虑到他们不深入思考的问题。

测试人员还会研究用户，特别在清楚用户知道什么、真实的用户会做什么可能的操作方面。程序员很难去做这些东西。他们可能没有这么多的时间。他们过多地陷入他们的解决方案里，而不会把自己置身于用户的角度
因此，测试人员做的事情是通过呈现某些特定的细节（以测试用例的方式）帮助程序员掌握相关的技术细节，而这些细节本来很可能不会引起他们的注意。不幸的是，你通常太晚才呈现这些细节（在代码写完后），因此揭示的问题是抽象概念或它们的使用方面的问题。但是那是把测试人员过迟地放到项目中的副作用，也是认为测试人员只是执行测试而不是设计测试的不幸的观念的副作用。如果程序员能及早地了解到细节，问题就不会发生了。
程序员帮助测试人员描述他们是怎样测试程序的。这有两个好处。第一，它能帮助测试人员理解程序员的盲点是什么。第二，它照亮了测试人员的盲点 – 当然测试人员也会忽略一些东西。
那是很理性的情况。测试人员通过提供详细的细节给程序员来掌握，从而帮助程序员实现他的真正能力。这是程序员容易接受的论点 – 至少暂时接受。但是在实践中会碰到障碍，它们很可能是跟bug报告相关的。在第三章将讨论这个主题。
你需要解释的关于你自己的其它怪癖
包含开发人员与测试人员之间个性的比较。我需要强调其中的3点，因为我看到过它们导致的摩擦。
测试人员能容忍冗长乏味的工作任务；程序员则想办法自动化这些工作。
当开发人员转向测试的时候，往往只是专注于自动化测试。（有时候他们花费了很多的时间在自动化的支持上，而不去写任何实际的测试…）当程序员看到测试人员手工地运行测试时，尤其是重复地执行相同的测试，关于测试人员能力不强的观点又加强了一些。明确地反对手工测试，指出自动化测试的经济有效，但是他们大概不会去权衡一下。由于篇幅限制，我不能展开讨论，让你知道不仅仅需要权衡自动化测试的时间和手工执行N遍测试的时间。
测试人员能快速学习；程序员倾向于全面的理解。
每个人都赞赏能快速学习的人，但是程序员可能不会意识到通常测试人员面临的是几乎没有时间去学习一个产品的情况。那诱发了人们“摘挂得比较低的水果”（选择轻而易举的目标去实现）的想法：找出他们需要知道的东西，找到重要的bug，然后继续。因为程序员重视完整性，这样的测试人员看起来是肤浅的而不是有效率的，除非你给他们解释你的工作。
测试人员相信无知是重要的；程序员认为专业是重要的。
测试人员知道对于产品构成的无知和所谓“正确使用方法”的无知能让他们发现程序员忽略的东西和用户会看到的东西。比用户更专业其实是危险的事情。问天真的问题能产生令人惊讶的答案。需要让程序员知道“天真”是一种有预谋的策略，不是缺点。