之前在群里看到一个比较有意思的话题，有人在讨论测试左移的价值，核心观点是：测试左移会降低产品和研发的交付质量，同时因为左移消除了很多缺陷，导致测试发现的缺陷数减少，让测试 “没有被充分利用” 而显得工作不饱和。
是不是很有意思？
本文无意反驳任何观点，只是觉得这个话题很有意思，结合自己在团人中的实践，聊聊自己的想法。
01
先讨论一个总量：测试左移是否减少了测试工作量？
答案是否定的，左移并没有减少测试的工作量，只是把原来测试时间从完整的一大块（瀑布模式下属于测试的专属时间），切分成分布在不同阶段的平行时间，同时，还保留了一部分专属时间用于集成测试和回归测试。
举个例子，原来测试熟悉需求，来源于需求文档和需求评审会，此时需求基本上已经定稿。在实践测试左移时，从需求定义及优先级排序时，测试就介入，参与需求的讨论，协助产品完成验收标准的输出，这样更有利于理解需求的场景和业务价值，减少信息传递引起的衰减，从而可以更针对性的设计用例。
左移至开发侧，也是一样的，只是把测试用例分批提前了而已，同时可以让开发更好的自测。
02
测试左移是否会让产品和开发产生依赖心理？
其实并不会，或者说，这个完全取决于个人的想法。在原来的研发模式下，开发人员也没有完全依赖测试来保障质量啊。单元测试、静态扫描还是一样在做（虽然大部分做得不是很好）。对于测试左移，个人的思考是：不是让你在其他领域指指点点，而是通过自己的经验和能力，协助他们更好地完成原来的工作。
还是以左移至产品侧为例，在了解业务需求的背景和业务价值后，测试人员要做的不是如何参与去做产品的设计。二是需要尝试去消除用户故事中描述模糊之处，识别 Backlog 对整体的影响。并设计好验收场景，让团队知道什么条件下，这个需求算是 “做好了”。原来产品该做的设计还是由产品去做。
03
缺陷数对测试人员的意义
在整个测试左移的过程中，由于提前发现和规避很多问题，包括开发自测提升了移测质量，会让测试人员的部分产出（缺陷数）减少。如果你团队还在用缺陷数考核测试人员，那我建议你还是早点做打算的好，毕竟 2023 年了，不是 2003 年。
在测试人员的价值体现一文中，个人阐述了对于测试人员的价值思考，有提到：
当我们做好缺陷预防后，就可以提升研发的交付质量。有的人会担心 BUG 少了，老板会认为测试就可以减少人力，是不是会把自己做没了？其实大可不必有这样的担心。当研发交付质量提升后，测试可以把时间腾出来做更多有意义的事，比如探索性测试、可观测性测试等，这些测试活动，不论对个人，还是对团队，都是有利的。做好测试该做的事，讲好测试该有的故事，才能真实地体现测试人员的价值。
04
团队对于测试左移的期望是什么？
测试左移，其实就是通过一系列的活动，能提高质量的上限（对齐需求，减少非必要的返工），缩短测试的周期（减少测试专属时间，缩短交付时间），始终将质量稳定在一个水平线上，进而和团队一起追求更高的目标了。
对于测试左移的落实，最重要的就是全员质量服务意识的培养，不要把提测认为是测试活动的开始，上线是测试活动的结束，更不要认为质量只是测试同学需要关注的。
以上，共勉。
看完了帖子和所有人的聊天， 突然想起某位大佬说过的一句话：千万别让理论派做老板，讲道理时简单一句话，实操时千言万语都不足以表达。
我记得几年前我们那有个 leader 在群里对着手下说：我希望大家对质量是有敬畏态度的，不能觉得把 UI 上的用例跑完了了就足够了，你们需要深入到产品代码里，我要求研发修复的每个 bug fix 你们都要去代码里去分析风险，会不会引起其他的问题。
这位 leader 说的话对不对？理论上完全没错， 但我们统一管这叫永远不会出错的废话。道理谁都懂， 但是他手下要面对的是什么情况呢， 我们看一下那个产品主要以 go 语言实现， 其中还包含了大数据，机器学习，云计算，边缘计算。 而这些测试人员是什么情况呢， 几个正式带一大堆外包，并且项目全都是倒排，排期压缩到了令人发指的程度。 这个前提下，怎么执行这项命令？
首先那一堆外包别说 go 语言代码了， 人家能写个 python 脚本就了不起了， 要是代码写的溜人家也不至于来做外包。 你想让他们看懂 go 代码， 得搞内部培训吧。培训怎么排？怎么能在项目倒排的大环境下协调这些测试人员完成培训，还得保质保量的完成培训。 这些培训要花多长时间， 怎么计划培训内容，这都是问题吧。 还有不是会写代码就能看懂人家产品代码逻辑的， 得安排研发来宣讲代码逻辑吧，得培训大数据，机器学习，云计算，边缘计算的各种逻辑吧， 得安排研发和测试做结对吧， 那人家研发凭啥配合你， 人家也是项目倒排。 做 code review 也得有机制吧， 这年头有几个团队正经八本搞 cr 的，谁有那个时间， 都是自己对自己的代码负责， 你怎么改变这个情况， 这不仅是排期的事， 你还要改变工程文化吧。 还有一堆在实操过程中出现的乱七八糟的状况就不多说了。
所以你看就一个测试人员参与 code review 这事， leader 简单一句话，但要办起来要有多么复杂的工作，要花多长时间。 理论需要有， 但理论不是动动嘴皮子这么简单的， 我们都知道王阳明的知行合一。 光动嘴皮子，说一些永远不会错误的正确的废话是十分容易的。 难的是知行合一，难的是把理论落地。
这就是为啥说，大道理谁都懂，但大家为什么不这么做？ 就好像问你为什么不去清华，你说为啥，那难道还能是因为不喜欢么？ 不管左移，右移，cicd，概念早就烂大街了， 就那么几本书大家该看的都看完了。 问个在校学生人家都懂这些理论。 所以提理论是没错的， 但我希望我们做的是把理论落地，而不是空讲理论。
最后说一句我信奉的哲理： talk is cheap，show me the code
对项目和团队来说，左移没啥毛病。
对个人来说，得看考核制度，不同的项目，你每个月找 1 个缺陷，别人每个月找 100 个缺陷，同样是线上没出问题，但是总有傻逼觉得你没在干活。
这种问题已经没有意义了，市场好的时候，你前后左右移的都行，现在就是缺陷保命，能提的缺陷越多越好
大部分测试方法论都过于理想化，在高并发，倒排，以及资源严重不足的情况下，都运作不下去。尤其在当下降本之后，每个角色都降到缺人了。
恒温
回复
“从需求定义及优先级排序时，测试就介入，参与需求的讨论”，光是这一点就理想化过度了，现实就是：组长忽然打了个通知，我这边收到一份不详细的需求文档，开发还没写完，接着明天转测
CKL的思考
回复
bug 数是真能保命，大厂我不知道，但是一般的公司，老板和高层都不是技术出身，你绩效最直观的成果就是找的 bug 数，我管你做了多少效能提升，这些都是看不到且成果有待验证的，但是我找出的 bug 数是实实在在的，做成扇形图不知道多好，未来也是各种效能证明的有效武器
恒温
回复
理论肯定是象和简化了部分场景，大方向上应该是没什么问题的。
缺人的情况下，更得注意做事方法，有些成本还是得花的，比如左移的时间、和开发对齐的时间，主动点。
无非是把时间花在提测前还是提测后。
看完了帖子和所有人的聊天， 突然想起某位大佬说过的一句话：千万别让理论派做老板，讲道理时简单一句话，实操时千言万语都不足以表达。
我记得几年前我们那有个 leader 在群里对着手下说：我希望大家对质量是有敬畏态度的，不能觉得把 UI 上的用例跑完了了就足够了，你们需要深入到产品代码里，我要求研发修复的每个 bug fix 你们都要去代码里去分析风险，会不会引起其他的问题。
这位 leader 说的话对不对？理论上完全没错， 但我们统一管这叫永远不会出错的废话。道理谁都懂， 但是他手下要面对的是什么情况呢， 我们看一下那个产品主要以 go 语言实现， 其中还包含了大数据，机器学习，云计算，边缘计算。 而这些测试人员是什么情况呢， 几个正式带一大堆外包，并且项目全都是倒排，排期压缩到了令人发指的程度。 这个前提下，怎么执行这项命令？
首先那一堆外包别说 go 语言代码了， 人家能写个 python 脚本就了不起了， 要是代码写的溜人家也不至于来做外包。 你想让他们看懂 go 代码， 得搞内部培训吧。培训怎么排？怎么能在项目倒排的大环境下协调这些测试人员完成培训，还得保质保量的完成培训。 这些培训要花多长时间， 怎么计划培训内容，这都是问题吧。 还有不是会写代码就能看懂人家产品代码逻辑的， 得安排研发来宣讲代码逻辑吧，得培训大数据，机器学习，云计算，边缘计算的各种逻辑吧， 得安排研发和测试做结对吧， 那人家研发凭啥配合你， 人家也是项目倒排。 做 code review 也得有机制吧， 这年头有几个团队正经八本搞 cr 的，谁有那个时间， 都是自己对自己的代码负责， 你怎么改变这个情况， 这不仅是排期的事， 你还要改变工程文化吧。 还有一堆在实操过程中出现的乱七八糟的状况就不多说了。
所以你看就一个测试人员参与 code review 这事， leader 简单一句话，但要办起来要有多么复杂的工作，要花多长时间。 理论需要有， 但理论不是动动嘴皮子这么简单的， 我们都知道王阳明的知行合一。 光动嘴皮子，说一些永远不会错误的正确的废话是十分容易的。 难的是知行合一，难的是把理论落地。
这就是为啥说，大道理谁都懂，但大家为什么不这么做？ 就好像问你为什么不去清华，你说为啥，那难道还能是因为不喜欢么？ 不管左移，右移，cicd，概念早就烂大街了， 就那么几本书大家该看的都看完了。 问个在校学生人家都懂这些理论。 所以提理论是没错的， 但我希望我们做的是把理论落地，而不是空讲理论。
最后说一句我信奉的哲理： talk is cheap，show me the code
CKL的思考
回复
刚毕业那会我会怼，现在不了，干嘛给自己找难受？去得罪领导干嘛， 一家公司又不是都能长久待，能待个三年不裁员不降薪都不错了，卷入这种纷争干嘛，怼赢了 leader 还是 leader，但是小组员就不好受了
测试新人
回复
你参加代码评审，发现代码一个方法有问题，只能提 1 个 bug，这个方法可能被多个提供给前端的接口使用，影响到多个功能，黑盒测试的同事可能提出 10 个 bug 都是这个方法的问题导致的，如此考核是不是有点问题了
luck咕咕
回复
我觉得不冲突吧？ 首先开发也是活人，对于大多无效 bug 是会提出意见来制衡测试的，如果 bug 数能用来考核测试，那也是反向考核开发，开发对于 bug 数量会去和测试沟通把无效 bug 删除。
再者你不能用开发的思维去考虑测试呀，因为一个方法能发现 10 个不一样功能的 bug，难道不是更全面的测试覆盖？ 且回归 bug 修复时，你的针对性验证也能做得更加全面，我倒觉得不是挺好的？ 开发也可以一键关闭相关类型的 bug
我的观点：
测试左移理论上是正确的，而且优秀高效的测试团队确实在不同形式实践测试左移的理念 —— 但是往往实践不会和理论一模一样，会做一些删减；按照测试人数被压到较少的常态现状下，需求都是倒排的形式插入，测试多数以配合交付为主，确实没有人力在需求最早期就参与进去的，属于心有余而力不足；如果真的能做到这种程度，我个人倾向于认为是外企、国企，或者很成熟的行业才能这么考虑人力利用。
不做测试左移，或者没做好测试左移，不代表测试团队能力不足（作者没表达类似观点，我属于插播）—— 测试左移只是保障质量的其中一种手段，搞质量需要先认清当前测试人力容量，在能以至少及格分水平支持需求交付的测试之外，再额外做一些中长期对质量有改善的工作，包括但不仅限于流程改进、度量运营、灰度发布、线上监控、研发构建效率等很多不一定是传统测试领域的事情。测试左移可以适当投入，做到 70 分程度 ROI 就不错，如果要做到 80 分甚至 90 分，必然有边际效应。
bug 数作为绩效考核，听闻很多公司都会用这种办法去衡量产出，至少在大厂里对外包也会做 bug 数的横向对比以考虑某外包是否留下（还会结合该外包经手的需求质量）；可以说它粗暴，但是不能说明它不合理。因为想把它做得很合理是要成本的，当 “这个成本 超过 拍脑袋决定绩效 导致的损失” 之后，就显得无足轻重。所以它确实有问题，但除非能提出更好的办法而且足够低成本，不然…… 那就忍受
这种讨论和以前测试要不要写代码一样的无聊。
重要的事情说三遍：“有能力别做测试，别做测试，别做测试”
孙高飞
回复
作为一个多年开发，发现测试本职工作都没做好，还想着卷别人是不是不合适。谁没做好就替换谁，测试能做好架构，做好产品就直接转过去更专业的做事情，比左移右移好多了。
测试左移其实也是为了更好的做测试，最基本的，左移能够保证你的测试用例是相对更准确和靠谱的。
左移不影响你测试能力的提升。有的人从技术层面去提升，有的人从业务的角度出发。在当下的互联网环境中，可能对技术的提升需求更显著。但是在实业或者制造业，一个慢懂 MES 或者 WMS 业务流的测试，价值远高于会技术的测试。笔者现在就在实业，比较清楚业务的价值。
陈小猫
回复
从供需关系上来说，现在 1-2 年的有没有可以转的机会都难。
大龄的很多思维定式了，要来就是给自己埋雷。
看别人 DO 都是容易的，自己 DO 就呵呵了。
测试左移，还是要看团队的能力，真能做左移的有几个团队呢
各司其职才是最快最好的方式
为了报答老板不把我裁掉，我天天睡公司，加班加到死
IT 不等于互联网. 很多大吵的互联网概念在制造业的 IT 领域并不是要考虑遵循的.
一切以实际落地出发, 一切以解决问题出发.