为何测试困在内卷陷阱里?

简介: 干货

本来老张约ckl和我做一次圆桌讨论,无奈疫情原因我参加不了,ckl和老张联合来了一场直播,对于直播的话题我们也想了下,相对于各类专项技术,不如聊一聊大家的现状以及可能突破的方向,关于测试为何困在内卷陷阱里,这个话题显然比较实际,事实上老张和ckl也聊的很充分,下面内容是一些核心总结点。


怎么卷:

  • 比谁测试执行做得多/case多,一个case拆成多条。
  • 比谁测的bug多,以及前端bug多还是后端bug多。
  • 线上的bug逃逸率。
  • 测试人员的平台开发能力。
  • 效能度量大PK。
  • 卷工时。


为什么陷入内卷陷阱:

  • 测试门槛低,进入的同学很多,存量市场下筛选门槛变高。
  • 行业的发展,包括技术和业务,很多测试同学并没有跟上,低维度的同学多了。
  • 企业利润降低,需要降本增效。
  • 能力与年纪不匹配,危机带来的求生欲。
  • 大蛋糕给基层是最少的,基层最卷。


面对内卷应该做

  • 测试门槛的提高是好事情,可以更多的筛选一部分人
  • 专注自己能力的提升,做大属于自己的蛋糕,自己的范围做精,辐射其他需求、研发环节,如产品实例化、产品验收,端到端拉通。
  • 技术领域菜是原罪,注意下班后的学习时间分配,比如提升代码和测试思维能力,能够有与产品和开发同频对话的能力,并且能够验证需求方案或者技术方案的合理性。
  • 如果你选择躺平,也要学会降低欲望。
  • 关注新行业、如芯片、人工智能之类等在三五年可能存在机遇和空间,但普通人很难连续换赛道。
  • 面向业务,稳住业务基本盘,深入理解业务,与产品、BA可以深入沟通,注重产出,通过你的测试方案设计,你的测试报告能够给团队质量保障的信心,最终技术的价值是通过业务交付来彰显的。


测试的发展方向:

  • 敏捷理念,需求实例化,story拆解,运维发布,项目管理各流程吸取经验。
  • 更多的测试前置(左移),单元测试,质量卡点。
  • 专项测试、平台等能够落地,细化到能够多维度度量。
  • 发现过程中的痛点并能够主导改进,如环境不稳定等,如自动化能力,去证明你对过程痛点的改进。


以上,两位大佬给出了现实的案例以及解决方案,从我个人而言,还有一个很重要的点是如何实践,也许大家能看到一些通往罗马的大道,但无奈的是很多人上不了路,说出了很多成长过程中朴素而又现实的痛点,比如


1.学习过程很枯燥,坚持不了。

学习是要有目的性的,很多人说还是为了升职加薪,这是每个人都希望看到的,但这是结果并不是内驱力,你需要细化阶段性的实现目的,比如我想做一个监控系统的报警,先去看看可以实现的技术能力有哪些,然后再去拆解学习目标,做到每一步骤的细化,通过目标去驱动过程,这样子肯定比你每次从字符串、列表开始学习,写最简单的demo来的有效得多,所以学习最重要的是找到阶段性价值目标。


2.我会写脚本但是领导不给机会。

在目前的存量市场下,靠公司给机会做专职自动化几乎不太可能了,在大厂里目前的自动化往往是业务测试人员靠相应的技术框架就自行完成了,至于一些小公司,没有时间可能也就不做自动化了,那为什么大厂可以做小厂会选择不做呢?这就是成本跟效率的问题,一般来说,小公司的业务测试同学框架驾驭能力还不成熟,可能会消耗大量的时间,所以基于这样的一个背景,你需要考虑的问题是你的自动化能力有没有到很成熟,而不是考虑谁给你机会的问题。当然也不是说专职自动化完全不存在,像基于UI或者接口类的专职自动化,目前银行外包还是存在的。


3.我技术能力很强,但还是很迷茫,不知道测试的核心竞争力到底是什么?

这是一部分高阶选手的困惑,能力比较好,但是总感觉自己没有核心竞争力,能解决公司的一些问题,但还是找不到核心价值的定位,论代码能力,又感觉很多开发可以代替自己,这些同学我认为技术够用了,但是对测试的认知有一些偏颇,如果你把单项能力去拆解,你会发现总有岗位能够替代开发,所以说测试真正的价值并不在于单项能力的pk而是体系化解决方案的输出,如果你在这个级别你应该能够深刻的理解质量内建,而质量内建是贯穿整个软件生命周期的,比如上述提到过的需求实例化,反讲,平台的落地、度量、复盘、改进等,你想一下整个流程的质量建设你有没有思考过?而这个流程是对测试执行,测试认知,测试技术的全面提升也是对沟通能力、协调能力、团队融合能力的考量。而这样一个角色对公司产研全流程的影响是巨大的,这样的护城河能力并不是其他角色能够轻易提到或者短期内能够替换的,这些是你需要真正思考的。


