一
之前我发了两篇关于《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，我也没看懂）。
最后，书中还提到了测试基础设施在未来最终都会整体迁移到云端。
主要特点是云端实现、集中管理、数据共享并相互关联，一方面是减少重复造*的资源消耗和维护成本，另一方面可以让更多的人来参与、维护和构建这些基础设施。
关于这点，我觉得公司内部在某种程度上是可以达到这个程度的，但是更大范围的共享，确实是个有待商榷的问题。