选择一个有效的角色

在这一节，我首先描述一下我喜欢的角色和这个角色的日常工作。然后描述这个角色解决的问题，最重要的是，可能产生的新问题。
假设你被告知要测试某个开发人员的工作，也许是增加了一个新特性到产品中。你也许要同时测试多个开发人员的程序，但是我会在后面的章节覆盖这些复杂的情况。我假设你会在编码阶段开始工作：在开发人员开始写第一行代码后，但在它被完成之前（除了修改bug的情况外）。如果你在更早的阶段介入，那会更好，但是我不假设那种情况。如果你在代码完成后才开始进入你的工作，那么这个章节的作用除了帮助说服你承认下次应该早点介入外，就作用不大了。它也不能应用在那些你不会去找一个开发人员的工作的bug的地方，例如配置测试、压力测试或其它类型的测试。
测试组是为谁服务的？一个普遍的回答是“顾客”。在这种模型下，测试人员站在顾客那边，为顾客服务，保护顾客的利益。顾客是一个无助的少女，被绑在铁轨上，一辆失控的火车（处于失控状态的产品开发）冲向她。只有测试人员才能救她，阻止火车（阻止产品发布 - 至少要到bug都修改完）。
这个模型有很多问题，不仅仅是这个模型几乎是不工作、不生效的。火车往往冲向少女，让她的救世主失落，士气低下、愤世嫉俗、工作效率低下[Marick97a]。然而对于这篇文章的目的而言，有一个问题是非常相关的：把人们想象成坏人的角色，对于想寻求他们帮助来说不是一个好的开端。不要误会：你其实是要花很多时间从开发人员那里寻求帮助的。你需要他们解释程序，这其实是在要求开发人员给你最宝贵的礼物：时间。你会登记bug并且希望开发人员聪明地处理它们，而不是寻找各种理由来宣布某个bug是一个特征而已，要求有更多的信息，或者干脆开始浪费你的最宝贵的资源：时间。
也许我有点夸张。也许没有开发人员会真正相信你在把他们想象成坏人。大概他们会相信某些更糟糕的事情：你把他们看成会频繁出错的人以致不可信赖。大部分开发人员会被认为是坏人而不是缺乏能力的人。但是不管反应的差别有多小，事实是这个模型给了开发人员和测试人员一个不一致的目标。开发人员希望早点发布；测试人员尝试阻止他们。开发人员的合作顶多是一种处于责任感的态度，甚至可能是不满的抵触态度：不可能达到让测试人员融合到项目组中的境界。
所以，如果不是为顾客，那么测试组应该为谁服务？
我认为应该是为那位对项目的所有事情负责任，并决定产品是否能发布的人而服务。“所有事情”包括了：了解竞争者在做什么；知道程序员因为疲倦而存在的风险，不能进一步提供好的程序，而是提供很糟糕的代码；清楚承诺没有实现带来的代价，产品延期发布给公司和顾客带来的损失。（见[Bach97]，会有更详细的讨论。）我把那个人叫做“项目经理”。测试组的工作是为项目经理提供其中一项精确的评估：产品的缺陷率（这个产品的bug多不多），主要是从顾客可能看到并关注的角度去看。
让我强调一点，测试人员仍然做的是相同的核心工作产品：bug报告。只是这些bug报告的使用方式不同。不是作为针对和指责产品的证据，而是作为提供给项目经理的信息，以便他做出更好的决定。
现在应该很清晰了，这个新的角色定位帮助你跟开发人员一起合作。从他们的角度看看：测试人员就在身边，不断尝试找出可能存在的问题，时刻准备着扑向bug并把它交给项目经理。当然没有人喜欢告密者或搬弄是非的人。
那么如何克服这些问题呢？一个解决办法是一个叫egoless programming（无私编程）的项目组结构，在这种团队里程序员不认为代码是他们自己的扩展，他们不自私，所以他们自己的错误对于他们来说没有那么多的威胁。然而，我不赞成这种方法，因为这意味着开发人员需要改变他们的行为，而不是我要改变。跟我一起工作的开发人员很少有无私的，但是我没有其它的选择，只能跟他们一起工作，接受这个现实的局限性。
我的解决办法是转移到private bugs（私有缺陷）和public bugs（公有缺陷）的差异上。私有缺陷是程序员产生的bug，但在把代码签入到公共源代码库之前修正了，它可能会对他的程序员同伴们造成潜在的危害，或者对后面的顾客造成影响。但是一旦bug已经出现，为了保护同伴，要求它必须被公开。（注意这个重要的区别：它不是为了处罚某个制造这个bug的人而公布，而是为了保护其他同伴。）
我作为一名测试人员给这些开发人员带来的信息是：我是来帮助他们把bug阻止在private阶段，防止他们出现在public阶段。转眼间，我变成了他们的盟友，成为专注于帮助他们变得更好的人。我的工作就是像他们的一张完全网一样地服务，专注于那些他们不能避免或自己找出来的bug。我是一个工具，作为开发人员的扩展（不要忘记，即使我们与开发人员紧密地工作在一起，他们其实通常都会自己找到更多的bug，比我们找到的要多。）
让我澄清一些东西。假设我的开发人员准备好了一块新的代码并且修复了3个bug。我会马上开始测试。唯一会使我推迟测试的是我已经在为另外一个开发人员在做相同的事情。
当我找到一个问题的时候，我会发Email给他。我通常不会把那些bug登记到公共的bug跟踪数据库中。我不会把它们跟其他测试员、其他开发人员、项目经理一起分享。它们是私有的。我用自己的Email目录记录并跟踪它们，除非开发人员要求我把它们公开地跟踪起来。
开发人员可能不能在把代码放到公共源代码库之前修改所有bug。我一般不同意这种决定，但是我接受开发人员的决定。（这跟我的关于测试组与项目经理的关系的观点是一致的。）如果他不修改bug，则我会把它从Email目录移到bug跟踪系统。因为现在这个bug是公开的，公众（项目经理、其它开发人员）需要知道它的存在。
我如果不是在找私有的bug，就是在找公开的bug。也就是说，我完成了测试的代码已经放到公共源代码库了。（也许它已经放到上面了，但是我没能及早分配到这个测试任务。或者是程序员需要让某些内容独立工作，出于演示demo的需要或出于让其它程序员的工作能正常进行的目的。）我在那里找到的bug是公开的并且会报告到公共的bug跟踪系统中去。
这样说有点过于简单化了，目的是想说明我的观点：帮助程序员寻找私有的bug。在现实中，事情会更加复杂点。假设刚刚完成的代码不是非常重要，但是代码中的bug已经是public的可能对其他程序员造成严重的阻碍。那么我可能会专注于public的bug。我总能得到开发人员的支持，原因在下个大章节解释。有时候，在项目结束之前，我需要确保所有代码都得到了充分的测试。稳定的变更的测试也不能阻止我这样做。