目录
相关文章
|
6月前
|
机器学习/深度学习 人工智能 测试技术
探索软件测试中的“禅”:寻找内在的平和与外在的效率####
在软件测试的世界里,我们常常被缺陷的数量、测试用例的覆盖度以及上线时间的紧迫性所困扰。但如果我们能像禅宗修行者一样,将注意力转向内心的平静与专注,或许能在纷繁复杂的测试工作中找到一种全新的效率和质量提升之道。本文将带您走进软件测试的“禅意世界”,探讨如何在看似枯燥无味的测试过程中,通过调整心态、优化方法,实现个人成长与项目成功的双赢。 ####
|
9月前
信不信?工作这么多年,还有很多网工不知道光模块光衰的正常范围?
信不信?工作这么多年,还有很多网工不知道光模块光衰的正常范围?
819 2
|
10月前
|
测试技术
ACL 2024:大模型性能掺水严重?北大交出答卷:交互评估+动态出题,死记硬背也没用
【7月更文挑战第8天】北大研究团队推出KIEval框架,针对大语言模型(LLMs)的性能评估进行创新。KIEval采用互动评估和动态出题,通过多轮基于知识的对话测试模型理解和应用能力,旨在减少数据污染影响,挑战死记硬背的评估。然而,该方法可能增加计算需求,且评估结果可能受主观因素影响,不适用于所有类型LLMs。[论文链接:](https://arxiv.org/abs/2402.15043)**
169 24
|
算法 搜索推荐 数据挖掘
掌握程序员之剑:解析常见算法与其在生活和工作中的影响
掌握程序员之剑:解析常见算法与其在生活和工作中的影响
148 1
|
算法 程序员 编译器
当程序遇上困难:程序调试的艺术(VS)
当程序遇上困难:程序调试的艺术(VS)
124 0
|
存储 编译器 Linux
C生万物 | 窥探数组设计的种种陷阱
数组在设计的时候为何会出现那么多纰漏?数组越界是如何导致的?,我们来一探究竟🔍
84 0
C生万物 | 窥探数组设计的种种陷阱
|
设计模式 人工智能 缓存
B站员工猝死,审核员之殇,谁该反省?谁该惭愧?技术层面解构内容安全审核系统(python3)
猝死,又见猝死,可怜无定河边骨,犹是春闺梦里人!每当有年轻的生命逝去,我们就会感到心中某种撕裂的感觉,惆怅万千,疼痛不已。审核专员,一个我们既熟悉又陌生的岗位,他们的疲惫,不仅仅体现在肉体上重复工作的折磨,而更多的,是精神上处于一种无知无觉的疲惫,想象一下,作为审核员,千帆阅尽之后,感动过你的一切不再感动你,吸引过你的一切不再吸引你,甚至激怒过你的一切都不再激怒你,麻木和怅惘充斥着你的工作和生活,只剩下疲于奔命,惨淡经营。而造成审核员审核过劳的因素之一,就是海量内容审核系统的设计问题。
B站员工猝死,审核员之殇,谁该反省?谁该惭愧?技术层面解构内容安全审核系统(python3)
|
SQL JavaScript 前端开发
#你会担心掌握的技术语言过时吗?#一入编程深似海,从此妹子是路人
我掌握的技术语言有C、C++、ActionScript、JavaScript、TypeScript、Flex、Java、SQL、Scala、CAD,当然,这还不算一些具有特殊语言的技术框架,如Vue.js、Angular、Spark、Android、HarmonyOS、Node.js等,如果算上就更多了。
288 0
|
智能硬件
周鸿祎:不符合人性的需求都是伪需求
  在移动互联网时代,产品的可选择性实在太大,各类网站琳琅满目,App(应用程序)层出不穷,任何一个用户都会在网络上不断地进行切换和刷新。   乱花渐欲迷人眼,用户到底凭什么选中你的产品,并为之买单?   谈到这个话题,我不得不提到人性。一个好的产品,往往能够反映人性中最本质的需求,换言之,不符合人性的需求都是伪需求。最本质的需求是人类原始的本能欲望,在《圣经》中,人类有七宗罪:淫欲(lust)、懒惰(sloth)、贪婪(greed)、饕餮(gluttony)、傲慢(pride)、暴怒(wrath)和妒忌(envy)。一款好的产品,需要对人性做透彻的分析,才能完成其设计。且让我们分而论之。
299 0