最近因为招聘，所以经常会跟一些比较优秀的大厂同学聊天，无意中得知了这样一些信息。

腾讯的pcg已经在逐步干掉测试了，这是所谓的去测试化。

这里的干掉指的是日常的测试工作交给外包去做，曾经的正式员工往效能提高的方向去转型，做一些研发效率度量，质量度量以及效能提升的工作。

去测试化万口传，至今已觉不新鲜。

最早听说这个词应该是在2016年左右，正好是5年前。当时我们公司来了一批微软的测试专家，从他们口中得知微软总部在去测试化，之前的测试人员转做测试工具或者效率工具开发，开发尽可能的多写测试用例，一些实在需要人工覆盖的场景可以交给外包去做，所以现在微软应该没有测试这个角色了。尽管在做出这个决定的初期，微软产品的整体质量似乎是出现了一些不可避免的下降现象，比如win10之前出过非常多的bug，但是微软后来迅速走出了困境，整体的产品质量有了一定的提升。

不过仔细一想微软是有这样做的资本的。在操作系统领域，哪怕windows的质量有了一定程度的下滑，但是对于大部分人来说，要么是没有选择，只能默默忍受，要么就是选择不升级，停留在之前的稳定版本里。所以对于一个在市场上占主导地位的公司或者产品，没有了活下去的压力，去测试化可能是一个不错的选择。将质量保障的压力传导给开发，这是最行之有效提升代码质量的方法。我记得很久之前分享过，如果一个项目中开发很强，测试相对不强，那么这个项目的质量其实是可控的；相反开发能力很弱，但是测试很强，产品的长期质量我其实是看衰的。再看一些很流行的开源项目，这些项目中似乎只有开发，他们写用例，做code review，发布代码，然后开源项目的使用者其实就是测试，他们试用产品，提出问题，寻求解决方案或者直接贡献代码解决。因此微软的去测试化其实就是让开发多做测试，让用户当小白鼠，反正用户的选项不多，也不是很怕用户流失。

后来在18年左右，又听说一家公司在做去测试化，那就是字节。

当时跟字节的一个部门负责人交流的时候，他说他们很欣赏微软的理念，要对标微软去测试化。测试人员主要的职能有

• 提升测试效能，让开发会写用例以及提供相应的工具让测试的效率可以提升
• 测试管理，大体是做流程管理和推动，顺便管管外包和实习生，似乎字节有让实习生做测试的传统

字节和微软不一样，字节应该是一家非常焦虑的公司，偏平的架构和不成功便成仁的kpi导向，使得这家公司的策略可能会偏向激进，所以作出去测试化的策略是可以理解的。毕竟字节产生产品的速度和放弃产品的速度一样快，一个产品因为质量不行而被诟病其实问题比较好解决，要么放弃掉，要么重新做一个。

到了今天腾讯的一些部门也坚定的站在去测试化这一阵营，综合分析起来其实是可以理解的。

• 来了新的gm，推进自己的技术理念
• 稳定的产品占据市场主导地位，质量下降带来的副作用在短期内是可以接受的
• 产品开发的快，放弃的也快，跟字节类似，所以一旦有质量问题，要么重新来做，要么直接放弃
• 腾讯老一代的开发基本上新陈代谢的差不多了，向这部分人灌输开发做测试的概念其实比较难；但对于新鲜血液来说，推一推总是有办法的

所以我们可以有理由相信，对于一些在行业内有一定垄断地位的大厂来说，去测试化应该是大势所趋。

那么我们测试同学应该何去何从呢？

• 转型为测试开发，专心打辅助，开发质量度量工具，测试效率提升工具以及其他各种工具，另外还要教开发写测试用例，这是测试左移，可能不需要背锅
• 大厂不好混可以去二线厂，只要市场没有被巨头垄断，其他玩家必定重视质量和口碑，这里测试同学的机遇和挑战并存，可能需要背锅
• 转型为测试管理，大厂还是要有人做流程管理，外包管理，质量管理，职位不多，但有需求
• 转型为开发，说句实话，在相同的预期条件下，写业务逻辑很多时候比写工具要简单，不过转开发要趁早，因为对于开发来说，你之前的测试经验可能是一文不值的
• 转产品，我认识好几个转产品的测试同学，还是同样的道理，转要趁早
• 转行，换个行业和赛道，想象的空间可能更大

不知道大家有什么样的想法，欢迎在评论区留言讨论。