测试通常被看做是质量的代名词，如果你问一位开发人员做了哪些与质量相关的事,他的回答往往是“测试”。
可是测试并不能保证质量。质量是内建的，而不是外加的。因此，保证质量是开发者的任务，这一点毋庸置疑。
这就带来了第一个致命的缺陷：测试成了开发的拐杖。
我们越不让开发考虑测试的问题，把测试变得越简单，开发就越来越不会去做测试。
比如：我们坐在舒适的沙发里看电视的时候，有人来为我们修剪草坪。
而实际上，我们是可以自己修剪草坪的。
更糟糕的情况是，当他们在为我们修剪草坪时，我们却坐在家里，什么事儿也没有！
修剪草坪的服务让我们很轻松，是太轻松了，以至于想都不想就外包出去了。
当测试也成为一种服务，能让开发想都不想的时候,那他们就会真的什么也不想了。
测试应该需要一点痛苦，需要开发人员费点心思。
某种程度上我们已经把测试变得太轻松，把开发养得太懒了。
第二个致命缺陷，还是与开发和测试的组织结构分离有关。
测试人员更关注自己的角色，而不是他们的产品。
如果产品不被关注，那它就好不了。毕竟，软件开发的最终目的不是编码，不是测试，不是文档，而是完成一个产品。
每一个工程师的角色都是为总体产品服务的，而角色本身是次要的。
健康的组织的一个标志是，人们会说“我在为某个产品工作”，而不是“我是测试”
任何角色都不应被过分强调。
团队的每个人都是在为产品工作，而不是为了开发过程中的某个部分。开发过程本身就是为产品服务的。
除了做出更好的产品，流程的存在还有其他目的吗?用户爱上的是产品，而不是开发产品的流程。
第三个致命的缺陷，是测试人员往往崇拜测试产物胜过软件本身。
测试的价值是在于测试的动作，而不是测试产物。
相对于被测代码来说，测试工程师生成的测试产物都是次要的:测试用例是次要的;测试计划是次要的；bug报告是次要的。
这些产物都需要通过测试活动才能体现价值。
不幸的是，我们过分称赞这些产物(比如在年度评估时，统计测试工程师提交的bug 数目)，而忘记了被测的软件。
所有测试产物的价值，在于它们对代码的影响，进而通过产品来体现。
独立的测试团队，倾向于把重点放在建设和维护测试产物上。
如果把测试的目标定位在产品的源码上，整个产品都将受益。
因此，测试人员必须把产品放在第一位。
最后一个致命缺陷也许是最深刻的。
产品经过最严格的测试发布以后，用户有多大可能仍然发现测试中遗漏的问题？答案是：几乎必然发现。
我们谁都没见过哪个产品能够避免漏测问题所带来的困扰。
我们想象自己是用户，而内部使用者就是真实的用户。
是谁做测试不重要，重要是进行了测试。
