【原创】Google 软件测试流程中的致命缺陷

前面我已经写了三篇关于《Google 软件测试之道》的荐读和读书笔记，这是我读完一本书之后写读书笔记最多的一次了，主要是因为他引发了我太多的思考，也开拓了我对于测试未来的想象。

前三篇可以点击链接查看：
Google 软件测试之道
Google 软件测试之角色职责
Google 软件测试的未来

今天是这个系列的第四篇，仍然是关于书中第五章的内容解读。

第五章中 James 除了阐述 Google 软件测试的未来之外，还着重提到了 Google 流程中的致命缺陷，里面有一些和我们目前的情况十分相似，另一些则警示我们要提前注意可能出现的问题。

下面我会针对这些缺陷，逐个进行说明。

缺陷一：测试成了开发的拐杖。

本来质量是所有人的事，但是因为有了测试部门的存在，开发人员越来越少的考虑质量问题，越来越不会去测试，因为他们认为质量是测试人员的责任。

关于这点，应该是有共识的，有反馈找测试，漏出 bug 找测试，所有问题都可以归结为一个终极问题「为啥测试没有测出来？」

如果继续目前的做法，这个问题是没法得到解决的，但是可以借助之前「测试即服务」的方法间接解决。

我们服务于产品，在需求阶段解决需求问题。
我们服务于开发，在编码阶段解决架构和技术实现的问题。
我们服务于用户，从用户角度解决体验性问题。
我们服务于质量，深层次挖掘逻辑问题。

缺陷二：开发和测试的隔离，阻碍了测试人员对产品的关注。

James 要表达的是 Google 独立的测试部门，导致他们更注重测试工作本身的事情，从而忽略了我们是为业务服务的大目标。

这个在国内目前的环境，基本不是问题，甚至部分公司会出现测试过于依赖业务，进而失去了自己作为测试应该具有的独特视角，仅仅成为一个工具。

我理解只要记住两点就够了：

测试是为保障质量服务的；
质量保证是为业务目标服务的；

</