从事测试工作 7 年了,最近是越来越看不懂测试圈了,我想问我是不是走进了测试误区
大学刚毕业的时候做的是嵌入式产品的手工测试,客户是日本人,那个时候的工作几乎是都是分析需求,设计用例,Review 用例,测试执行,bug 反馈之类的工作,没有什么技术含量,但是培养的是测试思维,我想这可能是当时测试人员最重要的素质了,虽然说穷尽的测试是不可能的,但是 Case 的覆盖率真的是很高,想的到的,想不到。后来逐渐开始带团队,主要的工作重心放在提供完整的测试解决方案,测试计划,风险评估,测试流程管理等等,那个时候用的还是瀑布式开发模式,留给测试的时间和空间也足可以让测试人员自己对测试产品有足够的信心,那个时候我以为测试可能会一直这样下去。
后来,互联网时代的到来,测试人员开始学习一些新的技术,想尽办法减省人力,提高效率,开发模式也发生了变化,迭代,敏捷成了各大公司最求效益的最好方法,因为升级迭代的成本不像嵌入式产品那么大,所以流程和风险都可以通过下一个迭代来弥补,这样的方式流程测试人员的时间是有限的,甚至是被压缩的,对于做了这么久的瀑布模式的我,不走完所有的流程对产品质量就没有信心,所以每次版本发布都是惴惴不安的,后来我也还是接受了现状,根据产品的上线时间点,用户场景,issue 的等级来有条件的放宽上线标准,至此,测试失去了主动权,更多的是产品作为主导,只要是产品经理说可以上线的就可以上线了,也不是我放弃了测试的信念,只是审时度势,现实确实这样的,大家都在抢占先机的时间段,有些事情是要分轻重缓急的。可是,当出现上线的问题的时候往往大家第一句是测试是怎么测的呢,这个锅测试背不起呀,于是接下我的工作就是和开发斗智斗勇,和产品经理划分责任,和老板反馈现状,对于测试工作,我只能是做到我能做的,根本不敢说多产品质量负责。
终于我决定跳出现状,不想要继续做管理,打算静心研究技术,只是技术的水太深,我学了 python,学了各种自动化框架,可以写写脚本,利用工具做做性能,压力,分析分析瓶颈,应该可以是可以做一个自动化测试工程师了,于是我决定出去面试,但是发现面试官需要我有测试框架的能力,由于我对接下的工作有自己的想法,宁缺毋滥,不想先找一个随便做做,于是我开始学习自己搭建自动化测试框架,搭建了 2 套,在项目用了一下,我觉得还可以,能够满足使用的需求了,于是我又面试了,后来我发现公司希望的不仅仅是框架,他们希望的是测试人员能做出一整套的测试工具,我曾经问面试官,有一些开源的工具完全可以拿来用呀,面试官的回答是开源的工具不能和公司很 match,希望自己公司的产品能做到不懂代码的人员也可用,那么我就有个疑问了,工具是给不懂代码的人员用的,那为什么各大公司在招聘的时候要要求会代码,能写脚本,甚至是要会开发呢,于是我开始学习前端,后端技术,希望自己能开发个简单的工具(没有学明白目前)。
多次的面试还发现,有的公司希望测试来管理流程,通过测试规范开发流程,常常还被问道如果发现 bug 的时候开发不肯改,你该怎么处理,这样的问题其实我知道该怎么回答,我也知道问这种问题的公司大多是因为开发很难搞,测试很被动,但是我真的不想回答,如果只是测试去迎合开发,开发自己本身对自己的产品没有要求,那还沟通个毛线,公司为什么能容忍这样的开发,可能这样的公司是少数,或者是不规范的公司,但是我想说的是在大家的思维中,测试的地位大致都是比较低的吧。我知道的一个真实状况,一家金融公司的测试总监,测试技术不用说了,开发能力也很强,喜欢研究前沿的技术,也喜欢分享,经常开会给开发和测试人员分享技术,可是开发的想法却是一个测试跟我们谈技术。。。
最近我经常想测试的本质是什么?难道是开发各种测试工具进行测试,还是只是尽量减少手工,高效的测试,现在除了通过工具分析下测试覆盖率,真正的 Case Review 大家都是怎么做的,有几轮的 Review,那些场景性的测试怎么覆盖的,探索性的测试是怎么做的。没有详细的需求文档,测试人员是怎么进行需求分析的,产品的逻辑是通过什么方式理解的,我在想我一味的追究前沿的测试技术,到底是在学习怎么进行开发还是怎么进行测试。
我想我可能最近是有些浮躁了,就这样的发发牢骚,希望大牛们能帮我理清下思路,当然我不负能量爆棚的人,我希望和我一样迷茫的人能明白,如果现在看不透,那就不用努力看透,低头做好现在正在做的,也许会在猛抬头的一瞬间就看透了,事情总是在发展的,光有焦虑是不行的,静下心来,沉淀自己,就算是一事无成,也会有很多一事无成的人陪着您的。
后来我发现公司希望的不仅仅是框架,他们希望的是测试人员能做出一整套的测试工具,我曾经问面试官,有一些开源的工具完全可以拿来用呀,面试官的回答是开源的工具不能和公司很match,希望自己公司的产品能做到不懂代码的人员也可用,那么我就有个疑问了,工具是给不懂代码的人员用的,那为什么各大公司在招聘的时候要要求会代码,能写脚本,甚至是要会开发呢,
非大牛回答,如答述表意有误,敬请谅解。做东西跟用东西,还是有区别的,“做” 要明白怎么做符合需求,“用” 不在乎内部构成只保证所见即所得(降低使用成本?)。设若,一款工具都复杂到只有作者自己能明白怎么用,怎么推广给其他人使用呢。工具作为辅助手段的存在,臆测为提高工作效率、适当降低人力投入成本。手工测试,更多源于对需求本身的分析(无论是否所谓的 “文档”)、经验、风险预见与分析?自动化测试接触较少,故不作任何表意。 话说,不喜勿喷啊
一字不拉的看完了,和楼主一模一样的状态;为了不让自己处于迷茫的状态,目前我是按照这样的标准执行的:
1、工作中:对内总结梳理团队中不足的地方,规范和提高测试组项目中各环节的流程和输入输出规范,提高测试效率;对外不断宣传和同步质量意识(不是每个人有全员质量意识的概念的),这部分是循序渐进的过程;
2、生活中:给自己报了个测试开发技能学习班,拓展不一样的测试技能和视野,除此之外,把更多的心思用在小孩的教育和陪伴上,固定时间和自己的家人联系和慰问。
总而言之,不要胡思乱想,不要让负面和颓废的情绪影响到自己,人无完人,接受不完美的自己,对于工作和生活,都应该同等的对待,我不愿意把所有的精力都给了工作,我爱工作,但更爱自己的家庭
明白的你的意思,工具确实是要做的尽量简单化,这没有毛病,也理解自动化和手工要相辅相成,但目前的实际情况不是这样的,更多的重心是在自动化测试,可能我是测试出身,我在测试的时候往往关注的不是这个工具有多好用,我更关注我的 Case 覆盖率是什么样的,有没有用户场景没有想到的,产品的逻辑存在什么缺陷。
如果非要走技术、自动化测试技术这条路,现阶段,一定要记得:CI/CD、DevOps,孤立的自动化测试就是屎,毫无价值
不能从全流程提升研发效率、不能有重心的提高产品质量或发布效率,自动化测试做的再好,也只是自嗨,无法赢得开发、产品的尊重和信任
你是环保部的;税收不是你创造的
同样的技术不适用于所有的公司,同理质量管理规范也是一样。测试只是质量保证的一个环节、一个手段。五楼说的很对啊,不从全流程提升质量,对一个团队产出质量来说很难有大的提升(所以,了解下内建质量?)。另外,是否有话语权这个关键看质量团队 leader,这玩意儿是在不断的斗争中争取来的。想推行规范,就要做好长期斗争、不停改良、不断尝试、顶住压力的准备。。。
另外,各种五花八门的测试技术只是提高产品质量的手段,不要走火入魔
莫名恐慌,跟老大沟通了下打算转开发了
楼主开篇也提到了在进入互联网前后经历的瀑布式和敏捷式的开发模式。 我也是工作了 7 年半的人了,经历过楼主描述的过程。 先讲述一段关于小故事吧。 小步快跑,试错迭代的思想在上个世纪漫威的崛起中就已经有成熟的应用了 (我是漫威迷 ),斯坦李可不是一口气直接创造了漫威宇宙。而是在一开始尝试性的创建了有性格缺陷的神奇四侠。在斯坦李的笔下,石头人敏感易怒、霹雳火轻佻自负……超级英雄终于不再是高高在上的神话故事,而是一群有血有肉的普通人。(不同于 DC 的超人蝙蝠侠神奇女侠,他们几乎是完美的) 这种设定迅速激起了年轻人的共鸣,《神奇四侠》大受欢迎,拯救了处于垂死边缘的漫威。随后,斯坦李用这种更加贴近人性的配方,开始用流水线大规模地生产超级英雄。斯坦李一个超级英雄一个超级英雄的试错,一点点找到大众更喜欢的角色。 然后 1940 年的一期漫画,海王和霹雳火在漫画 pk 了起来,漫威的超级英雄第一次有了交集,之后是美队和霹雳火和那摩等集结打纳粹。再然后漫威宇宙一发不可收拾,原著中的内战涉及的超级英雄之多令人咂舌。漫威宇宙 2000 多位超级英雄就是这么被创造出来的。 跟大家说漫威的故事就是想说明这个模式。这种小步快跑,试错迭代的思想被充分的利用在了互联网里。 因为它能更快,更有效率的找到用户更需要什么,如果漫威一开始就设计一个恢弘庞大的漫威宇宙,那它当初早就被 DC 干死了。 尤其是在互联网中竞争对手无处不在,抢时间抢用户抢地盘。慢一步,步步慢。 当初阿里云诞生之初把评估的工作排期直接压缩了 2 倍,誓师大会上所有人喝酒宣誓,3 月前必须上线。 所有杭州团队的人直接飞北京,光差旅费就花了百万以上,没需求文档没设计文档什么都没有,沟通全靠吼。就是要快,当初的目的就是赶在腾讯云之前上线。如果慢了,很可能就没有现在阿里云的传奇了。 所以在这种商业背景下,传统软件的研发模式必然是淘汰的结局。 这是互联网对传统研发模式的打击。 同时互联网对传统软件公司也造成了一种降维打击。即便是我们这种 TO B 业务的公司,也或多或少的走这种模式。因为你慢了,你就死了。
所以在这种背景下,像以前一样那么长周期的测试活动肯定是不会存在的了。TO B 企业还好一些,互联网就完全是快节奏。 所以才需要大量的自动化来缩短测试周期,也许这时候的测试是不完全的,但这时候的测试是能满足用户需要的。测试人员需要转换一种思维,就是我们的目的是做一个能满足用户需求的产品,而不是一个完美的产品。 经常能看到一些开发吐槽,比如都什么时候了还在这跟我提这些无关痛痒的 bug。这就是测试人员还活在自己世界中的表现,也是没有产品意识的表现。 一个成功的技术团队 (包括产品,研发,测试,设计等) 要有一个共同的目的,在这个共同的目标下,所有人都要互相妥协。 最后的产出,就是各方为了这个目的互相妥协出来的。 所以像以前那样,质量部门产品部门研发部门互相独立的团队很难存活下去。 现在已不是单打独斗的时代。 相比测试思维,我们更加需要团队思维,整体思维和产品思维。
根据之前说的,测试人员要跳出纯测试的框框来,从整个团队考虑。 测试人员介入流程规范,约束开发这个事其实没毛病。 有能力就可以做。 我的测试 manager 现在兼职管着 PMO 的事,管着 TS(技术支持) 的团队。而我现在是 CICD 的 owner,老大了我一帮子比我技术好的研发人员做为我的资源让我搞。 产品上,所有关于 k8s 的需求和设计由我组织,甚至好多需求是我本人提的。 运维上,一些 k8s 和 hadoop 集群也是我和我同事在维护。 你看我们的工作涉及到了多少非测试的事? 不止是 QA,我们的研发多少跨界客串一把产品人员的, 客串一把交付人员的。 我觉得一个好的团队是不会给团队划分固定角色的,谁有能力做,谁有时间做,谁愿意去做,那谁就可以去做。 每个人都有自己擅长的领域。 那在自己擅长的领域里跨一把界,是对团队有好处的。 比如我们这种技术架构这么复杂的产品, 有些模块,让研发人员去做产品的角色就是比产品人员自己搞来的高效,正确。
关于线上出问题了以后让 QA 背锅,这个是要分情况的,要 case by case 的分析,但这种无脑背锅的事倒是存在的,一个不成熟的团队会有这种不成熟的思维。 质量是所有人的,不是 QA 的,有时候该怼就怼。 做 QA 要是还怕得罪人,还玩个蛋了。
这个楼主去面试的时候是碰到不太好的团队了。 做到不懂代码的人员也可用的这种思维是无奈之举,一定是团队中不会写代码的人太多了。 没办法而为之的。 但基本上这种关键字驱动框架我就没见过有人做好的。 最后规模大了都是维护噩梦。 只能测测业务层,而且是小规模的。 case 多了能累死人。 一个测试人员追求技术是没毛病的。
至于开发人员吐槽你一个测试跟我们聊什么技术。 那还是因为测试的技术没有给他们带来价值,不信你来我们公司看看,会有人吐槽测试的技术么? 技术不在于有多高明,而是它能为你带来多少价值。 当你的技术能力,产品能力,团队能力达到了一个点的时候,就会呈现出爆发的姿态。
我一直建议测试人员跳出测试活动这个小框框来,往整体上看,往产品上看,往团队上看。 思维跳出来以后就会发现,你可以为了产品质量做很多很多事。 不要为自己设限。
发现你真的很善于总结,由于激动我的内容写毫无重点,你竟然剥丝抽茧的将我的所有疑问都解答了,谢谢你的分享,我想要的答案你都给我了,复制下来,没事的时候看看,和开发吵架了就读一遍,和产品有争议了就读一遍,背黑锅了也读一遍,我们的目的是做一个能满足用户需求的产品,而不是一个完美的产品
“一家金融公司的测试总监,测试技术不用说了,开发能力也很强,喜欢研究前沿的技术,也喜欢分享,经常开会给开发和测试人员分享技术,可是开发的想法却是一个测试跟我们谈技术。。。”
如果你可以做到开发经理,你也会这么想。。。
我走的技术路线是这样的:手工测试-》图形界面自动化-〉接口自动化-》云平台持续集成-〉测试工具开发-》云 +devops+ 测试架构。
现在工作 9 年半,下一步我的方向是是云 +devops+ python 开发/架构。测试的核心是测试效率。你想一下你的职业生涯变迁,正体现了效率的逐渐提升。效率的提升有两方面,一个是测试技术化越来越强,像你说的做工具。另一个是测试人员比例越来越低,开发自测将是未来趋势。而测试人员未来还会活跃在在性能、安全等特殊领域上。对技术路线有兴趣的朋友可以看看我的专栏:https://zhuanlan.zhihu.com/testup
希望真正想做测试技术的人可以坚持好好做好技术,改变一些行业里浮躁的现状。
作为测试人员,当你迷茫的时候有个很简单的办法:想想客户要什么。
客户对我们产品的期望,对产品质量的期望,是我们作为测试做重要的出发点,也是我们应有的坚持。
我想楼主对测试工作认识有误区吧,任何工作是要解决实际问题的,我认为楼主不屑的工作,才是高难度的工作
我确实是有误区呀,标题已经写了,不过我字里行间有体现出对什么工作不屑吗?我只是短时间的迷茫了,和大家探讨一下,希望走过来的小伙伴能给我点建议。
发一篇老鸡汤。常读常新。
https://www.cnblogs.com/skytraveler/p/3546703.html
btw,感觉有一句话特别重要:不要给自己设限,一切以解决问题出发。
长此以往,你就会做得很好,是不是 QA,无所谓了。
我觉得首先是搞清对测试的定位吧,测试不同于业务和产品,他们的目标是希望尽快上线赚钱盈利,但对测试来说目标是保证产品质量,测试就是技术活,不管是业务手动测试还要自动化测试,同样也都可以发展得很好,都不是那么简单的~
自动化测试只是测试中的一部分,而 CI/CD 可以包含所有的测试,所以说:方方面面
概念不理解的话,好好看一下蒋老师的帖子,本坛第一价值神贴:https://testerhome.com/topics/9977
和楼主一样,之前在传统 IT 公司,走的都是瀑布模型,跳出来互联网公司,要求各种各样的技术。
然后现在,我有一半的时间是在做开发。
最后发现,我做的东西并没什么卵用,不过工资倒是多了不少
先不看大牛的评价,最近也遇到这样的困惑,但是还没有楼主这样积极探索。感觉越到后面发展,就必须要求你掌握更多的技能,虽然还是最开始的时候会探索测试的初心和坚持,后续就是寻找更多样的自己
大功能分为小功能,今天开发完马上上线,出了问题就回滚上个版本,修改后在发布,出了问题,在回滚,如此反复多次,即可完成任务。那么问题来,测试有什么用。
我见过很多测试经理转产品经理的,你要不试试
测试:位低钱少责任重,有过而无功。
奉劝各位入行不深的兄弟们早点转行吧,不然等到你有老婆孩子了想转都转不动了。