经验40,如果自己知道自己不聪明，就更难被愚弄

　　骗子说，最容易上当的人，是绝对自信不会被愚弄的人。作为测试员也可以把这条定律用于自己的工作中。证明自己容易被愚弄。做到这一点并不难，只需仔细看看自己在测试中犯的错误。任何时候都要注意其他测试员所发现的自己本来也可以发现，但是没有发现的问题。

　　如果真心认为自己容易被愚弄，也会比较谨慎一点，在考虑自己的测试策略细节时就会更认真一点。这是一种新测试员能够提高的最快的方法之一，因为知道自己可以被愚弄是一种态度,并不是特殊技能或知识。新测试员的问题是，对于他们来说，这个定律只是一条信仰(“人家告诉我，我应该认为我可以被愚弄……”)，而有经验的测试员的感觉和反应，会通过实际教训唤起和加强(“我还觉得1994年的那次大教训。我们怎么也没有想到病毒会感染我们自认为性能非常可靠的磁盘。我的声誉在这一天全给毁了”) 。
经验41,如果遗漏一个问题，检查这种遗漏是意外还是策略的必然结果

　　如果掷币猜边时，猜的是国徽面，出现的却是字面．这是否意味着做出了差的决策?以任何理性的观点看都不是这样。除非在硬币上做了手脚，否则出现任何一回的机会都是50％。出现字面没有什么可奇怪的，只是不够幸运罢了。决策策略没有问题。

　　在测试过程中没有发现程序错误时也存在同样问题，同样也会困扰客户。在研究测试策略出现了什么问题之前，先不要自责。出现遗漏，是否因为忠实地执行了好的测试策略，并只是碰巧没有发现那个特定的问题?如果是这样，可保持原有方针不变。确实有这种情况。但是，如果遗漏程序错误是因为测试策略关注了错的问题类型,可利用这个机会改进测试策略。

经验42,困惑是一种测试工具

　　当测试员感到困惑时，这可能是某种重要的预示。

·规格说明不清楚吗?规格说明中的模糊点，常常是为了掩盖有影响力的项目相关人员之间的重要分歧。

·产品不清楚冯?产品可能有严重问题。

·用户文档不清楚冯?产品的这个部分可能太复杂，有太多的特例和不一致性要描述。

·内部问题只是难以理解呜?我们试图自动化的有些系统具有内在的复杂性，或包含复杂的技术问题。程序员也认为它们复杂、困难,并导致自己犯遗漏、误解和过于简化的错误。

　　测试员对产品、技术和一般测试问题了解得越多，自己的困惑就会成为更有力的指南针，指出重要问题所在。

　　在测试过程中，如果对产品一无所知，那么至少知道自己在困惑。在这种情况下，困惑可以成为最佳交付内容，即提出也许其他人没有勇气提出的问题。
经验43,清新的眼光会发现失效

　　理解事物，是把新信息吸收到已知信息中，同时修改已知的信息以适应新信息的高智力过程。测试员在理解了产品或功能部件之后，会在头脑中形成映射，并且头脑不再那么努力工作。对于测试员来说这可能是个问题。当非常了解产品后,会对产品做出更多的假没，并更少检查这些假没。

　　这种情况对于测试至少有三点提示：

·第一次接触产品或功能时，要特别注意使自己困惑和烦恼的地方。这可能    说明用户也会有类似反应。

·当与团队的新成员一起工作时，与他们一起测试。观察他们在了解产品时的反应。

·警惕陷人测试惯例。即使没有遵循严格的测试脚本，也可能对特定功能太熟悉，以至于以越来越窄的方式进行测试。在任何可能的地方引人多样性,或改由其他测试员负责。

经验44,测试员要避免遵循过程，除非过程先跟随自己

　　警惕其他人的过程。测试用例和过程的描述，常常不提测试的内部设计目标。这非常容易使测试员在执行测试时并不太理解如何建立测试,或寻找什么。换句话说，测试员并没有真正跟上过程。一般来说，测试过程的编写和设计都比较差，因为没有多少优秀测试员像擅长计算机那样擅长程序设计人员的工作。如果要遵循测试过程，最好采用自己设计、自己拥有或已经完全了解的过程。

