测试人员正在逐步被自动化取代

图片取自lifeofpix

记得大学从计算机毕业时，班里大部分的

• 男同学选择了"开发工程师岗"
• 女同学选择了"测试工程师岗"
• 极个别的“产品经理岗”
• 部分“非计算机行业岗”

转眼间，快10年了，大家各奔东西，各为其主数年。

在各自的互联网岗位上也基本都是中坚力量了。

我后毕业，就一直在做一线开发工作。

最近这半年，我觉察到，在一线的互联网大圈里，产品研发的工程模式，已在悄悄的发生转变。

以前是这样的：

• 2012~2015年，移动端互联网井喷式的发展
• 客户端App每月一次发版，都需要几个测试工程师进行测试回归
• 梳理出TestCase，然后人工手动的“点点点”
• 把功能feature实际的全点一遍，看看好不好使。
• 新功能和老功能，都依赖这种“手动模式”的测试。
• 只有都“点点点”了，才能放心的发版。
• 梳理出P0级的重要checkList，进行测试回归
• 做的更好的，把checkList再进行拆分，让全员进行业务回归
• 最后把各自回归测试的结果，再统一反馈给“组织者”
• 组织者决定软件版本的质量，是否满足发版要求
• 后面发现当这个“组织者”非常耗时
• 又将这个owner角色，让大家轮换着担当
• 就这样，让产品不断的进行版本迭代

但是在今天

• 在大型互联网公司中，这种原始的测试回归方式正在逐步消失。

传统的测试人员，正在被自动化、以及更完善的监控体系所逐步取代。

触发这个变化的原因主要有3点：

1. 每次发布，都有逐步的灰度切流，新功能走灰度验证，不再“一把梭”。
   1. 有bug不怕，只要影响面足够小，做到快速验证
2. 技术人员，面向业务数据（埋点）的BI开发能力，被跨栈赋能
   1. 业务的决策，越来越依赖数据说话，老产品经理也要给数据下跪
3. 非UI交互相关的业务核心逻辑，在逐步的被单元测试所保障
   1. 各端的发布的稳定性，正在被更科学的工程手段改造着

同时，前几年被吹很火的ABTest，现在很少听到声音了

ABTest概念介绍：

• 一个已知确定的需求，需要用两种方案1和2，同时进行实现
• 然后再选取一伙目标人群，将这伙目标人群，无差别的一分为二成A\B两组
• 对A组实施方案1，对B组实施方案2
• 然后再通过数据监控，去判断A组和B组的业务效果。

这种思路，看着比较逻辑正确，但是在实践中并不好落地

• 因为没哪个产品经理敢让一个需求，既要方案1实现，又要同时方案2实现
• 这意味着2倍的研发资源的投入，以及更高的复杂度实现
• 即使技术老板不怼他（都没想清楚，就过来要研发资源了），程序员也会砍死这个产品经理的

所以大部分执行较好的场景是

• 线上业务有1条全量的主干功能roadmap
• 然后在各个具体的分支上，产品经理提出一个“尝试性”的功能feature
• 然后让研发人员去实现，并在这个新功能给加上完整的链路埋点
• 上线后业务开关默认关闭，然后通过预先实现好的流量开关，慢慢放量
• 一边放量一边配合埋点进行数据佐证

这其实是一种更接地气的 “A/B test方案”变种

• 核心是 细灰度 + 强监控 逻辑

逐级灰度 + 强监控 + 数据大盘

• 这3个组合拳，应该是未来要 废掉“传统测试人员”的主要推动者
• 这既是工程技术的进步，也是互联网及软件工程发展到今日，一个必然的趋势。

图片取自阿里云 dataworks 简介

为什么互联网裁员的时候

• 往往先裁中年摸鱼的管理层，然后再裁代码能力弱的测试人员
• 本质裁掉的，都是使用落后生产方式的生产力提供者。
• 只有裁掉了这些人，才能进一步提高整体的生产方式的效率
• 进而提高-生产力
• 最终创造-竞争力

高度市场化的社会，大家在享受社会进步的同时

• 其实是生产力与生产关系的一茬又一茬的“再升级”
• 各行各业的职场不断“再进化再洗牌”，招人、裁人
• 最终推动了社会不断向前发展。

作为一个IT家庭：

• Beta的爸爸是开发，Beta的妈妈是测试
  • Beta的命名也是富含软件工程的哲学
  • 爸爸目前在努力学习数据开发相关的技术
  • 妈妈这边等Beta稍微大一点的时候，也要重新去工作

经过本周的分析，得出如下结论：

• 测试工程师小伙伴们
  • 没有一点代码能力，也是越来越不好混
  • 唯有“自动化测试”能力才是你简历上的加分项，妈妈要加油鸭~
• 开发工程师小伙伴们
  • 是时候去锻炼你数据ETL能力了
  • “埋点+基于分布式数据库写SQL+可视化报表”，爸爸要加油鸭~

-End-