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

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

        接下来，我会期待任何程序员能快速地解决这个谜题 – 毕竟，他们是问题的解决者。但是问题的关键是某人必须在谜题被解决之前创造出谜题。而问题创建的技能是与问题解决的技能不一样的。在这个例子里，谜题的创建者需要把两个情况搅和在一起，知道父亲不涉及他们自己的儿子或者他们自己不一定是那个人的父亲。技巧在于知道如何误导谜题的解决者。 
        这个例子与软件测试关系挺大的，因为测试人员要做的其中一个事情就是去考虑是否两个不同的名字会跟同一样东西关联。（“如果输入数据的文件跟输出的log文件是一样的呢？代码是否会在重写文件之前读一下？”） 
        现在，程序员可能会跳出来说，我们也能考虑到这样的情况。他们是通过修改bug学到的。然而，测试员比开发人员更能找出问题来： 
        这是他们唯一要做的事情。他们看到过很多的bug。他们关于bug的思考会更多。他们花更多的时间在形成问题上。 
        就像谜题的创建者很清楚谜题的解决者一样，测试人员研究程序员目的是为了洞悉程序员可能忽略的问题的类型。程序员很难考虑到他们不深入思考的问题。（注：要想研究好程序员，你需要成为一名好的观察者。我推荐大家看[Weinberg85]和[Weinberg93]。学习其他人已经观察到的东西，可以参见[Gabriel96]，[Hohmann97]，[Lammers86]，[Levy84]，[Turkel84]，[Weinberg71]和[Weizenbaum76]。） 
        测试人员还会研究用户，特别在清楚用户知道什么、真实的用户会做什么可能的操作方面。程序员很难去做这些东西。他们可能没有这么多的时间。他们过多地陷入他们的解决方案里，而不会把自己置身于用户的角度。（注：在斯德哥尔摩综合症那一节，我提到一些书可能帮助你学习更多关于你的独特产品的用户：[Moore91]，[Cusumano95]，[Gause89]，[Hohmann97]。我没有读关于大众用户的很多书，但是我可以推荐[Cooper95]，[Norman90]，[Nielsen93]。） 
        因此，测试人员做的事情是通过呈现某些特定的细节（以测试用例的方式）帮助程序员掌握相关的技术细节，而这些细节本来很可能不会引起他们的注意。不幸的是，你通常太晚才呈现这些细节（在代码写完后），因此揭示的问题是抽象概念或它们的使用方面的问题。但是那是把测试人员过迟地放到项目中的副作用，也是认为测试人员只是执行测试而不是设计测试的不幸的观念的副作用。如果程序员能及早地了解到细节，问题就不会发生了。 
        程序员帮助测试人员描述他们是怎样测试程序的。这有两个好处。第一，它能帮助测试人员理解程序员的盲点是什么。第二，它照亮了测试人员的盲点 – 当然测试人员也会忽略一些东西。 
        那是很理性的情况。测试人员通过提供详细的细节给程序员来掌握，从而帮助程序员实现他的真正能力。这是程序员容易接受的论点 – 至少暂时接受。但是在实践中会碰到障碍，它们很可能是跟bug报告相关的。在第三章将讨论这个主题。 
        你需要解释的关于你自己的其它怪癖
[Pettichord98]包含开发人员与测试人员之间个性的比较。我需要强调其中的3点，因为我看到过它们导致的摩擦。 
        测试人员能容忍冗长乏味的工作任务；程序员则想办法自动化这些工作。 
        当开发人员转向测试的时候，往往只是专注于自动化测试。（有时候他们花费了很多的时间在自动化的支持上，而不去写任何实际的测试…）当程序员看到测试人员手工地运行测试时，尤其是重复地执行相同的测试，关于测试人员能力不强的观点又加强了一些。明确地反对手工测试，指出自动化测试的经济有效，但是他们大概不会去权衡一下。由于篇幅限制，我不能展开讨论；见[Marick98b]，让你知道不仅仅需要权衡自动化测试的时间和手工执行N遍测试的时间。 
        测试人员能快速学习；程序员倾向于全面的理解。 
        每个人都赞赏能快速学习的人，但是程序员可能不会意识到通常测试人员面临的是几乎没有时间去学习一个产品的情况。那诱发了人们“摘挂得比较低的水果”（选择轻而易举的目标去实现）的想法：找出他们需要知道的东西，找到重要的bug，然后继续。因为程序员重视完整性，这样的测试人员看起来是肤浅的而不是有效率的，除非你给他们解释你的工作。 
        测试人员相信无知是重要的；程序员认为专业是重要的。 
        测试人员知道对于产品构成的无知和所谓“正确使用方法”的无知能让他们发现程序员忽略的东西和用户会看到的东西。比用户更专业其实是危险的事情。问天真的问题能产生令人惊讶的答案。需要让程序员知道“天真”是一种有预谋的策略，不是缺点。

