记得大学从计算机毕业时,班里大部分的
男同学选择了"开发工程师岗"
女同学选择了"测试工程师岗"
极个别的“产品经理岗”
部分“非计算机行业岗”
转眼间,快10年了,大家各奔东西,各为其主数年。
在各自的互联网岗位上也基本都是中坚力量了。
我后毕业,就一直在做一线开发工作。
最近这半年,我觉察到,在 一线的互联网大圈里,产品研发的工程模式,已在悄悄的发生转变。
以前是这样的:
2012~2015年,移动端互联网井喷式的发展
客户端App每月一次发版,都需要几个测试工程师进行测试回归
梳理出TestCase,然后人工手动的“点点点”
把功能feature实际的全点一遍,看看好不好使。
新功能和老功能,都依赖这种“手动模式”的测试。
只有都“点点点”了,才能放心的发版。
梳理出P0级的重要checkList,进行测试回归
做的更好的,把checkList再进行拆分,让全员进行业务回归
最后把各自回归测试的结果,再统一反馈给“组织者”
组织者决定软件版本的质量,是否满足发版要求
后面发现当这个“组织者”非常耗时
又将这个owner角色, 让大家轮换着担当
就这样,让产品不断的进行版本迭代
但是在今天
在大型互联网公司中,这种原始的测试回归方式正在逐步消失。
传统的测试人员,正在被自动化、以及更完善的监控体系所逐步取代。
触发这个变化的原因主要有3点:
每次发布,都有逐步的灰度切流,新功能走灰度验证,不再“一把梭”。
有bug不怕,只要影响面足够小,做到快速验证
技术人员,面向业务数据(埋点)的BI开发能力,被跨栈赋能
业务的决策,越来越依赖数据说话,老产品经理也要给数据下跪
非UI交互相关的业务核心逻辑,在逐步的被单元测试所保障
各端的发布的稳定性,正在被更科学的工程手段改造着
同时,前几 年被吹很火的 ABTest,现在很少听到声音了
ABTest概念介绍:
一个已知确定的需求,需要用两种方案1和2,同时进行实现
然后再选取一伙目标人群,将这伙目标人群,无差别的一分为二成A\B两组
对A组实施方案1,对B组实施方案2
然后再通过数据监控,去判断A组和B组的业务效果。
这种思路,看着比较逻辑正确,但是在实践中并不好落地
因为没哪个产品经理敢让一个需求,既要方案1实现,又要同时方案2实现
这意味着2倍的研发资源的投入,以及更高的复杂度实现
即使技术老板不怼他(都没想清楚,就过来要研发资源了),程序员也会砍死这个产品经理的
所以大部分执行较好的场景是
线上业务有1条全量的主干功能roadmap
然后在各个具体的分支上,产品经理提出一个“尝试性”的功能feature
然后让研发人员去实现,并在这个新功能给加上完整的链路埋点
上线后业务开关默认关闭,然后通过预先实现好的流量开关,慢慢放量
一边放量一边配合埋点进行数据佐证
这其实是一种更接地气的 “A/B test方案”变种
核心是 细灰度 + 强监控 逻辑
逐级灰度 + 强监控 + 数据大盘
这3个组合拳,应该是未来要 废掉“传统测试人员”的主要推动者
这既是工程技术的进步,也是互联网及软件工程发展到今日,一个必然的趋势。
图片取自阿里云 dataworks 简介
为什么互联网裁员的时候
往往先裁中年摸鱼的管理层,然后再裁代码能力弱的测试人员
本质裁掉的,都是使用落后生产方式的生产力提供者。
只有裁掉了这些人,才能进一步提高整体的生产方式的效率
进而提高-生产力
最终创造-竞争力
高度市场化的社会,大家在享受社会进步的同时
其实是生产力与生产关系的一茬又一茬的“再升级”
各行各业的职场不断“再进化再洗牌”,招人、裁人
最终推动了社会不断向前发展。
更多相关知识点击如下链接进行获取:
https://edu.csdn.net/lecturer/6110
https://edu.csdn.net/course/detail/32107
https://edu.csdn.net/course/detail/32047
https://edu.csdn.net/course/detail/31981
https://edu.csdn.net/course/detail/31967
https://edu.csdn.net/course/detail/31941