测试基础 老师说不懂就要问,我有个疑惑想请教各位

槽神 · 2020年10月09日 · 最后由 houzf 回复于 2020年10月13日 · 5283 次阅读

过完节回来看匿名吐槽贴子,发现自己对测试左移右移的理解跟帖子里很多人的理解不一致,想请教各位到底该怎么理解?

1、帖子里大家的理解

  • 向左抢开发的事情,比如做 Code Review,担开发的责任甚至 KPI
  • 向右抢运维的事情,比如做运维开发工作,担运维的责任甚至 KPI

2、我的理解

  • 向左,通过评审等静态测试手段,预防缺陷或者争取及早发现缺陷,只为质量负责
  • 向右,借鉴运维的技术手段(以及部分权限),将测试场景更加完善,相当于常规测试完毕之后的加固,只为质量负责

我看大家讨论的前提基调都是第 1 种理解,到底哪种才是真正的左右移?
这第 1 种理解是为了吵架生造出来的还是真的一直盛行于某些公司之中?

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
最佳回复
共收到 24 条回复 时间 点赞

我理解为补位,而不是抢……要不然球场上没法踢球了。

不抢 KPI,但是想分别人如果 KPI 获得的好处呢?

恒温 回复

测试就是打野的,不游走怎么带节奏,要是带崩三路那就是真的。。。。。

我也一直是第二种理解。
本质工作做好以后,左移右移只会是加分项呀。

你认为的这两项,应该还是属于测试本职的工作,只是借助技术或者经验,拓展测试体系。

很多传统测试体系的大牛们,著的书里面应该能看到你的这两种方法!

至于左移与右移,如果仔细深究地话,恐怕要找到最早提出这一思想的人,问他何意

但是无论是他本意如何,就市场流行的观点看,更像是默认达成了一致,就是抢开发与运维的责任

此类做法真正实施的公司,基本上都是一些大公司,至少也是头部公司。

你一个只有几个测试的小公司,无休止的业务都搞不完,基本业务质量都难以保证,还要扯什么构建测试平台,那不是胡言乱语,更不用说 20 几个开发一起提交,你一个人去 code review,什么开发的责任揽过来一部分,还在完不成本职工作的前提下去构建 devops。

之所以出现左移右移的概念,大概是一些有余力的公司,他们有严格的 KPI 考核,每年要有什么质量提升 xxx,新技术引进效率提升 xx,而又没有过余考虑成本(可以招足够的人,给足够的钱),如果每年都搞测试本职那一套,恐怕 KPI 也没得写了,必须要有新的提升点,以及新的思想,新的测试技术,才能在领导面前邀功甚至交差,所以他们必然会侵入到开发与运维的领域,以此为战果。!

嗨呀,我以为的左包括:开发和运维;我以为的右包括:产品、运营、技术支持😅 。我以为的左右移,实际上的非核心岗位在激烈竞争下保值的手段,释放别人生产力,让别人更专业或者被淘汰。。

传统的测试——点点点系列,左移右移,跳出点点点之外的所有质量保障的手段,大概这样吧

1,2 都会涉及,如果算占比,2 多吧

质量工作是不会因为是谁的工作就不去做,比如我们之前做的监控,我们公司有 BA 的业务级监控和 SRE 的资源级监控,运营有舆情监控,还有服务端开发的各种数据监控,那问题来了,质量维度的监控怎么办?要说没有交集是不可能的,但是往往是因为大家角度不同,看问题的方式不同,从而容易产生业务真空地带。不过在推进过程中确实产生了一些抢地盘的问题,通过区分指标和角度,或者共建的方式来解决,本质上是希望能共同保障产品质量

换个角度想想:需要更多的移位、补位去为质量负责,难道质量真的是 “测” 出来的?还是 “写” 出来的,有时候很用力,但是打在了棉花上吧。资本的性质是逐利的,你想什么不太重要、老板想什么更重要一些吧?你能创造岗位还是能解决就业问题?没有增加新的蛋糕,那是不是就是原来的人在互道 SB·······

