Google 软件测试流程中的致命缺陷

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

前三篇可以点击链接查看：

Google 软件测试之道

Google 软件测试之角色职责

Google 软件测试的未来

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

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

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

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

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

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

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

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

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

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

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

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

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

缺陷三：测试人员往往过于崇拜测试产物。

这点主要强调的还是测试太过于关注测试本身，比如测试流程、计划、用例、工具、系统、bug 等等，所有这些都是测试过程的产物，所有这些产出的目标都应该是为了保证产品质量。

这其实牵涉到另一个比较大的话题「如何进行软件测试人员的绩效考核」，考核目标不一样，对应的就是大家的关注点的不一样，所以这个方面每个公司根据自己现状不同，都是有一些差异。

总体来说，James 表达的这个意思是没问题的，确实业务是最终的目标，测试人员应该把产品放在第一位，目前剩下的就是怎么去制定合理的考核指标，让我们的目标和业务目标能够保持一致。

缺陷四：产品经过测试后并仍然会遗漏问题。

这点确实没法完全保证，James 指出的原因是 TE 只是想象自己是用户，而试用者是真实的用户，所以才会漏出问题。

从我的经验看，其实可以分为两种情况考虑。

一种是功能问题的漏出，比如逻辑分支缺少用例覆盖。

这种肯定就是测试人员的问题了，有可能是需求没有搞透彻，有可能是实现逻辑没有弄清楚，有可能是自己用例设计的方法不熟练，解决办法当然是对症下药。

另一种是用户场景的遗漏，比如真实用户使用产品的操作方式没有覆盖到。

这种情况，产品、开发、测试和运营部门都是应该参与试用的，特别是作为产品的第一批用户，我们应该在我们的生活场景中去使用我们的产品，而不仅仅是想象我们的角色，一定要作为真正的真实用户去使用产品。

当然，内部试用、灰度发布和快速迭代也可以解决这个问题，但是这时候漏出的问题应该是符合预期的，因为本来就是期望他们来发现这些体验性问题。

以上，James 提到的 Google 流程中的缺陷在你当前流程中是否存在同样的问题？目前是怎么解决的？是否有更好的解决方案？欢迎留言说出你的想法。

当然，如果你觉得我上面的内容对你有启发，请帮忙转发 + 点个「赞」让更多人看到，谢谢。