过完节回来看匿名吐槽贴子，发现自己对测试左移右移的理解跟帖子里很多人的理解不一致，想请教各位到底该怎么理解？
1、帖子里大家的理解
- 向左抢开发的事情，比如做 Code Review，担开发的责任甚至 KPI
- 向右抢运维的事情，比如做运维开发工作，担运维的责任甚至 KPI
2、我的理解
- 向左，通过评审等静态测试手段，预防缺陷或者争取及早发现缺陷，只为质量负责
- 向右，借鉴运维的技术手段（以及部分权限），将测试场景更加完善，相当于常规测试完毕之后的加固，只为质量负责
我看大家讨论的前提基调都是第 1 种理解，到底哪种才是真正的左右移？
这第 1 种理解是为了吵架生造出来的还是真的一直盛行于某些公司之中？
说下我对测试左移和右移的理解：
左移：通过对代码的静态扫描，安全扫描，组织评审等方式，提前解决一些可能的代码质量问题。其主要是在于质量问题，是代码质量的补充手段。这里我认为不是和开发抢饭碗，而是让开发更加专注业务层面的事情。
右移：通过对测试环境（开发环境、生产环境或许也有）的管理和质量维度的监控，实现上线前、上线后的质量保证。这里其实一般的测试主要是保证测试环境的质量。但是我觉得，对生产环境的质量监控是非常重要的，这是测试了解生产真实情况的最佳途径。右移我认为也不是抢运维的饭碗，也是对产品质量的保证补充。
传统以往的研发和运维体系，其实是缺失了这一部分的质量保证。研发没有从代码层面监控质量，运维没有从生产上监控软件质量。以前的运维，只要服务器不出问题，软件正常跑，其他就不管了。
但是现在微服务的发展，需要非常细的颗粒度去监控整个软件的运行，所以有了全链路追踪。全链路追踪这里可以认为是运维应该做的，也可以认为测试应该做的，因为测试的职责是把控质量，而链路追踪恰巧可以给测试了解到软件运行过程中非常多的质量问题，这也是以前没有的。所以现在很多公司是测试在做这块，运维没啥动力。
每家公司的情况都有很大的不同，有的公司可能开发规范，开发自然而然的就把我们需要左移的事情都做了，那测试就可以作为质量监督者把控下即可。如果是公司没有，那么测试做，可以提高自己。运维的活同理。
其实作为测试，我觉得无论如何，首先要准确的认识到自己做的事情是为了什么。无论是左移还是右移，目的都在于更好的产品质量。我们用的所有手段，所有技术，都是为了提高测试过程中的效率，准确判断产品质量问题。如果偏移了这个中心，那么我觉得测试就不再是测试了。
我理解为补位，而不是抢……要不然球场上没法踢球了。
不抢 KPI，但是想分别人如果 KPI 获得的好处呢？
我也一直是第二种理解。
本质工作做好以后，左移右移只会是加分项呀。
你认为的这两项，应该还是属于测试本职的工作，只是借助技术或者经验，拓展测试体系。
很多传统测试体系的大牛们，著的书里面应该能看到你的这两种方法!
至于左移与右移，如果仔细深究地话，恐怕要找到最早提出这一思想的人，问他何意
但是无论是他本意如何，就市场流行的观点看，更像是默认达成了一致，就是抢开发与运维的责任
此类做法真正实施的公司，基本上都是一些大公司，至少也是头部公司。
你一个只有几个测试的小公司，无休止的业务都搞不完，基本业务质量都难以保证，还要扯什么构建测试平台，那不是胡言乱语，更不用说 20 几个开发一起提交，你一个人去 code review，什么开发的责任揽过来一部分，还在完不成本职工作的前提下去构建 devops。
之所以出现左移右移的概念，大概是一些有余力的公司，他们有严格的 KPI 考核，每年要有什么质量提升 xxx，新技术引进效率提升 xx，而又没有过余考虑成本（可以招足够的人，给足够的钱），如果每年都搞测试本职那一套，恐怕 KPI 也没得写了，必须要有新的提升点，以及新的思想，新的测试技术，才能在领导面前邀功甚至交差，所以他们必然会侵入到开发与运维的领域，以此为战果。！
嗨呀，我以为的左包括：开发和运维；我以为的右包括：产品、运营、技术支持
。我以为的左右移，实际上的非核心岗位在激烈竞争下保值的手段，释放别人生产力，让别人更专业或者被淘汰。。
传统的测试——点点点系列，左移右移，跳出点点点之外的所有质量保障的手段，大概这样吧
1，2 都会涉及，如果算占比，2 多吧
质量工作是不会因为是谁的工作就不去做，比如我们之前做的监控，我们公司有 BA 的业务级监控和 SRE 的资源级监控，运营有舆情监控，还有服务端开发的各种数据监控，那问题来了，质量维度的监控怎么办？要说没有交集是不可能的，但是往往是因为大家角度不同，看问题的方式不同，从而容易产生业务真空地带。不过在推进过程中确实产生了一些抢地盘的问题，通过区分指标和角度，或者共建的方式来解决，本质上是希望能共同保障产品质量
换个角度想想：需要更多的移位、补位去为质量负责，难道质量真的是 “测” 出来的？还是 “写” 出来的，有时候很用力，但是打在了棉花上吧。资本的性质是逐利的，你想什么不太重要、老板想什么更重要一些吧？你能创造岗位还是能解决就业问题？没有增加新的蛋糕，那是不是就是原来的人在互道 SB·······
老师告诉你，有事别找老师，要自己自学。老师不能授给你鱼，会害了你，桃李满天下很花时间，学成龙大哥说的一样，年轻人，我看好你喔。
楼主既然又到了 4 小龙，应该也是管理者。
方便的话，是不是可以简单介绍一下目前您团队的主要工作和价值体现？这样更方便大家参考？
说下我对测试左移和右移的理解：
左移：通过对代码的静态扫描，安全扫描，组织评审等方式，提前解决一些可能的代码质量问题。其主要是在于质量问题，是代码质量的补充手段。这里我认为不是和开发抢饭碗，而是让开发更加专注业务层面的事情。
右移：通过对测试环境（开发环境、生产环境或许也有）的管理和质量维度的监控，实现上线前、上线后的质量保证。这里其实一般的测试主要是保证测试环境的质量。但是我觉得，对生产环境的质量监控是非常重要的，这是测试了解生产真实情况的最佳途径。右移我认为也不是抢运维的饭碗，也是对产品质量的保证补充。
传统以往的研发和运维体系，其实是缺失了这一部分的质量保证。研发没有从代码层面监控质量，运维没有从生产上监控软件质量。以前的运维，只要服务器不出问题，软件正常跑，其他就不管了。
但是现在微服务的发展，需要非常细的颗粒度去监控整个软件的运行，所以有了全链路追踪。全链路追踪这里可以认为是运维应该做的，也可以认为测试应该做的，因为测试的职责是把控质量，而链路追踪恰巧可以给测试了解到软件运行过程中非常多的质量问题，这也是以前没有的。所以现在很多公司是测试在做这块，运维没啥动力。
每家公司的情况都有很大的不同，有的公司可能开发规范，开发自然而然的就把我们需要左移的事情都做了，那测试就可以作为质量监督者把控下即可。如果是公司没有，那么测试做，可以提高自己。运维的活同理。
其实作为测试，我觉得无论如何，首先要准确的认识到自己做的事情是为了什么。无论是左移还是右移，目的都在于更好的产品质量。我们用的所有手段，所有技术，都是为了提高测试过程中的效率，准确判断产品质量问题。如果偏移了这个中心，那么我觉得测试就不再是测试了。
magicyang
回复
目前在做产品需求和部分 CRUD 工作，只不过还是过不去自己心里 “测试出身” 那道坎，所以一直有在关注质量技术相关的信息
我没准备评判哪个是对的哪个是错的，只是想知道大家到底是怎么想怎么做的，确保一下自己搜索出来的信息是准确的。
彼此彼此。做的最长时间的工作，怎么都绕不过。
我们团队也想解决问题，但是这几年来，看到的负面大于正面。
对于中小厂商，没有底层的工具建设，同时又涉及算法等等新知识，如何去保证质量？
测试至少代码能力和我们差距巨大，同时又没有相关背景，用原有的思维模式，右移部署环境还行，左移就不行了。
质量很难控制，我们有自己的单测，但是流程覆盖人力原因后端达不到，测试对业务核心理解有限。（新员工毕竟工程能力会弱一些，老一点的糊就去测前端，薪资水平甚至还不如外包。）
同意补位说，每个公司每个团队情况都不一样，建议针对性解决问题
同意补位说，全栈是不可能全栈的，毕竟能力有限，退一步的话就求一半，也就是向左，向右，将质量贯穿在团队工作中
话说天下大势，合久必分，分久必合。
做的人往往只能看到自己眼前的而需要别（测）的人能够看到更远以及可能出现的过程衔接点，就好像集成测试一样，本质就是围绕模块和模块对接的时候容易出现问题而设立的。测试的左移和右移本质是为了衔接需求与研发，研发与发布之间的预防
我理解的左移不是抢开发的工作，而是促进研发提高提测质量；右移则是协助开发定位线上问题和指导业务同事或客户使用系统。
怎么说，往左或者往右都是一种趋势，测试本身定义很广泛，要看你怎么去看这件事情。个人觉得如果按照当前测试的范围去做测试可能比较狭窄，只能按照自己的个性来发展往左或者往右
个人理解是第二点。
个人觉得，说抢饭碗其实有点过了，开发的核心饭碗是创造，用代码实现需求。运维的核心饭碗是生产环境管理，确保线上各复杂服务可以正常运行，耐得住各种意外。大部分测试左右移，再怎么左移也不会左移到直接帮开发写新功能代码，再怎么右移也不会右移到机房虚拟机等管理，所谓抢饭碗，只是一些对开发和运维来说非命脉而又和质量沾边的真空地带而已。
当时也有问楼主是不是和开发运维们沟通没做好，导致对方认为在抢饭碗。但楼主没有后续答复，所以也不知道到底是什么情况了。
