共计 2758 个字符，预计需要花费 7 分钟才能阅读完成。
一、测试左移的由来
1.1 缺点的修复老本逐渐升高
上面是品质畛域司空见惯的一张图，看图谈话，容易得出：大部分缺点都是晚期引入的，同时大部分缺点都是中晚期发现的，而缺点发现得越晚，其修复老本就越高。
因而，为了升高缺点修复老本，咱们冀望在更早的工夫发现缺点。
那么上图是否齐全没问题呢？不是的，这张图来源于 1996 年的一本书《Applied Software Measurement》，这张图画成的时候，麻利宣言还没诞生呢（麻利宣言诞生于 2001 年）。在传统背景下，需要是明确且绝对固定的，需要产生的缺点能够忽略不计。同时，在需要阶段产生的问题可能会引起整体计划的返工，因而，需要产生的问题不太会以软件缺陷的模式来体现。
1.2 需要品质召唤测试左移
随着软件生态的倒退，软件需要越来越复杂多变，需要的有效性和传递效率也备受挑战。受大环境影响，需要阶段引入的缺点就对软件的研发老本造成了影响。同时，软件的研发过程越来越成为一个须要高效合作的整体，各角色之间的界线也变得绝对含糊。
为了让品质理念更早的染指软件研发过程，也为了升高缺点修复的老本、缩小不必要的返工，需要的品质变得尤为重要。测试左移因而而生，需要剖析人员与测试人员须要协同工作，独特保障需要的品质。
加上需要阶段重画一下下面的图，现实状况下，咱们容易得出以下论断：
- 缺点的引入从需要阶段就开始继续，到研发阶段达到峰值，而后趋于平缓；
- 缺点从需要阶段就开始陆续被发现，到测试阶段达到峰值，而后趋于平缓；
- 从需要阶段到研发初期，缺点修复的老本极低；
- 开发前期到上线，缺点修复老本一路攀升至高点；
- 缺点发现的数量少于引入的数量，但在上线前后，缺点发现数量大于引入数量。
因而，为了取得更经济的资源投入产出比，咱们认为应该在需要阶段和编码初期更多地发现缺点，从而缩小修复老本和返工，这也正是测试左移的价值所在。
那么，该如何保障需要的品质呢？咱们在不同的期间面临的需要，其状态是有差别的，所以须要深刻理解这些差别，并有针对性地设计品质流动加以验证。
二、需要的三个档次
2.1 一个很事实的例子
一天，大老板说：“微信小程序不错，咱们外部 OA 流程得做一个，你们安顿一下，年内公布就行。”这就是一个来自大老板的一句话需要。
项目经理拿到这个需要，看到“年内公布”，需要治理看板上就能够多一张卡，只有几个字“OA 小程序”，排期可能临时安顿在第三季度。
过了俩月，送走了一批艰巨的需要，临时松口气的项目经理扫到这张卡，霎时头皮发麻，这还有一个老板亲生的大坑呢，得尽快填上。喊来产品经理，快出一版计划，再找技术经理大抵估一下工作量。
只有一句话显然是没法出计划的，产品经理和技术经理各自焦头烂额的钻研了两天，又花了半天临时碰出了 OA 小程序的初版计划。一周后，计划通过评审。这时，依据既定计划，产品经理细化了一些需要：用户治理，组织治理，流程治理，表单配置，权限配置，审批配置，微信登录等。
行将进入研发阶段，需要又会被再次细化。以用户提交请假单的场景为例，需要可被细化如下图。进入研发后，开发以肯定的优先级程序来支付需要进行研发。
2.2 需要的三种粒度
在下面的故事中，为了服务产品布局和不同的治理诉求，需要呈现出以下三个粒度：
史诗故事 > 个性故事 > 用户故事
- 史诗故事 Epic：粗粒度的形容需要，通常须要多个迭代能力实现，次要用于版本布局时记录和跟踪该性能；
- 个性故事 Feature：也叫主题故事，是一系列雷同主题用户故事的汇合，次要用于迭代布局、优先级排序和整体估算；
- 用户故事 Story：迭代开发的最小单元，是细粒度的需要形容，次要用于迭代交付过程中的估算、跟踪和治理。
三、不同粒度的需要保障
3.1 史诗故事：计划验证 & 测试设计
在产品演进过程中，当面临的需要还是一句话时，测试人员能做的事件并不多。当史诗故事行将进入迭代布局，进行方案设计时，测试人员就能够参加进来了。
计划成型初期，测试人员能够参加计划探讨和技术可行性研究，奉献既有业务流程或潜在业务逻辑，针对有较大品质危险的计划，测试人员有责任提出质疑，并给出倡议。
计划确定后，测试人员就能够着手进行测试设计了，测试设计包含但不限于：针对该性能的品质预期，大抵的测试布局，现有的测试资源评估，次要的品质危险及响应形式等。
3.2 个性故事：需要评审 & 测试计划
邻近迭代，需要会以个性的模式体现，此时测试人员能够参加需要评审：
- 针对性能需要，测试人员先验证需要是否无效，包含需要价值确认，需要波及场景是否齐备，与现有业务逻辑是否有抵触；
- 针对性能需要背地的撑持性需求进行廓清，确认撑持性需求的范畴、验收规范、测试形式等；此外还须要思考用户体验；
- 思考需要的拆分是否正当，是否便于估算和迭代治理。
品质流动方面，测试人员能够落实测试计划了，如各种测试流动的安顿，测试成果的评估，测试的重点和难点，测试阶段的输出和输入等，在这个阶段都能够确认了。
3.3 用户故事：需要验收 & 测试执行
故事启动时，测试人员须要补充需要验收的用例，以及需要影响范畴内的回归用例等。在这当前测试人员次要关注在需要验收和测试执行上，依照测试设计和打算进行测试，确保最终的实现品质。而在此阶段，测试人员尤其须要关注投入产出比，把无限的精力用在刀刃上。卓有成效的做法是在测试计划阶段就明确好各性能的质量标准和资源投入，并在测试执行阶段时刻回顾。但打算是死的，人是活的，万一在测试过程中，咱们发现打算赶不上变动，就须要随时跟团队沟通并进行灵便调整了。
当然，品质流动并不是以性能测完上线为完结，而是须要实现一个残缺的闭环。测试阶段当前的品质流动不在本文探讨的范畴内，在此就不做过多开展了。
四、小结
测试左移之所以重要，是因为咱们要在缺点引入的最后阶段就发现它，把缺点扼杀在摇篮里，而不是等着它像雪球一样越滚越大。而这里的误区在于，测试左移要求的是测试流动尽早染指，而不仅仅是把测试人员进行左移。因而，团队里的每个成员，都须要有测试左移的思维，都能够从一开始就绷紧品质这根弦，确保每个人的工件品质。
而在需要的质量保证流动中，测试人员也须要时不时换帽子，有时可能是终端用户，有时可能是产品经理，也有时可能是产品负责人。不论戴什么帽子，保障各个工件的品质，以及各工件的顺畅集成，都是测试人员能够关注的事。品质相干，咱们义不容辞。
起源：圆小豆的美梦工场
作者：于晓南
申明：文章取得作者受权在 IDCF 社区公众号（devopshub）转发。优质内容共享给思否平台的技术伙伴，如原作者有其余思考请分割小编删除，致谢。
5 月每周四晚 8 点，【冬哥有话说】品质与测试专场。公众号留言“品质”可获取地址
- 0506 朱少民《如何最大化软件测试效力》
- 0513 陈琦《数据驱动测试》
- 0520 陈霁《没错，去 QA 是提高质量最无效的办法！》
- 0527 施慧斌《DevOps 实际之继续测试》