　　为了得到最好结果，测试员必须掌握自己的测试，而不是自己的文档。要使过程跟随自己。

　　如果确信那些过程很好，也至少要研究一下过程的工作原理。请参阅《使我们聪明的事物：机器时代的人性保护》(Things that Make Us Smart : Defending Human Attributes in the Age of The Machine)(Norman l993)和《信息的社会寿命》(The Social Life of information)(Brown和Duguid 2000)。
经验45,在创建测试过程时，避免”1287”

　　我们中的Bach曾经见过一位测试员编写的测试过程包含”在字段中输入1287个字符。”这1287是从哪里来的?测试员解释说．她的测试想法只不过是在一个小输入字段中，输入非常多的字符。因为她听说测试过程必须具体，因此小心地数了自己已经输入的字符数，1287,这就是过程中的这个数的由来----一个任意数，现在却被永远供奉起来,就像是印在水泥人行道上的猫的脚印一样。

　　过于详细没有什么好处。当编写测试过程时,要避免与测试概念无关的细化。包含所有必要的信息和设计与解释测试所需的细节，但是要让未来的测试员有创造性和判断力地执行，让未来测试员引入变化以使现在所编写的测试过程新鲜、高效。

经验46,测试过程的一个重要成果，是更好、更聪明的测试员

　　我们经常听到反对产生很少或不产生文档的测试的理由，好象测试的惟一价值就是通过测试产生的文档。这种观点忽略了测试的一种意义深远的重要产品：测试员本身。

　　好的测试员永远都在学习。随着项目的进展,他们不断加深对产品的了解，逐渐从各个方面提高对产品的反应能力和敏感性。了解产品并已经经历过一两次产品发布的有经验的测试员，即使没有任何指示，但与有一套如何测试产品的书面指示的没有经验的测试员相比，他们测试的有效性也要高得多。

　　软件测试领域内的一些顾问和论文作者看起来相信，只要提供测试过程，测试效果差的测试员就可以变成测试效果好的测试员。在我们看来，这是一种差的实践，这反映出他们对测试和进行有效测试的人的根本误解。

　　在评估测试过程时，首先要看项目测试员的素质,要看他们怎么思考，以及这种思考怎样对其行为产生影响。只有掌握了这些信息才能评估他们的工作产品。
经验47,除非重新发明测试，否则不能精通测试

　　不要彻底改造轮子。请等一下,难道轮子不是历史上被重新发明次数最多的吗?这不是好事情吗?毕竟我们的汽车是装在充气轮胎上，而不是花岗岩圆盘上。轮子如果说不是数以百万计的话，也有数以千计的变种。也许我们可以从中得到启发。在我们看来,重新发明东西至少有两个原因：通过改造使其适应新条件,了解其工作原理。而要掌握它，这两个方面部需要。

　　我们有的同事忠告测试专业的学生不要重新发明测试,也不要重新发明测试思想。我们不同意这种观点。这就像是学习科学又不想做实验一样。通过其他思想家进行学习是没有错的，我们认为这样学习是很重要的。但是如果这是学习的惟一方式，那永远也不会成为测试技艺的行家。这样的人将是技术员，但不会再进一步了。按照指示做不会掌握任何东西，就像要沿高速路上火星一样。我们提倡要像伟大的机械师和伟大的程序员那样地学习测试：把东西分解，琢磨其工作原理．再以新的方式组装到一起。不要把自己限制为只是接受智慧的服务者，而应该使自己成为智慧的创造者。

　　在学习过程初期，要重新发明不是非常好的测试、想法、手段和文档。这是正常的。要永远使头脑运转，观察其他测试员,研究和不断评估如何筛选自己的思想。如果想要善于做到这一点，就必须实践。

　　我们这样做已经有很多年了，我们仍然在重新发明，仍然在反思老的想法。我们所尊敬的每个同事都是这样走向精通之路的。