软件测试现状以及行业分析

大家都知道最近 ChatGPT 爆火,国外巨头争相宣布自己的相关计划,国内有点实力的企业也在亦步亦趋地跟进。不出意料的是,关于测试职业要被淘汰的话题又(为什么要说又?)在扎堆出现,内容跟之前还是大同小异,无非就是它会取代基础的功能测试岗位之类。话说关于 AI 的话题又不是头一回,大家怎么还没习惯呐?

今天我主要也不聊 ChatGPT,一来是因为关于它的文章实在太多,我没必要再去锦上添花;二来这种事情也不好太早下结论,还不如让子弹多飞一会儿。非要说实话,企业是想追一波风口,自媒体是想吸一波流量,还有一些机灵的人跟着赚一波外快,咱们普通吃瓜群众就别跟着瞎焦虑了。

但是出于对自身职业的尊重,我还是要说说关于测试的生存问题,我的结论是:测试行业近十年基本没有消失的可能性。这倒也不完全是出于个人感情或盲目自信,这个问题在数年前我还真的正儿八经研究过,后面几年的趋势观察下来也基本符合当初的推测,所以我想还是有一定的可信度的。

早前之所以会调查这个问题,是因为测试界有位挺活跃的人物(为避免口水战,就不提名字了)发表了一篇轰动一时的文章,内容大致是说:测试角色很快会被淘汰(去测试化),以后测试都会去开发平台,测试工作则赋能给了开发。巧的是这篇文章也被公司一位外企过来的高管看到,还跟我聊了聊这方面的可行性。

基于对自己饭碗的担忧,我还是比较认真地调查了国外像谷歌、微软,国内像 BAT 等名企发布的信息资料,分析了这些公司的测试生存状况和产品迭代模式,整理成了一份报告(涉及大量公司业务细节,就不分享了),主要结论就是:测试在中国现有的环境下,至少在可预见的未来内不会消失。

原因说起来其实并不复杂,稍加思考就能理解。去测试化的理论源头基本来自一些美企(主要参考的是 Google,但如果去研究 Google Testing Blog,对方其实也没说不要测试...),要说美企的一些管理理念的确挺前沿,但是仔细对比 BAT 的情况就不难发现,有三个因素决定这些模式在国内很难行的通:文化环境、行业水平、数字化基础。

先说文化环境。相对于国外企业更相信流程,国内企业则更(被迫)相信老板。前者是集体决策机制(自下而上),后者是中心决策机制(自上而下)。有句玩笑话说,外企的工作是为了 Do right things,国企的工作是为了 Do things that boss think is right。软件工程本来就是个复杂的专业问题,不是靠行政命令就能够解决的。

实例来讲吧,就说 Google,比如大家熟悉的 Chrome,版本更新也不慢,但是你看它的产品有很大改变吗?相信不少人读过《Google 测试之道》,知道他的发布过程是有着完善的分级灰度控制的。再强的团队也避免不了问题,但人家有足够的耐心去打磨。而且 Google 也没有把测试的事情拿掉,而是做了进一步分化,对工程和体验都有更强的专注力。

比较有意思的是微软,他可以说是测试行当的祖师爷,前几年也有模有样地宣称要去测试化。当然这里面也是有些逻辑的,Windows 的发布方式已经有很大变化,以前卖的是实体光盘,现在基本是数字化交付,所以 Windows 也玩起了灰度测试那一套。结果 Win10 的各种问题被骂出翔,矛头直指微软裁掉测试的传言,逼得微软辟谣还留着上百人的测试团队,可见 Google 模式也没那么好复制。

至于国内的情况不多说大伙也知道,产品研发的基本调性就是抓紧时机搞一波热钱,产品好不好不重要,能不能 IPO 才重要。 所以感觉多数老板都很焦虑,今天提的想法,明天就得落地。能不能带来效果不知道,这个想法不行明天就再换一个,总有一个是行的吧?产品特性换得比自己的衣服都快。

如果说人月神话的比喻是说:一个孕妇生孩子要十个月,两个孕妇就只要五个月。那么国内的普遍情况就是:一个孕妇生个孩子只给三个月,怎么实现管不着,反正就是一定要。老板不在乎什么软件工程、质量控制,只关心他的需求要等多久。想想为什么他们不懂什么是黑盒白盒,自动化这个词倒是记得很清楚。靠灰度慢慢做产品?不存在。只要能快点发布,堆测试才是最香的。

