测试之殇

简介: 测试之殇

最近测试的日子不是很太平。

先是隔壁事业测试砍了半,而后我量大部门也被打散。说原地业吧,至少感觉手里的碗由铁变泥了,大伙都得小心翼翼地端着,摔不得。

好几个测试朋友问我这里还有没有坑,我说别提新坑了,现在最大的责任就是把老坑里的萝卜护好,别给人家拔了去。

早前疫情刚结束的时候,我推测测试的境况可能会不太好(第三代测试的思考)。结果何止是不太好,简直就是糟透了。

我倒不觉得是测试职业的问题,只是又到了重新洗牌的关头上而已

如果时间再倒回十年前,我是肯定不会有任何危机感的。那时候只要熟悉一门语言,懂点 Linux,会个 SQL,再搞搞自动化或性能,差不多在中小公司就可以横着走。

现在呢,会编程已经是测试的标配,别说什么端到端自动化了,新一代小朋友已经开始卷算法。我想问问老一辈的资深测试们,智能化测试大伙跟上了没?

刚开始做公众号那会,我也会在文章里讲:别太把自己当测试了,主动站出来,多担点责任,对自己会有好处的。

然后有读者给我留言:啊呸,就是你们这种工贼,才让测试越来越难做。想想也对,大家都本本份份做点工,不就没那么多事了?非常有道理。

于是我特意请教了一些朋友,他们说你这不行啊,得站在读者的角度上写,比如“达成年薪百万的方法”、“大厂面试必过技巧”、“如何让测试有地位”。

我说这给我整不会了,方法确实有,就是文里讲的那些,那可是工贼的做派

朋友们也很耐心,又教我新的方法:那你就别讲道理了,讲自己的故事。这个我觉得行,讲故事就讲故事吧。

回到前面说的,我就是那个会点编程,在公司里横着走的家伙。我做执行岗会,绩效就没离开过第一档,最后搞得都不好意思了,跟主管讲要不换换人吧,反正耽误加薪就行。

很多人在问,测试没有话语权怎么办?这很正常啊,因为那会我遇到的情况也一样,开发的口头禅就是你们测试懂个什么?你还不好反驳,早年的情况确实就是如此。

后来有个测试同事碰到一个缺陷,开发死活不承认,说他本地正常得很,一定是测试环境的问题。所以我也被迫进去 Debug,发现原因是文件名大小写错误。

这位开发也是个耿直人,事后跟我们道了歉,还说是我们让他对测试岗位有了改观。这句话着实让我触动不少:对啊,即然已经干了测试,不得为这个职业正名么?

类似的情况又发生了几次,以至于后来只要出现开发不配合的场面,测试就会说:那我叫 XX 过来看了啊。效果好得很,让测试来给自己定位缺陷,开发不要面子的吗。

所以只要问我测试地位问题的,我都回答地位就是打出来的

可以理解有些同学的想法是:我就想安心当个测试不行吗?我也不要求高工资,只要给我一般的薪水就行。

其实从感情上说,我非常认同这种观点。人生嘛,自己觉得有意义最重要不能说谁对谁错,但是环境不一定允许啊。为什么?继续讲故事吧。

前面不是说,我做执行岗的时候,绩效都在第一档吗?很自然的,我工作第四年就做了主管,到现在为止差不多十年的管理经历,我想这方面还是可以说两句的。

执行转为管理的一个重要变化,就是看问题的视角不一样

今天大家在吐槽的各种问题,像是压测试时间、测试缺资源、出问题背锅,年轻的时候我骂得比你们都厉害,和主管拍桌子也不是一回两回。

之前有个挺热心的读者,以为我是项目经理,加了微信跟我讲了很多测试的难处,把我给看乐了。我说哥们我也是测试,但正因为我是测试,所以更要讲讲现实。

什么现实?就拿倒排期来说吧,我做执行的时候,也会跟主管抱怨这个多少用例,那个多少缺陷,怎么怎么不行。主管也是测试,他听得懂啊,反正他负责搞定。

做了主管以后,再这么跟老板汇报,他听得懂吗?听不懂,他也不在乎。要么是销售跟客户打了包票,要么是尾款就差这么个需求,不上就是几十万损失,你看着办吧。

你要说主管不就是要为员工争取权益么?很对,以前我也这么想,一身正义感,跟老板当面争。结果呢?一样的绩效,团队年终少一大截,这个权益是大家想要的吗?

后来就知道了,管理最大的作用在于变通,而不是去争论所谓的立场

比如老板说我们缺个自动化平台,给你一周时间搞一下吧。我不能直接跟他说我做不到,时间不够。老板只会想,原来你这么不专业,得找个机会换人。

那怎么办?拿个开源平台,账号对接一下,再换个 LOGO 呗,至少我就是这么干的。也许你会说就这样?对啊是很简单,但多数人就是做不到,遇到这种情况第一反应就是说不行。

