测试左移，初级阶段就有以下四个台阶……
持
持续交付20约 4 分钟
持续交付20约 4 分钟
点击上面的” 预约 “， 每周三晚上 20:00，
来乔帮主聊天室，
聊聊你我的想法~
DevOps，研发效能， 团队管理，职业成长。
0 引子
现在都在提“质量内建，测试左移”。 这并不新鲜，算是“炒冷饭”吧～
因为 2001 年开始的 Agile， 就已经提出来了几乎相同的内容和做法～
1 “测试左移” 的初级阶段
在 DevOps 潮 流 中，很多团队提倡“测试左移”， 但 大多数团队只能做到“ 测试左移 ”的初级阶段 ，
而且，它们会分布在初级阶段的 四 个台阶 上 。 这四个台阶分别是：
（1）小批量提测； （2）跟随测试； （3）用例先行； （4）主干测试。
2 第一个台阶 “ 小批量提测 ”
小批量提测， 是指在一个迭代周期内，安排两个（或以上）的提测点，开发人员会将多个需求合并在一起，在迭代进入集成测试日之前就让测试人员开始进行质量验证。
这个台阶的特点是： 由于刚刚尝试 ， （1）开发人员质量意识不高，交付物的质量较低。 （2）测试人员也同样比较排斥，因为看上去，每个迭代内的工作量都加大了。 3
3 第二个台阶 “ 跟随测试 ”
跟随测试 ，是指：每当开发人员开发完成一个需求（任务）后，测试人员就能开始进行验证，以便更早地发现质量问题。也有人称其为“并行测试”，或者“小粒度测试”。
为了能做到这一点，测试人员必须在迭代早期（甚至迭代开始之前）就参与需求分析过程，以便尽早了解需求，而不至于让产品经理（需求分析人员）或开发人员再找时间给测试人员讲一遍需求。
这个台阶的特点是： （1）每个迭代结束时仍还会有一个“集成测试”，但集成测试的压力会减小； （2）跟随测试通常发生在这个开发人员的开发分支上。也就是验证这个分支上的产出物。
4 第三个台阶 “ 用例先行 ”
用例先行 ，是指 在某个需求开始开发（至少是结束）之前，测试人员就能提供一个针对该需求的测试用例列表，以明确该需求的质量验收标准。
这个台阶的特点是 ： （1）测试用例通常是非自动化的用例；
（2）开发人员被要求在提测前，对照测试用例列表完成开发自测；
（3）以"提测后，所有测试用例是否通过”作为评判开发工程师的工作质量的一个重要维度。
5 第四个台阶 “ 主干测试 ”
主干测试 ，是指测试人员的跟随测试发生在用于多人代码集成主干上，而不是在开发人员的个人开发分支上。 这一台阶可以与上一个台阶（测试用例先行）合并在一起，以减少测试人员的工作量，但对开发人员的要求会更高一些。
到底哪个分支是集成主干，取决于分支模式，即可能是 Master(Main)， 也可能是团队开发分支。
关于分支模式，请参考《持续交付2.0》第八章 “利于集成的分支策略”，该章节的目录如下所示。
这个台阶的特点是 ： （1）开发人员必须在集成主干上提测，也就是代码合并到集成主干才算开发完成；
（2）测试人员在迭代内的总工作量减少，因为不必在个人开发分支上 多 验证一遍了；
6 初级阶段的持续运转 是很难保证的
这种模式挺不错的，但通常来说，这种模式能够持续的时间不会太长，很快就会退化。
因为软件会越来越复杂，仅通过人力手工管理这么细粒度的测试用例，是很困难的一件事。 另外，重复回归测试的工作量也会不断更大。
此时，就会出现一种声音， 那就是“ 要做自动化测试 ”。 然而……
7 传统模式下 自动化测试的护
虽然很多大型团队做了很多年的自动化测试， 但当那些由测试部门的测试开发人员 编写的端到端自动化测试用例数量达到某一临界点后， 这些自动化测试用例很可能就成了“鸡肋”～
原因在于：维护它们需要花费大量的精力，
然而，软件产品的质量并没有提升，
开发人员也根本不太在意这些端到端的自动化测试用例，
因为他开发的功能在生产环境是好的，但是自动化测试用例失败了而已～
这些用例的失败很可能是由于
（1）需求变化了，但维护用例的人员并不知道；
（2）由于网络抖动，测试用例不能稳定执行； （3）由于执行测试的机器性能问题，导致测试用例失败；
（4）由于莫名其妙的原因，导致测试用例失败；
（5）这里还可以写很多……
更多旧模式以及其带来的问题， 参见《持续交付2.0》第十章 自动化测试策略与方法，目录如下：
那么，如何进入高级阶段呢？ 等我有空再说吧～
重磅推荐
《持续交付2.0》 硅谷顶级互联网公司的产品研发方法。 在未来十年里， 快速 提升工程生产力，打造有战斗力的团队， 应对激烈的 市场 竞争， 这一本书就够了~
持续交付2.0是实现组织战略目标的组织能力，并引入双环模型理论，以及基础工作原则、组织原则和架构原则；
通过多个互联网公司案例的解读，阐述如何根据组织的当前状况，应用原则，并对最佳实践进行取舍，快速达到组织能力目标。 关于作者