再说行业水平。某名厂也搞过去测试化,硬是给推行下去了。至于效果嘛,老板怎么看的不知道,底层群众问一圈就清楚了,反正后来不少团队又悄无声息地给招了回来(有的是测试转开发,披层外衣接着干)。如果一定要说没测试又怎么样?确实也没怎么样,能保证服务基本不挂,但是细节上就真的一言难尽。少数纯服务端的业务也许可以,前端交互很重的业务这么搞就是自掘坟墓。

这类隐患的爆发只是个时间问题,业务高速扩张的时候还能无视,等到了瓶颈期就发现已经积重难返。之前我在“第三代测试的思考”说过,现在是个存量竞争时代,国内消费者早就被教育得很挑剔,你的产品细节不行,被抛弃是很快的事,这点现在也已经得到证实。也许有读者要问,你说的体验也就是近两年(后疫情时代)的事,之前我们还在高速增长的时候,去测试化怎么就不行?你不也说没怎么样吗?

前面打过一点伏笔,去测试化是个底层逻辑问题,不是靠中心决策硬推就能行的。Google 的推行模式是由测试团队发起,一个个部门去沟通,让大家愿意相信你,愿意一起去努力,再经过漫长的实践和优化,才达到今天的程度。即便是我们都想改变,也不是立即就能变的。具体一点:产品和开发的质量理念要不要培训?符合新要求的测试要不要招聘?配套的基础设施要不要建设?

去测试化的内涵是思维升级,不是把人裁掉就完事了。前面提到的某名厂例子,上层的想法是我要学习先进,下层又理解不了你要的是什么先进,结果就是逼得开发去做原本测试做的事情,工作方式和内容并没有多少改变。表面看起来是完成了去测试,但总成本反而在增加,落地效果还不好。我们的行业水平还没成熟到可以支撑这种模式。更夸张的是,前面大厂都玩脱了,后面居然还有小厂跟风。

其实要论 BAT 三家公司,我最欣赏的还是阿里。从产品的调性上看,阿里还是比较“热爱技术”的,也实实在在做了很多科技改变生活的事情。但是阿里也不能免俗的一点是,对产品打磨缺乏足够耐心,一些有前景的产品没能等到它见证奇迹的那一天。阿里云刚搞的时候多少人反对?不坚持哪里会是今天的结果,祝福阿里将来能够走得更远吧。

然后说数字化基础。不知道是否有人注意过一个消息:21 年底印发的《“十四五”国家信息化规划》提到“十四五”时期要加快数字化发展,建设数字中国的新阶段。为什么要搞数字化?因为要提升效率,效率就是成本。照理说这是企业关心的事情,国家为什么亲自站台?因为要产业升级,提升国际竞争力。我们不可能永远做鞋子帽子,人民想要过上好日子,就得往产业上游走。

国内的数字化发展非常不均衡,意思就是大部分企业的办公方式还是靠手、靠吼,有个微信群就差不多了。比如在线协同办公,要说我们已经有钉钉、企微、飞书等这么多产品,为什么他们不用?因为潜意识里就不觉得这些东西有用。中小企业的眼睛普遍还是盯在怎么增加收入上,协同效率的提升能不能体现在财务报表里?不知道。所以协同软件有个怪现象是,很多客户卖得出去,就是用不起来。

上面说的这些和测试似乎没什么关系?当然有。前面说的协同软件能卖不能用的现象,代表很多企业对这方面其实还是有一定尝试欲望的,毕竟大环境和大趋势摆在这里。但是他们对数字化的理解又几乎是空白。这带来了什么后果?软件的前期交付、后期维护都极其痛苦,客户可不管你什么产品理念、技术架构,只要不能让他快速理解的,统统都是缺陷。

举个我实际遇到的例子,有位客户部署之后的几个月内一直很稳定,有天突然向我们反馈系统故障,排查了老半天发现是对方运维升级了网关,没给我们的产品域名开白名单。你再委屈也没用,客户一定要服务,这种情况下测试几乎是全程贴身重保。况且企业采购之前基本都要你出具各种测试报告,你要是跟客户说我们先进团队没有测试,客户会说不好意思我不要你的产品。

