作者|于晓南测试原点左移修复缺陷的成本在逐渐增加同时，大部分缺陷是在中后期发现的，越晚发现的缺陷修复成本越高。因此，为了降低缺陷修复的成本，我们希望能够更早地发现缺陷。那么上图就完全ok了吗？这不，这张图出自于1996年的一本书《Applied Software Measurement》。画这张图的时候，敏捷宣言还没有诞生（敏捷宣言诞生于2001年）。在传统语境下，需求明确且相对固定，需求产生的缺陷可以忽略不计。同时，需求阶段产生的问题可能会引起整体解决方案的返工，因此需求产生的问题不太可能以软件缺陷的形式体现出来。需求质量要求测试向左移动。随着软件生态的发展，软件需求越来越复杂多变，需求的有效性和交付效率也受到挑战。受大环境影响，在需求阶段引入的缺陷对软件开发成本有影响。同时，软件开发过程越来越成为一个需要高效协作的整体，角色之间的界限也变得相对模糊。为了让质量理念更早地融入软件开发过程，减少缺陷修复和不必要返工的成本，需求的质量就显得尤为重要。于是，测试左移诞生了，需要需求分析师和测试人员共同努力，保证需求的质量。重画上图除了需求阶段。理想情况下，我们可以很容易地得出以下结论：缺陷的引入从需求阶段持续不断，在研发阶段达到顶峰，然后趋于平稳。发现它在测试阶段达到峰值，然后趋于平缓。从需求阶段到研发初期，缺陷修复成本极低。从研发后期到上线，缺陷修复成本一路攀升至高点。发现的缺陷数量小于引入的数量，但在上线前后，发现的缺陷数量大于引入的数量。因此，为了获得更经济的资源投入产出比，我们认为应该在需求阶段和编码前期发现更多的缺陷，从而减少修复成本和返工，这也是测试的左移。价值所在。那么，如何保证需求的质量呢？不同时期我们面对的需求有不同的表现形式，需要深入了解这些差异，并有针对性地进行设计质量活动验证。几个层次需求的一个很现实的例子有一天，大老板说：“微信小程序不错，我们要做一个内部OA流程，你安排一下，年内发布。”这是大boss的一句话要求。当项目经理拿到这个需求，看到“年内发布”时，需求管理板上会多出一张卡片，上面只有“OA小程序”几个字，时间可能会临时安排在第三季度。两个月后，一批棘手的需求被送走了。暂时松了口气的项目经理扫了这张卡片，顿时头皮发麻。还有老大生的大坑，必须尽快填上。打电话给产品经理，快速出一个版本的方案，然后让技术经理大概预估一下工作量。只靠一句话，显然是没有办法想出方案的。产品经理和技术经理花了两天时间研究，花了半天时间搞出了第一版OA小程序。一周后，该提案通过了审核。这时，产品经理按照既定的计划，细化了一些需求：用户管理、组织管理、流程管理、表单配置、权限配置、审批配置、微信登录等，即将进入研发阶段，需求将再次细化。以用户提交请假的场景为例，可以将需求细化如下图。进入研发后，研发会根据一定的研发优先顺序接到需求。需求的三个粒度上面的故事中，为了服务于产品规划和不同的管理需求，需求呈现出以下三个粒度：EpicStory>FeatureStory>UserStoryEpicStoryEpic：需求的粗粒度描述通常需要多个It需要一次迭代完成，主要用于版本规划时记录和跟踪特征故事Feature：也叫主题故事，是一系列具有相同主题的用户故事的集合，主要用于迭代规划、优先级排序和整体预估用户storyStory:迭代开发的最小单元是更细粒度的需求描述，主要用于迭代交付过程中对不同粒度需求的质量保证进行预估、跟踪和管理。当需求还是一句话的时候，测试人员能做的事情并不多。当史诗故事即将进入迭代规划和程序设计时，测试人员可以参与。在解决方案形成的初始阶段，测试人员可以参与解决方案讨论和技术可行性研究，贡献现有的业务流程或潜在的业务逻辑。对于质量风险较大的解决方案，测试人员有责任提出质疑和建议。方案确定后，测试人员可以进行测试设计，包括但不限于：功能的质量期望、粗略的测试规划、现有测试资源的评估、重大质量风险及应对方法等。Featurestory：Requirementsreview&testplan接近迭代，需求将以Features的形式体现。这时，测试人员可以参与需求评审：对于功能需求，测试人员首先验证需求是否有效，包括确认需求的价值，以及需求涉及的场景是否完整。、是否与现有业务逻辑冲突明确功能需求背后的支撑需求，确认支撑需求的范围、验收标准、测试方法等；此外，还需要考虑用户体验考虑因素的拆分是否合理和方便。在质量活动的预估和迭代管理方面，测试人员可以执行测试计划，例如各种测试活动的安排，评估测试结果、测试的重点难点、测试阶段的输入输出等，都可以在这个阶段得到确认。UserStory:RequirementAcceptance&TestExecution故事开始时，测试人员需要补充需求影响范围内的需求接受用例和回归用例。之后，测试人员主要关注需求验收和测试执行，根据测试设计和计划进行测试，确保最终实现质量。这个阶段，测试人员尤其需要注意输入输出的比例，把有限的能量用在刀刃上。有效的做法是在测试计划阶段明确各功能的质量标准和资源投入，并在测试执行阶段随时回顾。但是计划死了，人还活着。如果在测试过程中发现计划跟不上变化，需要随时与团队沟通，灵活调整。当然，质量活动不会以功能测试和上线结束，而是需要完成一个完整的闭环。测试阶段之后的质量活动超出了本文的范围，所以我不会在这里展开太多。小结测试左移之所以重要，是因为我们要在缺陷引入的初期就发现它，把缺陷扼杀在摇篮里，而不是坐等它像滚雪球一样越滚越大。这里的误解是，测试左移所要求的测试活动尽早参与，而不仅仅是测试人员左移。因此，团队的每一位成员都需要有把测试左移的思想，从一开始就把质量这根弦绷紧，确保大家的工件质量。在需求的质量保证活动中，测试人员也时不时需要换个帽子，有时可能是终端用户，有时可能是产品经理，有时可能是产品负责人。不管你戴什么帽子，保证每个神器的质量，以及每个神器的顺利集成，都是测试人员可以重点关注的。谈到质量，我们责无旁贷。
