** 18年的时候第一次看到测试左移、测试右移的概念，感觉很新鲜，种草在实际的项目运用此思路和方法的念头。19年独自负责带队测试一个新项目终于得以落地拔草。
** 分享下当时的做法。
** 项目大体还算是迭代使用瀑布（增量）的模式，测试人员在正式提测冒烟之前的需求阶段较之前就开始较深入的介入，全链路，对需求做详尽的分析，主要针对但不限于产品的产出文档，研发针对需求的概要设计研讨会等。
** 开发编码阶段，持续每天都对开发的代码做功能的单元测试，开发，产品，测试使用相同的拆解好的需求矩阵，矩阵会有细分好的迭代目标，该目标对应岗位人员的进度（看板的另类演绎），每日更新各自的任务（燃尽图的另类演绎），如果一个人的任务在某个位置放了很多天，就可以看出进度。如果需要协助的多方（计划令牌的另类演绎），完成的时间不一样，互相沟通为什么需要那么那么多的时间，在每日的站立会议，简要的提出协助的问题。提前发现问题，防微杜渐，避免积重难返这方面的效果也还不错。
** 到了真正提测之后，发现的bug数有了非常显著的减少。
** 发布上线之后，还有一两个月的试运营，被动的也进行了一些测试“右移”，有些没有第一时间发现的问题修复后，直接在线上环境验证做了数据纠正后的一致性，以保证尽可能少的影响到用户。还有一些性能的监控以及用户意见的反馈收集，并据此做的调整后，也是测试环境过了一遍，线上再过一遍。
** 从质量管理的角度，当时是整个研发团队全员全程参与其中，换来了较好的交付质量，但测试的工作量比之前也明显增加了很多。毁誉参半。
** 不管是什么类型的开发模式，万变不离其中，确定性项目，一切都已明确，可以自动化生产流程，实验性的项目，充满不确定性，scrum或者敏捷。测试左移或者右移都可以适当的移植进来。
** scrum一个spring是2-4周，敏捷一个迭代增量周期是1-2周。相对而言，测试左移对敏捷项目，左移产生的效能并不特别明显。
** 后来接触更多的是需要及时投入市场，如果时间错过了，毫无意义的项目，所以基本都用了原型开发的模式：软件工程师与客户会晤，定义整体目标，明确已知需求，并大致勾画出以后再进一步定义的东西，然后迅速策划出一个原型并进行建模，快速设计要集中在那些客户和最终用户能够看到的方面，比如人机接口布局或者输出显示格式。对原型进行部署，由客户或者用户评价，再根据反馈，进一步细化软件需求。不断调整以满足用户需求。慢慢就模糊了左移和右移的概念，似乎测试工作贯穿产品声明周期始终。
** 19年时，又接触到了一个新的名词：内建质量。 以下均直接拷贝原作者内容。 在微软有一句名言：“质量是设计出来，而不是测出来的。” 这是理想情况，事实上身边的产品经理都是离这种让世界和谐的优秀还有很大的距离。那么从测试和开发的角度如何内建质量呢？
让测试内建质量
** 1.产品，开发，测试应该同时参与需求评审会议，澄清需求，达成共识
** 2.将关键测试点作为需求的一部分，让开发同学交付需求时完成自测
让开发内建质量
从开发的角度看，要提高代码的质量可以有很多种方式：
** 1.提高自测意识，借助单元测试或者质量分析工具
** 2.真正理解需求和技术架构，进行Code Review或者结对编程
** 3.评估代码质量或者bug数量，跟绩效挂钩
** 4.排除开发的自身能力问题，80%的bug都是需求理解不准确的问题，如果开发不愿背这个锅，那就甩给产品经理吧。
由此可见，如果测试不想看见这些bug，那么你就要帮产品表达需求，帮开发理解需求。
内建质量中的测试左移
上面我们说内建质量其实已经涉及到了测试左移，例如让QA在参与需求研讨时提出问题，列出测试点其实已经开始在进行测试了。
为什么我们要测试左移呢？因为发现问题的时间越晚，修复的成本就越高。
图中橙色线条代表了传统测试发现缺陷的时间，大多数bug都是在功能测试和集成测试时发现的，最后导致的结果就是发布前加班加点，祈祷不要有bug漏到生产环境。
如果我们能把测试活动向左移动，那么就意味着修复成本大幅下降。
在阿里是这样实践的，让测试给开发赋能。
内建质量中的开发赋能
从字面上解释就是，测试同学给开发赋于一定的能力，让他们有能力去完成测试，比如：
** 1.降低测试门槛 ** 2.使用测试工具（自动化） ** 3.获取测试数据 ** 4.培养测试意识 举个例子，开发同学在完成需求代码后，可以点击一个按钮得到测试数据，再点击一个按钮验证测试覆盖点，喝杯咖啡后就可以看到测试报告。 从上面这个例子看，开发同学其实他并不需要懂测试数据的设计，自动化测试的开发，测试报告的编排，但是他依然可以快速完成需求测试（门槛低），只要他养成习惯（培养意识）。 那么你就会说，这对测试的同学要求是不是很高啊？对啊，回到开篇的问题，如何评判一个测试人员的能力？在我看来就是评判他给开发和团队赋能的能力。在阿里是这样，在微软和谷歌也是这样。 一个优秀的测试人员将测试左移时，并不会将负担转移给开发。相反地，而是帮开发写出更高质量的代码，更高效率地交付需求。 那么测试能左移到什么程度呢？比如让开发在Coding时就发现问题，或者还没Coding就发现问题，那应该是极好的。
怎么做到呢？刚才已经说过了，测试即需求，把bug扼杀在摇篮里。
实践方法
想实践测试左移可以有很多种方法，每个组织需要根据实践情况进行裁剪和调整。
参与需求评审，帮助开发理解需求 参与架构、设计分析，提早预防问题 践行BDD，TDD 单元测试提案，接口测试提案 提供模拟数据能力，测试工具 制定提测标准，拒绝低质量代码 回归测试自动化 静态代码分析，单元测试覆盖率 测试左移的概念给整个测试角色带来了巨大的转变。软件测试不仅仅是“发现bug”，而是致力于“尽可能早的检测和预防bug”。
