【原创】Google 软件测试的未来

一

之前我发了两篇关于《Google 软件测试之道》的荐读和读书笔记，有不少同学就在后台跟我说，咱们国内的环境和 Google 差的太远，任重而道远呀。

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

嗯，确实是这样，不仅仅是我们，就算是国外其他大公司，很多也都是和 Google 的方法不一样。

但是我推荐这本书并不是希望我们要全盘照搬 Google 的做法，每个公司都有自己独特的环境，我们不必去眼馋，但是我们一定要学习，要取长补短，要融会贯通，这才是读书的意义。

今天这篇是这本书相关的第三篇文章，主要想聊聊 James 在 2013 年所预见的 Google 软件测试的未来。

再多说一句，这也仅仅是 James 自己的理解，不完全代表 Google 的预期，更不能说明肯定是对的，我们去学习和了解他的观点，是为了让我们了解更多的信息，拓展我们自己的视角，如果能带来惊喜的火花就再好不过了。

二

James 在 2010 年出版的《探索式软件测试》一书中，就一直强调一个理念：质量是所有人的责任。

直到 2013 年的这本《Google 软件测试之道》，这个理念也一直贯穿始终。

在 Google 软件测试改进中，他预言到这个目标终究会达成，其他对未来的预言都是基于这个前提。

如果真的实现了全员保证质量的目标，确实是不再需要区分独立的测试角色，毕竟测试的工作已经完全被其他角色取代，测试变成了完全的辅助者角色，辅助其他角色更好的进行质量保证。

理想很丰满，现实很骨感。

国内目前的环境，距离这个目标的差距还是很远，先不说需求实现的质量，仅仅是冒烟测试通过这个基本的要求，目前很多开发都达不到，测试仍然只是测 + 试的角色。

这个问题的原因不单单是因为测试，和整个行业发展也有一定的关系，目前整个软件行业都处于一个急速膨胀的发展阶段，很多人员的素质和能力并没有经过严格的筛选和培养，既然这样，各方面的人员素质都达不到统一要求，就算测试再努力，也是事倍功半。

那我们要不要往这个方向努力呢？当然需要，有些发展阶段是绕不过去的，我们要做的就是脚踏实地的趟过去。

三

基于「全员保证质量」这个前提，书中分别阐述了 SET 的未来、TE 的未来以及测试管理者的未来。

SET 的未来就是开发。

从本来只负责可测试性、可靠性和可调试性代码实现的 SET，变为在功能代码中同时实现测试代码的开发工程师，从而出现具有测试思维的开发工程师。

关于这点，从我的经验看还是有问题的，主要集中在：

1.传承很困难。培养固定的几个人开发人员还好说，让他们内部去传承几乎不可能，所以没有持续性。
2.目标变了，行为也会变。比如以前举的例子，测试用例写的好的同学，写代码仍然会出现可以被自己的用例测出很多低级 bug 的情况，哪怕是这两个行为是连续进行的。

TE 的未来是测试设计。

主要特点是从之前自己负责测试，到自己规划、组织和管理内部试用者、可信赖的测试者、早期用户或者众包测试者等近乎免费的测试资源。

TE 的另一个方向是垂直方向的测试专家，比如安全性测试专家、性能测试专家等等。

关于这点，如果流程上能够满足敏捷开发要求的增量开发、灰度发布和持续迭代，我觉得还是有可能的，特别是对于用户体验相关的测试，完全可以由真实用户来测试，专业测试只做专业性的深层次的测试。

测试管理者的未来是思想领袖，为维系松散的测试工程师和负责质量的软件工程师的关系而存在（sorry，我也没看懂）。

最后，书中还提到了测试基础设施在未来最终都会整体迁移到云端。

主要特点是云端实现、集中管理、数据共享并相互关联，一方面是减少重复造轮子的资源消耗和维护成本，另一方面可以让更多的人来参与、维护和构建这些基础设施。

关于这点，我觉得公司内部在某种程度上是可以达到这个程度的，但是更大范围的共享，确实是个有待商榷的问题。

以上，今天主要聊了 James 预言的 Google 软件测试的未来，以及涉及的 SET、TE 和测试管理者角色的未来，最后又提到测试基础设施的未来，期间我也表达了自己的观点，不知道你看完后是否认可？是否有其他见解？欢迎留言告诉我你的想法。

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