一孕傻三年,可能是真的......
前提:领导休假前,全面支持自动化的推进。
1、领导对业务很熟,技术不是很懂。
2、领导比较喜欢实实在在的输出,(例如:测试版本,找 bug)
我做的事情:
1、负责了方案的选型和落地。
2、经过好几个月,编写了 200+ 条接口自动化用例 (移植功能用例,接口逻辑组合)
3、现覆盖主流程回归,前提数据的产生。
4、打通 Jenkins 的 job 为后续集成准备。
目前:领导回归后,推翻前面的,重新制定 19 年安排。
1、不太认同当前自动化效果,认为效率不够好。
2、把我重新编排为点点点业务工程师,故曰,让我熟悉业务,然后不给资源,加班再继续完善自动化测试。
3、希望,后面我一个人把全部实现,并且取得很大的效果后,再进行推广复制。
我的想法:
1、目前的接口自动化有了一定程度,如果继续完善,投入成本比较大,希望梳理相关流程,希望公司能够投入资源。
2、重新给我的定位,和我预期设想差距比较大,我偏向增加代码覆盖率和引入 APM 和日志监控来完善流程。并且通过复制经验到其他项目中,来平摊研发成本。-----(和领导意见相左)。
我的吐槽:
1、领导回来之后,落差太大,从支持到直接砍了,之前还努力学习,到现在自己还没有完整的体验过,就直接不要了。这也太让我无法理解了。
2、这还没到过年呢,就说了这么大的变动,不想走都怕是要考虑一波了。
3、我已经说出我的顾虑和想法,领导还是按照自己的安排。----我自己感觉不爽。
4、这样的情况下,我是不是要溜.......
正常,公司请你是来创造价值的,不是让你来学习的。如果你能在私底下完成,说明你离升职加薪就不远了。。。
该怎么工作还怎么工作,听从领导的安排。
你做了领导也这样。
当然,如果你有更好的地方去的话可以开溜了。
找到自己的方向吧,如果工作不开心钱又不高何必呢。
我觉得测试这个职业做技术要凉了,你老大没做错,他有他的压力和考核。要么去做业务努力向产品发展,要么转开发吧。
所谓的大 V 在撕 UI 自动化,只能刷 KPI 数目,最没有绩效的自动化。
现在迭代太快了,测试的整体学习能力只能跟上点点点。
未来的应届生就业形势做算法的被压到做业务开发,做业务开发的压到测试,应届生技术基础完全碾压,基层测试凉凉。
迟早测试也会开始问 JVM 回收机制,双亲委派的,不过是早晚的事情。
说实话,看所谓的大 V 撕的心寒,真心没救了。
ui 自动化 可以很利于维护。只是不能拿原生的库直接用,要二次封装,甚至在开发一点小功能。
UI 自动化可以打不同标签进行,冒烟,版本回归,专有路径,主路径。
我来分析一波
首先提取关键字:全力支持,产假,全面否认。
这里也体现了你领导的心路历程。
全力支持阶段
可能外部环境迫使,或者你领导自身也想提高技术,你们合作算是热恋期,有共同的目标前进。所以啥都好说话,全力支持。
产假
这里是转折点,其实这个时候,就只有你一个人抗,虽然你把东西做出来了,但是,有没有考虑过能到公司内部的认可呢,这里里面就涉及到了办公室政治了,有没有给别人带来利益呢,或者有没有侵害到别人。这个东西不好说,假设就没有吧。
全面否认
你领导回归后,肯定是检查你的工作成果,但是你领导对技术本身是不太懂的,是属于传统型的,为了她能够快速掌握业务,再假设有人给你打小报告,那么你很可能就出现现在的结果,因为你领导这样做,她才能快速稳定下来。
建议
从楼主的描述来说,知道你内心是很不能理解和很受伤害的,没办法,因为这就别人能够当领导的本事,楼主就是遗漏了没有和领导一起把东西经历过来,只看到了结果。不过,你也赚了,至少你领导前期给了资源和项目让你去实施,也算给你积累了经验,后面就看自己了,再考虑考虑发展方向咯。不行就溜.....换一个认可你技术的领导和公司。
现在很多测试的人离开测试行业玩命的怂测试行业,我只想说,风水轮流转,苍天饶过谁
1、不太认同当前自动化效果,认为效率不够好。
-- 我觉得这个是需要沟通清楚的工作需求,也就是: 领导希望你的工作做成什么样,达到什么样的效率和效果。
如果这个无法达成共识,那么这个工作是没办法开展的,更别提后面的成功考核。需要和领导达成共识的是:自动化测试的目的不是为了发现 bug ,而是自动化回归。所以考核目标应该是执行效率和覆盖率。
悲哀的就是,领导其实根本不懂自动化的概念,还是传统思维,已经沟通过了,我认为自动化的目的还是覆盖率和效率,但是领导偏执的希望你去解决发现 bug 率,最大的分歧点就是这里,我感觉潜在含义是让我走了。
我觉得这就陷入了一个比较常见的死循环了,没有被认可的成果,就没有资源,没有资源就很难做出成果,这不管啥岗位都一样
你得评估下当前的公司成长和环境是否符合自己预期,如果符合,那么花点时间把东西做出来没什么不好,有产出肯定就会有资源了。主要蛋疼的是测试这鸟岗位不出问题就是没产出,出了问题就是大锅,怎么体现自己产出呢
最后一句话很有感触,测试工作单靠 bug 数量来量化产出也不合适,但你说不看 bug 数量又没有别的太多东西能看。自动化?脚本?覆盖率?没有直观成果感觉不好体现。
不会,我觉得你想的有点偏激了,或者是沟通哪儿出问题了,作为 leader 不至于不希望团队往好的方向发展,我觉得是你没说服他,举个简单的例子,实际的应用场景是不是更能说法他呢
假设一个版本的回归周期是 1 周左右,你在星期三之前测试的内容在后面 2 天一般是不会再手动去跑的,假设有紧急问题开发提交了文件导致了之前已测试模块出了问题,那么是不是就 cover 不到,这种时候自动化是不是就有效果了呢。
如果你做的自动化连主要流程和主要模块的功能都不能保障的话,那么我觉得你得想想自己的问题
人和人的不同点,估计就是在这里,其实在你的理解已经知道自动化的目的是用来提升效率,但是在传统的测试 leader 眼中,只会关注 bug 的产出,我已经说明,我的自动化已经在团队内部平稳运行主流程和重点模块的回归,因为是逻辑回归,业务同学也亲自感受了自动化的好处,不用重复点点点了嘛,能够找到 bug 是附带属性呀。
我说出了我的想法需要复制经验到其他项目中来更大的体现效率,而 leader 就认为你根本没有发现 bug,我投入这么多没必要,让业务同学不用省那么点时间,多加班也可以获得同样的效果 ---- 人肉战术。
就次进入了我现在的境地,leader 的意思很明显,就是自动化你自己去搞,bug 率也要有产出,就是日常工作要做,自动化你可以加班做,如果你的自动化可以发现很多 bug 了,又可以节省时间,那么就用你的方案,注意哟,leader 是不会提高任何资源的哟,口头配合。----这样的话我还不如做一条咸鱼!
1、管理好你领导的预期,自动化这事显然你做失败了
2、你认为争取的东西就应该有能力说服你的领导,如果无法睡服,说明你也不确定,领导的确没义务拿资源来给你试错……
怎么说呢,leader 和 leader 的差距还是比较大的吧,我是按照预期的理解来做自动化的提升效率,讲也讲过了,心累。遇到强势的 leader 想说服怕也不是一件容易的事情吧。因为 leader 的主观意见,是很难被推翻的。----不懂技术没办法呀!
更重要的是需要统一理念吧,分歧点太大,合作也很困难。
当前来说,我期望做技术推进业务的路线,leader 是希望业务堆切人力来完成,技术啥的暂时一边去。点点点才能发现 bug。
更多的是当前时机不对吧,也应该说业务量还不够大,见解也还不够深刻,没有在合适的时机做这个事情。
曾经做了一套 robotium 自动化脚本,刚完成才用了几遍(效果不太好,同样代码运行多次有一定几率运行失败),公司宣布开发新产品代替该产品了,导致整套还没有成长,就扼杀在摇篮中了。
那时很纠结,思考以下问题:
1.自动化是什么?为什么要进行自动化?
2.这套脚本能产生多大的效益?
3.目前的投入产出比怎样?
4.自己学到什么
最后 想到公司是有支付薪水让我在上班时间研究开发自动化脚本,瞬间觉得自己赚了,不但有了一次很好的练手机会,而且学习到不少的东西,我有信心在下一次做自动化脚本,我走的弯路会少些。
至于之后是走是留,看看后续的安排与自己的职业规划是否相符合了
你这完全是自己作的。从你的描述来看,你推进自动化这件事,完全是你自己一个人搞的,但凡你和你的直属领导有过仔细的沟通,或者和再上一级的开发 Leader 有过仔细的沟通都不会是现在的效果。沟通过后,要么就是不做,要么就会给你一定的资源去做,而不会像现在这样,做了一部分了,上级回来直接给你推翻。
业务同学也亲自感受了自动化的好处,不用重复点点点了嘛 ------------------------ 这个不行的吧,总归还是需要的,只是减少一部分
不是很理解你的意思。
我说了呀,前期是真的全力支持来做这个东西呀,并且我制定了项目的排期,来完成呀。
问题出现就是,leader 不在的中空时间段,leader 没有和我持续走下去,不经历过程,直接面对结果,因为确实沟通,肯定是有分歧呀,现在看来这也很正常。
至于回来推翻了,我觉得#6 楼分析的有道理,有很多方面的原因。
你说我作,我是不懂了,我认认真真做项目,解放业务同学的点点点重复,这个就是我做自动化的目的呀,我不是错也不是作,是有一些东西,不是我自己能够把握住的。
我能做的事情就是对项目负责,对业务负责,从前期的志同道合到后来的分道扬镳,我也是不舍得,做了这么多毕竟是自己得心血。不到万不得已,谁又愿意呢。
敢问大佬,我真的是作吗?
点点点,肯定是需要得,但是例如主流程回归,和模块回归,就可以进行替代呀,这里节省了时间,这个时间省下来了,无论干什么不了,多休息下也好呀,特别是业务量大得时候,更能够体现,同时这些用例可以运用在线上监控,数据构造当中呀。这个才是我做自动化得目的,可能前期投入高点,后面重复运用就赚了。
看作者是 社区第 12 位 ,会员,技术应该不是问题,估计主要还是领导不认可这件事情上。讲真,做技术这块,领导的行政资源支持太重要了,领导愿意作为他的主要事务来完成,推动力相当高。如果没有资源倾斜,级别又不够,是无法推动到其他项目或者整个质量部门的。
你直属领导不在的期间,你有和更上一级的领导持续沟通这个事吗?如果有,并且得到了支持,我相信你直属领导就算回来了也不可能说推翻就推翻。从说推翻就推翻这个既成事实来看,你应该是没有的,这是我说你作的原因。至于你说你的目标,你的负责的态度我都觉得没问题,但是这个世界本身就是方向比努力重要。军队的标语也是听党指挥,能打胜仗。思想上,方向上的统一本身就比团队内的人是否有能力更重要。
这个领导不是目光短浅,就是害怕你超过他,不过还有小部分可能是有业务压力,需要堆人手上去
我没有沟通就算作了吗,可能更多是还不是很懂这个职场道理吧。
我领导不在的,期间是需求的 leader 来给兼任,居然问我能不能让测试全部自动化,不需要人的那种,而且兼任 leader 更不懂技术,想得到认可,怕是更加困难。
我现在的感觉就是,做对自己有提升,做对团队有帮助,对项目和工作负责,至于政治什么的,真的不懂。我就希望能够开开心心工作,志同道合的同事一起协作。
沟通是职场里非常重要的一门学问,你没必要把他当成纯粹的办公室政治,不然你到哪里都觉得有政治。就算你与志同道合的人在一起,也有大家意见相左的时候对吧。
一个女领导,肯定境界不行,你能得到什么,之前去面试的一个领导也是女的,我想都没想,直接拒了 offer
不能再同意。完全是政治问题,领导最 care 的是自己位置的稳固。
注意你是在领导休产假期间做出的成果,领导全程无参与。如果领导认可了你的成果,而上面的领导必然会感知到你的贡献,你觉得无所谓,但你的领导会感觉不自在。
记得下次不管做什么东西,都要多请示领导,最好拉上领导一起做,这样做好了的话,领导更乐于认可。
提一个点,jenkins 集成进行接口自动化或许有些跟不上节奏了,接口测试的自动化,接口测试服务化平台化可能会好一些
作为一个管理层人员,一个很大的潜规则,是不轻易把自己的某项工作直接推翻。 这在领导面前是很难解释得过去:为什么花了那么多成本,最后没有任何产出?
所以需要看下你的情况:
那你应该做什么?
看了很多评论,我觉得是个普遍问题吧或多或少的。感觉作者是个踏实务实的人。我觉得更多是你 leader 的压力或者有人打小报告吧。不是你触碰了别人的利益就是你没给 leader 带来利益。思维方式上很多人都无法改变,如果确定改变很难,那就应该换个环境了
感谢你的建议。
接口测试平台化发展,之前也有和团队沟通过这个问题,自身业务体量还不够大,通过 CLI 的方式联通 Jenkins 是够用的,如果去发展平台的话,无论是二次开发还是自研都需要花费比较大的成本,可能会投入和产出比较低。
当前团队需要的是快速贴近业务的实践,后期有空闲了在搞平台,但是现在感觉凉了.....
你说的问题点,确实需要我自身去反省,我现在能做的也就是,努力把之前的工作成果保留住,希望后续还能够持续给团队带来效益。
至于 leader 层面,我个人的游说还是太薄弱了,说多了自己也累。
关于成绩,其实这一直是我搞不懂的点,可能就是前期没有沟通好,对结果产生截然不同的看法吧。leader 的主观是能够发现 bug,我主观是提高效率,这个真的解释不了呀,
也是有这个想法了,大家都是成年人了,个人主观意识,真的很难依靠外在条件来改变,只能自己去改变。
更多是能够统一理念,团队发展方向要一致,才能够有效率,大家干活才开心呀。
说政治问题的同学是不是太敏感了,自动化本身效率确实是需要考量的一个问题,运行效率、自动化用例编写效率、功能测试人员或者其他部门上手难易度、自动化用例错误分析难易度(日志分析)、各种中间件操作,单接口自动化用例生成等等,另外怎么和公司开发流程结合,嵌入当前测试体系,结合流程输入和输出产物帮助测试人员提前做一些自动化的事情之类更需要考量,要把整个平台搭起来短短几个月基本不可能,除非公司大领导能全力支持,因为这里面除了测试部门本身外,还需要开发运维等其他部门一起配合推动。我领导一样不懂技术,和不懂技术的人沟通需要掌握方法,不用扯太多技术类的东西,告诉她针对提效你这个方案能帮她达到什么效果就行。扯太多技术类的东西她听的也烦
讲实话,同学,我一开始也是这样说了,后面慢慢发现不对了,你领导应该还算是一个比较能够听取他人意见得吧。
我这里情况,恰恰相反呀,leader 很强势,必须按照她想的来实现。
导致分歧点就很大了,环境不一样,导致结果也不一样吧。
当一个人什么都不会,而且喜欢乱指挥,而且必须搞,并且他是你的上司。。。。。
说的很对,其实没必要自己加那么多心理戏,好好沟通就可以了
其实自动化,或者说测试技术,领导肯定是是非常关注且支持的,因为他们自己也有业绩压力,需要搞一些新的花样,技术这块是刚需,最容易出成绩的。领导推翻你之前的东西,你不妨自我审视一下,看看你做的在自动化有没有产生效益
有没有效益,不是看你做了几个框架,谢了多少用例,覆盖了多少流程,而是要看对手工测试有没有帮助,你的自动化有没有应用到项目中去,你的执行结果有没有测试、开发产品关注,你的自动化到底能为测试提高多少效率,比如手工回归要 1 小时,你自动化回归一遍比这时间还长,而且也不能完全覆盖手工,更致命的是就算失败了也不一定是系统 bug,很可能是环境不稳定,或者用例写的不健壮,导致你的结果不被信任,那你的回归测试自动化在花也意义不大。
其实现在很多公司做自动化都是测试领导想上汇报需要,在实际工作中手工该怎么测还怎么测,自动化的结果根本不关注。根本没有纳入研发流程。只是拿出去分享吹牛 B 用的
兄弟,这真不是加心理戏的问题了,我做的成果被 leader 拿去汇报,并且我将不再负责我原有的技术发展路线了,之所以发匿名吐槽贴就是想说说我心里的不痛快,能沟通的话就不会出现我现在的情况了。
很多事情还算要根据环境判断吧,当你的 leader 不是那种大度的人的话,离凉真的不远了。
不能挂你的领导,大环境就是这样的。小公司搞测试自动化就是玩玩而已,基本落实不了。
十分同情你,咱哥俩一样的遭遇。我自己的成果硬生生被 leader 搞成由他主导的全组的成果。结局就是他凭借这个上位或者达到好的绩效,反身回来踹了我两脚。人轻言微,上面的领导只会听汇报,而汇报的人是他不是咱。大领导只关心结果,不会纠结于最底层的小兵这一层级的功过得失。
我反正是心凉了,做出了成果还不如不做。什么都不做,领导不会把你视为威胁;做好了,领导还得想办法压制你。
哈哈哈 我想知道是哪家公司 以后可以不用去面试了
我已经凉了,拿了年终奖就走。
楼主几个问题:
公司的规模,技术部规模,测试组规模,专职测试技术方向的几个人?
我的背景,民企,外企,创业,现在在 bat,关于自动化的几个思考:
1、项目属性基本决定测试玩法,纯业务还是中后台产品
2、团队规模或者说用户数决定了测试的深度
3、是否有支撑整个产品研发流程的 CI/CD 体系,如果有的话,自动化是非有不可,不仅仅是自动化测试而是全流程自动化
4、回到个人做自动化的目的?证明自己的 coding 能力,还是想帮助到项目,不管是发现 bug 还是提升效率
5、如果我是你的话,我会怎么做?
我曾和你一样,所以慢慢地打算转岗了。