我们大部分时候要把老板当个客户看,客户的特点就是自己也不一定知道他想要什么,所以我们才要以专业角色的身份去告诉他,你要的其实是这个。

这不挺好的么,既维护了团队的利益,又满足了老板的要求。让团队好好活着才是最大的体面,不是一定要通过争辩的方式来证明什么。

为什么测试不受重视?因为纯测试的观点很多时候和老板们的愿望是违背的。比如我说测试的作用是保证质量,老板会说那怎么线上还有问题?根本就无解。

在老板看来,他不明白为什么测过的东西还有问题,他不明白为什么测试老是影响发版,他只会觉得测试没什么用。所以测试资源是最难补的,也是裁员最考虑的。

如果说上次变革解决了测试的定位问题,那这次变革就是为了解决测试的生存问题。

什么是定位?测试在以前只是一道工序,产品、开发、运维任何一方不给力,最后都能把锅甩到测试身上,所以我们要搞左移右移,定位从测试变成了质量。

现今测试在老板看来还是个成本部门,为了生存下去,当然要想着怎么把测试变成一个产出部门,这就是为什么说别太把自己当测试了。

前面提到要是再早十年,会代码的测试没多少,但现在是个什么情况,大家也能感受得到。那么再过十年呢,有没有想过会是什么样?

有人说不给测试更高的工资,凭什么要求测试这么多?太对了。一个数据,今年校招字节、阿里这些公司,测试 offer 基本在 22 ~ 30K 之间,这可是应届生的水平,你说代表什么?

好的,不讲道理,就讲故事。

上周我刚汇报了质量团队在产品上的一个创新项目,老板说你们这个想在了前面,本来我打算把开发和测试并到一块,你们自己有想法,我还是挺支持的。

事后我只觉得冷汗直流,如果我们没有这么主动呢,会是个什么结果?质量团队可能就不在了,能转开发的就转,不能转开发就走,没什么地方让我讲道理。

而且现在也不一定安全,只是看到了一丝曙光而已,未来会怎么样还得努力。但是我很确定,我们下一步必须要往业务上靠,不然就是走前一波人的老路。

我们质量团队从创立至今,也经历了很多波折,现今是仅存的一个完整延续下来的部门。所以说实在的,就冲着这份不易,我也不能选择躺平,只能继续战斗下去。

故事就是这么个故事,情况就是这么个情况。我不想说奋斗了,自媒体怎么可以讲这么 PUA 的事情?反正大伙就当个故事听,也许这些都是瞎编的。

测试还是测试,挺好的别担心,真的。

相关文章
|
2月前
|
敏捷开发 测试技术 UED
探索性测试:软件质量保障的无形之手
【5月更文挑战第31天】本文深入探讨了探索性测试(Exploratory Testing)在现代软件开发中的重要性。通过分析其定义、实施策略和优势,揭示了探索性测试如何成为提高软件质量和用户体验的关键手段。文章不仅为读者提供了对探索性测试的全面理解,还强调了其在敏捷开发环境中的实践价值。
|
2月前
|
监控 测试技术 开发者
测试八年|对业务测试人员的一些思考
本文分享了作者测试八年间对工作的一些思考,希望为业务测试同学提供一些有价值的思路。
|
2月前
|
机器学习/深度学习 自然语言处理 Devops
探索软件测试自动化的新思路
在当今快节奏的软件开发领域,传统的软件测试方法已经无法满足快速迭代和高质量交付的需求。本文将探讨如何借助最新的技术手段和方法,为软件测试自动化注入新的活力,提高测试效率和质量。
|
测试技术
语音聊天系统,细数开发中常见的测试方法
语音聊天系统,细数开发中常见的测试方法
|
前端开发 JavaScript 算法
【测试开花】动动手的测试平台来了!
【测试开花】动动手的测试平台来了!
|
测试技术 BI 项目管理
开发和测试的囚徒困境
探讨开发与测试之间困境相关内容
|
监控 测试技术
六年测试之精华分享:产品质量应从哪些方面提高
今天就说说近期大家比较关心的话题,根据自己多年的测试经验,对于一个企业能否很好的生存下去,有四个核心指标,产品质量Q、服务质量S、产品价格P、响应时间T,在我看来,属于技术范畴的2个最核心的指标是:一是产品质量、二是响应时间,怎样更好的保障产品质量,为一线的销售保驾护航好产品,就显得尤为重要...
1380 0
|
测试技术
需求、开发和测试的“三足鼎立”
需求、开发和测试虽然各自做着不同的事情,所关注的点不一样,有时还有可能会出现意见不统一,但大家都有一个共同的目标:将产品做好。也正是这个共同的目标让需求、开发和测试之间的合作大于对抗、理解大于分歧,也正是这个共同的目标让软件产品这个“鼎”的三只“脚”永远平稳和牢固。
3633 0