职业经验 测试开发之路—大厂工作四年的感悟

汇荔君 · 2021年12月04日 · 最后由 zql 回复于 2022年02月02日 · 3042 次阅读

开篇

当开始写这篇文章时候,才感受到人生如白驹过隙,4 年时间飞逝,自己也从一个初入职场小白到能肩负项目核心事务的测试开发。在这里,总结 4 年来的心智成长之路,也是借机互相交流,并无对错之争,欢迎有见解的讨论,共同进步。

经历

在两个大厂分别做了两年的测试开发工作,暂且成为 N 厂和 A 厂吧。负责过游戏自动化框架开发、专项测试工具开发、版本质量保障、Devops 平台开发,也带过小团队。每个厂,每份工作都力求突破,过程辛苦,自然结果都是很满意的,都拿到了不错的绩效。

测开的岗位定位

虽然在经历过的项目中,测开的定位大部分都是 “测试”,在 N 厂里面架构会比较特别,将测试开发与业务测试彻底分开。测试开发更多是做测试平台和效能提升相关工作,业务相对单纯,整个团队会一起面向功能测试痛点、研发痛点从质量检查角度出发做工具与平台,解决研发过程和测试过程的痛点。这份经历回想起来,还是很有意义,做事非常专一,技术也获得了不少成长。唯一不足的是,这些工具、平台也好,是否真正让业务产生了更实质上的提升,很难去精准量化,后期也做了很多量化工作的事情,建设量化的数据模型,所以切入 Devops 赛道,学习了很多 Devops 理念,造了一些轮子,当然一个人的精力是有限的,在一个成本中心里面,想去做 Devops 是很容易上手,但是做完善一整套 Devops 落地,几乎不可能的。

后来的工作,就开始跟业务了,能非常明显感觉到,业务带队水平的提升,沟通能力的提升,更多从一个质量保障的角度去做质量输入和输出,也算是亲身体会到了 QA 这个职业的 “不容易”,人在工位坐,锅从空中来,深有体会。

两段不同的经历碰撞,对测试开发这个岗位有了更纵深的思考,包括岗位价值、核心竞争力、行业发展有了一些思考。

测开核心价值

测开的定位既然也是测试,那么它的核心价值其实一句话可以总结:为质量买单,为产品保值,为过程降本。测开本质上归属于测试序列,哪怕再厉害的测试技术,测试平台,测试工具,不要被这些所谓的 “高大上” 的技术名词掩盖了真香,做这些自动化、平台工具最终都是为了更短的时间、更低的成本输出质量,然后(这里是重点)根据输出的质量去买单。这里说的直白一点,做的这些事情当然有意义,但是跳出本位思维,站在老板,站在项目经理的角色去看待,想要的只是质量结果和谁为这些结果买单。

总有人需要为结果买单,为过程买单,核心价值也就出来了,作为测试序列的一员,最重要的存在即为质量买单,也就催生出了,为什么测试要负责过程管理、左移右移,很少见到开发提到右移到测试,测试岗位的内容自然就杂而不精了,不是一个很合格的项目管理、却又要参与项目管理环节;不是一名单纯的技术,缺又要在业务测试中兼顾工具开发。甚至个别项目或者公司要求测试也要负责需求的质量把控,因此,在一个买单岗位他的存在大部分除了输出质量之外,本身不产生直接的商业价值,成为了一个背负成本的节能减排部门。也就是上面提到的为质量买单,为产品保值,为过程降本。

测开的职业瓶颈

在参与了很多项目之后,越来越能体会到,对话维度不同的平台,更能体现测试岗位的无力感,也是焦虑感。当你明白了核心价值后,那么谈发展时候,谈行业纵深时候,就会发现很现实的问题:

  1. 部分项目核心的前后端业务逻辑和代码是保密的,或者只开放冰山一角,很难真正全貌去做业务纵深,不利于个人的长线成长
  2. 测试序列作为一个成本保值部门,自然要肩负很多杂活脏活,零碎的时间和权限壁垒很难像做一款产品一样,去完整形成价值链,没有价值链谈什么个人价值呢
  3. 技术路线的测开会发现,纯测试开发技术大部分都服务于 QA 或者小部分人群,这些系统都未经标准化的开发管理,也没有外网的海量验证,技术的深度和广度在上游开发看来,不值一提

自我升级

跳出局限的打杂思维,去打破边界尝试做更专业的事。

如果善于沟通,利用测试已经具备的全局质量管理意识,可以往项目管理层面靠拢,去做一个真正的项目管理岗位,有质量思维做项目管理至少初级是超越了大部分非科班的项目管理了;

喜欢做技术,或者转做更上游的开发岗位或者具备领域门槛的研发岗位,专一纯粹去做技术思考和规划,把核心技术深入理解并向架构等方向纵深。
不要止步于下游赛道,虽然说每一个赛道有它的前景,但是也要知道,除了努力,也要看历史的进程。

最后还是想补充说道,四年来最大的感悟也不止工作上,在思考维度上更全局和本质去看待一个事物发展的规律,今天的测试赛道固然舒适,固然简单,但是这都是锦上添花,可是这些都很虚,业界大厂测试真正落地、沉淀了多少具备输出价值的东西,不得而知。不妨思考,测开岗位究竟带来了什么?这个赛道就行是为了什么而存在。

