哪些流程中致命的缺陷

测试通常被看做是质量的代名词，如果你问一位开发人员做了哪些与质量相关的事,他的回答往往是“测试”。

可是测试并不能保证质量。质量是内建的，而不是外加的。因此，保证质量是开发者的任务，这一点毋庸置疑。

这就带来了第一个致命的缺陷：测试成了开发的拐杖。

我们越不让开发考虑测试的问题，把测试变得越简单，开发就越来越不会去做测试。

比如：我们坐在舒适的沙发里看电视的时候，有人来为我们修剪草坪。

而实际上，我们是可以自己修剪草坪的。

更糟糕的情况是，当他们在为我们修剪草坪时，我们却坐在家里，什么事儿也没有！

修剪草坪的服务让我们很轻松，是太轻松了，以至于想都不想就外包出去了。

当测试也成为一种服务，能让开发想都不想的时候,那他们就会真的什么也不想了。

测试应该需要一点痛苦，需要开发人员费点心思。

某种程度上我们已经把测试变得太轻松，把开发养得太懒了。

第二个致命缺陷，还是与开发和测试的组织结构分离有关。

测试人员更关注自己的角色，而不是他们的产品。

如果产品不被关注，那它就好不了。毕竟，软件开发的最终目的不是编码，不是测试，不是文档，而是完成一个产品。

每一个工程师的角色都是为总体产品服务的，而角色本身是次要的。

健康的组织的一个标志是，人们会说“我在为某个产品工作”，而不是“我是测试”

任何角色都不应被过分强调。

团队的每个人都是在为产品工作，而不是为了开发过程中的某个部分。开发过程本身就是为产品服务的。

除了做出更好的产品，流程的存在还有其他目的吗?用户爱上的是产品，而不是开发产品的流程。

第三个致命的缺陷，是测试人员往往崇拜测试产物胜过软件本身。

测试的价值是在于测试的动作，而不是测试产物。

相对于被测代码来说，测试工程师生成的测试产物都是次要的:测试用例是次要的;测试计划是次要的；bug报告是次要的。

这些产物都需要通过测试活动才能体现价值。

不幸的是，我们过分称赞这些产物(比如在年度评估时，统计测试工程师提交的bug 数目)，而忘记了被测的软件。

所有测试产物的价值，在于它们对代码的影响，进而通过产品来体现。

独立的测试团队，倾向于把重点放在建设和维护测试产物上。

如果把测试的目标定位在产品的源码上，整个产品都将受益。

因此，测试人员必须把产品放在第一位。

最后一个致命缺陷也许是最深刻的。

产品经过最严格的测试发布以后，用户有多大可能仍然发现测试中遗漏的问题？答案是：几乎必然发现。

我们谁都没见过哪个产品能够避免漏测问题所带来的困扰。

我们想象自己是用户，而内部使用者就是真实的用户。

是谁做测试不重要，重要是进行了测试。