老师告诉你,有事别找老师,要自己自学。老师不能授给你鱼,会害了你,桃李满天下很花时间,学成龙大哥说的一样,年轻人,我看好你喔。

楼主既然又到了 4 小龙,应该也是管理者。
方便的话,是不是可以简单介绍一下目前您团队的主要工作和价值体现?这样更方便大家参考?

槽神 #14 · 2020年10月09日 Author
magicyang 回复

目前在做产品需求和部分 CRUD 工作,只不过还是过不去自己心里 “测试出身” 那道坎,所以一直有在关注质量技术相关的信息

我没准备评判哪个是对的哪个是错的,只是想知道大家到底是怎么想怎么做的,确保一下自己搜索出来的信息是准确的。

彼此彼此。做的最长时间的工作,怎么都绕不过。
我们团队也想解决问题,但是这几年来,看到的负面大于正面。
对于中小厂商,没有底层的工具建设,同时又涉及算法等等新知识,如何去保证质量?
测试至少代码能力和我们差距巨大,同时又没有相关背景,用原有的思维模式,右移部署环境还行,左移就不行了。
质量很难控制,我们有自己的单测,但是流程覆盖人力原因后端达不到,测试对业务核心理解有限。(新员工毕竟工程能力会弱一些,老一点的糊就去测前端,薪资水平甚至还不如外包。)

左移右移大概是没有真正好好做测试的大佬,以为测试以提测为始,发送测试报告为终。发现测试时间太紧,如果提测之前做点啥,测试质量和效率就提升很多了,殊不知古法测试早已经定义好了 STLC,各阶段修复 bug 的成本。
任何软件开发到线上的过程都会存在大大小小的问题,前些年的 QA 没做好流程的质量保障,现在貌似也很少有这个职位了。需求分析,架构评审,单元测试,静态扫描,CR 也不是啥新鲜东西。测试本来就应该在整个软件生命周期都能发挥作用,毕竟号称熟悉业务以及上下游,技术栈更全面。测试不如提高提测门禁,让开发把质量弄得更棒,对自己要求更高。
看目前说的左移右移也都是流程标准的实施,随之而来就是开发平台去自动化执行和检验,其实跟测试关系不大,你去做这些事情了只是让你们开发团队更标准更专业了,跟转行没太多差别,但是你开发的平台工具,每天也就了不起几十个用户,几百访问量。还不如直接转开发或产品,成就感会高百倍。

同意补位说,每个公司每个团队情况都不一样,建议针对性解决问题

同意补位说,全栈是不可能全栈的,毕竟能力有限,退一步的话就求一半,也就是向左,向右,将质量贯穿在团队工作中

话说天下大势,合久必分,分久必合。

做的人往往只能看到自己眼前的而需要别(测)的人能够看到更远以及可能出现的过程衔接点,就好像集成测试一样,本质就是围绕模块和模块对接的时候容易出现问题而设立的。测试的左移和右移本质是为了衔接需求与研发,研发与发布之间的预防

我理解的左移不是抢开发的工作,而是促进研发提高提测质量;右移则是协助开发定位线上问题和指导业务同事或客户使用系统。

怎么说,往左或者往右都是一种趋势,测试本身定义很广泛,要看你怎么去看这件事情。个人觉得如果按照当前测试的范围去做测试可能比较狭窄,只能按照自己的个性来发展往左或者往右

个人理解是第二点。

个人觉得,说抢饭碗其实有点过了,开发的核心饭碗是创造,用代码实现需求。运维的核心饭碗是生产环境管理,确保线上各复杂服务可以正常运行,耐得住各种意外。大部分测试左右移,再怎么左移也不会左移到直接帮开发写新功能代码,再怎么右移也不会右移到机房虚拟机等管理,所谓抢饭碗,只是一些对开发和运维来说非命脉而又和质量沾边的真空地带而已。

当时也有问楼主是不是和开发运维们沟通没做好,导致对方认为在抢饭碗。但楼主没有后续答复,所以也不知道到底是什么情况了。

恒温 回复

不在一个相同的意识领域工作,当然会误解其他人的做法。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册