1. 报告Bug

        在这一章节我描述怎样报告bug，从而帮助建立有效的关系。它不要求你使用前两章介绍的方法和技巧。对于更广阔的讨论范围，我推荐[Kaner93]和[Kaner98]。 
        Bug报告是展开你和开发人员之间的关系的一部分。你在报告bug时做两件事： 
        提供关于程序状态的信息。这是bug报告为人熟知的目的。 
        提供关于你的信息还有程序员能依靠你的程度的信息。 
        一开始，开发人员可能会怀疑。一些程序员有测试人员浪费时间在报告无用的bug的不好经验。有些程序员则听到很多关于测试人员的恐怖故事。你必须让程序员相信你是有用的人，是个值得在身边的人。有3部分内容你可以做。
不要浪费他的时间 
        Bug报告不应该让他来猜测你提供的信息。 
        如果可能，把能重现bug的清晰的操作步骤包括进去。写完后，在提交bug报告之前尝试一下步骤序列。确保你有一个清楚明确描述的开始状态（例如，确保你退出程序并重新启动）。 
        把你期待要发生的、实际发生的描述清楚，还有为什么这样不对。 
        大部分程序员喜欢获得能在最短的步骤下能重现缺陷的bug报告。有些则不喜欢，因为那没有真正节省他们的时间。（例如，GNU C编译器的缺陷报告方法说明书就清楚地告诉你不要因为需要举个小的例子而怕麻烦。） 
        其它也会导致错误的步骤序列能帮助程序员更快地发现错误的原因，但是不要琐碎地描述每个操作序列的差异。那同样会浪费程序员的时间来决定是否有新的东西。（可能会耗费你很多时间去看那些细节从而决定存在的变化是微不足道的。） 
        描述一些能成功的场景（令人惊讶地），也会有所帮助 
        如果问题在他的机器上不出现，要尽快发现他的机器与你的机器的差异在什么地方。检查bug报告使其反映对配置的依赖。学习产品是如何对配置敏感的。（当然，这对查找配置方面的bug也会有用。在测试的早期，对帮助开发人员扫除障碍很有用。）
保持自己置身事外 
        冷酷地把任何隐含个人批评的语句从bug报告中擦掉。你也许需要让一些bug报告“晾”上一个晚上，然后以一种新的眼光来读它。你可能会发现问问题会比做出武断陈述要安全点。（不要忘记问一些诚恳的问题，你需要学习的还有很多。）问一下你自己当发现你认为是bug的问题原来是正确的行为时会有什么感觉。如果你会感觉像个傻瓜，那么同样地，很可能你在bug报告中的某些措辞也是有问题的。 
        不要试图解决你报告的问题。你也许没有足够的很好地解决问题的能力。尝试这样做可能会带来反效果。
用重要的bug展示你的价值 
        你和你的程序员之间可能会对什么是重要的持有不同的观点。你可能也像我一样认为可用性问题时很关键的问题。但是程序员可能不这样认为。你如何解决这个冲突？你可能把一些可用性的问题抛给他，希望说服他修改。或者，你首先抛给他那些他认为重要的bug，bug是如此重要以至他认为自己被抓住了。然后，慢慢地建立对某人的观点是有道理的这样的信任，你就可以扩展“重要的”范围，把可用性的bug也包括进来。 
        你或许在想我倾向于后面的方法。我曾经保留不是那么重要的bug，等到我获得了程序员的尊重后才把它们报告出来。那样做不容易，尤其是那些bug是程序员也认可，只是认为优先级要低点。假设我被公共汽车撞了怎么办？如果这个程序员被调到其它任务，现在连最小的bug也不能修改怎么办？但是有时候我认为那是能做的最有效的事情。 
        这里是其它一些让他们关注重要的bug的方法。 
        解释为什么对于顾客来说这是个重要的bug。如果你的场景被指责说不切实际，那么想出一个更真实的场景来展示这个bug。如果你的程序员说没有哪个真正的用户会这样做，那么首先仔细地想想他说的有没有道理。他可能是对的。如果不是，收集维护你的观点的好的论据。客服人员是怎样说的？

版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。