还有一个事实是,这类测试需求都偏低端,不同客户之间 80% 的测试内容是重复的,就是不停地回归。剩下的 20% 那可是金主爸爸的定制化需求,而且以大多数产品的架构现状,这些定制能改到连那 80% 的代码都变得不稳定,你还不敢不全量回归。我曾经问过一位 P10 前辈对测试职业是怎么看的,答曰:很多企业对软件问题的自主判断和解决能力是缺失的,所以测试的存在也就成为一种必然。

如果你以为今天我要表达的是:哪怕你只是个点工也不要担心,因为还有大把低端岗位等着你?当然不是。我们的数字化转型可不只是随便说说,而是以一定速度在推进,信息产业更是首当其冲。上面我列举的几个影响因素,尽管较为缓慢,也在持续淡化,具体对测试的影响会是什么?

不是说测试整个群体会消失,而是一个尾部淘汰的过程。上面画了一个示意图,虽然从业人员的能力分布一直会是个波形,然而这个波在持续往右推进,如果个体水平没有变化,就意味着生存空间会被不断挤占,直至消失在尾部。假设你现在在中位线,这个时间我估计大约是 10 年。其实也不绝对,因为总会有些变量出现,比如大家都关心的 ChatGPT。

这么说可能没有概念,我举个例子。有了电子计算器之后,算盘基本就没用了,但会计职业不会消失,失业的是学不会(或不想学)电子计算器的会计。而且这是有个过程的,不是说“啪”得一声尾部群体齐刷刷的原地失业。他们先去用不起电子计算器的地方,等这些地方也普及了,再去更边远的小镇或乡村。放在测试职业身上,这个淘汰链大概就是:大厂->中小厂->外包。也许不是很严谨,就是这么个意思。

上一段的例子也说明了另外一个问题:对单一细分技能的依赖是极其危险的。因为没法预料什么时候会突然出现一个取代这项技能的东西。我们可以看看运维行业,或多或少有我们未来的影子。前面说的某名厂,去测试化没搞明白,去运维化倒是很成功。原本的系统运维人员,有开发能力的发展成为 SRE,没有的要么转岗,要么淘汰。

和去测试化不同的是,去运维化的成果是实在的。开发人员依赖界面系统自己就可以完成全套运维工作,碰到实在不懂的,再去问 SRE。那你要问运维消失了吗?也没有。头部企业都在上云,中小厂还有不少传统运维(想想上面说的淘汰链)。为什么去测试化不能成功?因为要是软件工程能力不够成熟,测试大把的工作就得放在沟通上,或者这么讲,测试的工作包含更多的非确定性问题。相对运维来说,测试的运气真的很好。

至于 ChatGPT,目前就是个内容理解+生成的工具。打个比喻,有个专人在帮你搜 Google,搜得又快又全,还能自动整理输出,你说爽不爽?爽,但也就仅此而已。所以它会是个很厉害的提效工具,还远远取代不了现有的测试能力。稍微专业一点的测试,都不会把 Google 的答案直接拿来无脑使用,更多的是检索和参考。要是 ChatGPT 真的那么灵,StackOverflow 封它干吗。

这类“智能”的局限性在于非常依赖知识库的正确性,如果你在一些知名的开放资料库里编造少量虚假内容,搞不好哪天就会变成 ChatGPT 的“真理”(韩国人的福音?)。还有一点,真正高价值的内容都藏在企业的内部存储中,是不会给它去做训练的,这点可能会决定 ChatGPT 永远只能是个“二把刀”。

当然,在内容领域 ChatGPT 还是具备很强的危胁性的,不然 Google 就不会着急上火,仓促搞出来一个 Bard,首次亮相就翻车,市值端走上千亿。原来 Google 这个浓眉大眼的家伙也有搞倒排期的时候,最终也给我们证明了:不管你是多大的厂,不尊重科学规律,终究还是不行滴。

最后感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:

这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你! 

你可能感兴趣的:(软件测试,软件测试工程师,自动化测试,chatgpt,功能测试,软件测试,自动化测试,程序人生,职场和发展)