共收到 15 条回复 时间 点赞

写的不错。

质量的成本非常高。这一年互联网企业普遍效益下降,于是降本的需求就非常迫切,通常降本对应会带来减产,要高产又要低本(又要马儿跑,又要马儿不吃菜)就有了降本提效的课题,这本来就是个资源平衡的问题。

可以看到楼主的无奈,其实不止测试,研发也是如此的。职业有瓶颈,人可以没有瓶颈,就看怎么破局了。

恒温 回复

感谢你,很久不写文章了,平时被各种版本事情占用。降本提效无可厚非,但是历史总需要有选择,在一个没有核心价值,或者价值并不是很直接的职能,面对大环境有一些变化时候,天花板直接就出现了。说起来也奇妙,两段不同经历让我有机会完整感受到测开的工作内容和边界,跳出技术局限的思维,进行认知升级。

所以说,做测试死路一条

很有同感。测试做的越久,越无奈。
我司每当行业动荡或者结构调整,“开发优先” 是必然被提出来的。特别是疫情这两年,开发人数没怎么变,测试已经立省 50% 了

活着死路一条😂

技术路线的测开会发现,纯测试开发技术大部分都服务于 QA 或者小部分人群,这些系统都未经标准化的开发管理,也没有外网的海量验证,技术的深度和广度在上游开发看来,不值一提
喜欢做技术,或者转做更上游的开发岗位或者具备领域门槛的研发岗位,专一纯粹去做技术思考和规划,把核心技术深入理解并向架构等方向纵深。


个人觉得这个理解有点片面了,与运维开发不同的是,貌似因为测试的缘故导致多数人总会把测试开发当做自动化的业务测试去理解。当运维开发搞出来 devops,在从架构层面上去改变开发模式,甚至已经开始用云原生去革开发的命。测试开发不要再想着用一个 ssh+vue,写一个所谓的自动化测试框架就是测开的阶段了。
想想公司里测试基建真的有做起来吗?压测是不是还在用 jmeter,能不能做到全球多节点的分布式压测,能不能做到结合监控数据、结合代码分析,做到自动分析代码问题?
静态代码扫描是不是就还在用 sonar,就找人配了几个规则,搞个 ide 插件就完事了?程序分析作为 PL 领域比较火热的一个大领域,能不能做到工业界的落地?
集成测试是不是还停留在接口测试的阶段?复杂业务的全链路自动化测试,在链路上任何一个节点中断、切入这些都能做到吗?
还有混沌工程、流量录制回放、单测生成、用例生成、精准、程序修复……可以做的东西太多了,总结来说就是测试领域的基建还是太落后了。

eryi 回复

你说的这些我在大厂都经历过,有很多很炫的测试平台、测试思维,不可否认是不错的,的确有点效果的。但是这些真正能让业务价值凸显吗,这些混沌工程、全链路测试、单侧 AI 生成,这些维护和收益的成本与价值是怎么样呢,至少我看到的,效果与成本并不是正比,老板也不会 care 这些似乎很有意义的东西。

eryi 回复

你说的这些都有道理,但是我怀疑大部分公司落实不了,没资源也没有实力,真实现了这些,恐怕大部分人也失业了

现状和道理很多人都或多或少有感触,关键还是要如何去破局,转行转岗就不说了,就说说怎么在这条路坚持下去。
职业发展往上走,都是需要综合素质和影响力的,看似瓶颈,但实际上能做的还有很多。测开和开发、产品等岗位本质上都是一样的,运用自己的知识、经验,提供交付能力,只是侧重点略微不同而已。

说点实际的吧,我个人的话是预期在未来往两个方向努力:

  1. 个人能力,提升开发、产品体系、测试经验总结、沉淀
  2. 建立体系的能力,包括业务测试、自动化、效能

瓶颈归瓶颈,真正遇到瓶颈的人,哪怕晋升再难,实际过得也已经很不错了,慢慢沉淀呗,总是有各个方面需要提升的。另外真有其他打算,也可以换条赛道。

frankxii 回复

嗯,可以继续往下走,这点不能否认,只是说同样的付出,天花板就在那里,能做的空间其实就在那里,大厂讲的是成本和效率

看来 “从质量管理出发,慢慢构建项目管理意识” 想法的人不止我一个呀,刚好今年把 pmp 过了,也不是要转项目管理,给自己留一手可能性,顺带向上游扩展视野。
现在慢慢也会去咨询或闲聊上游的业务走向与需求规划。
如果自己能用最少的人天,保证最合适的质量产出(平衡点),就算是保值属性的打工人,老板应该是乐意用的。😃

jinglebell 回复

不错的思路啊,从质量管理去延展到项目的全阶段,懂业务懂技术懂流程懂管理的结合,可以找到新的机会。最关键的是,不再是下游的被动测试,而是逐步靠拢上游,提供核心决策,让上游感知决策的基础和能力。

13楼 已删除

校招生,准备去大厂做测开,是不是建议赶紧转开发了😭

zql 回复

如果你可以起步开发,直接开发岗位还是比较合适的

49875183 回复

为啥呀?可以说说原因吗

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册