如何真正实现测试左移

交付速度不应受测试团队处理能力的限制！

我们渴望比竞争对手更快交付，渴望加速产品上市；但质量同样至关重要。若要鱼和熊掌兼得，团队应致力于：

并行开展开发活动（而非串行作业）。
减少缺陷带来的过程损耗。
在流程每个环节实施恰当的质量保障措施。

目前一些专职测试团队作为"缺陷捕捉者"模式的致命缺陷——当测试成为交付瓶颈时，公司的交付能力将完全受制于测试团队的吞吐量。最糟糕的实践莫过于设立显式的"测试阶段"，这最终必然演化为"缺陷修复阶段"。

许多开发者评估过结对编程的益处，但结对测试呢？

为有效实施，作为完成定义的一部分，开发者应在创建拉取结对请求前与质量保证工程师（或其他开发者）进行简短会议，共同验证代码变更是否符合预期，且实现过程是否遵循所有约定的质量规范。这不仅能发现隐藏的边缘用例或场景，还能作为培训活动——质量保证工程师向开发者传授各种测试设计技术，培养他们的"测试者"思维。质量保证团队屡屡发现，票面上明确书写的验收标准实际上未被落实。通过在提交代码审核前让质量保证工程师参与功能验证，开发人员能更确信功能符合质量标准，识别未预见的场景，并通过早期解决问题加速交付周期。

开发人员花费10-15分钟与质量保证工程师开会，其成本远低于执行完整开发周期修复缺陷（有时耗时数小时甚至数天）。在某些情况下，双方甚至能共同审查单元测试和集成测试，识别潜在的代码漏洞。

结对测试在质量工程中的角色

结对测试应作为质量工程的"补充"而非"替代"。现在让我们回顾哪些活动有助于构建内建质量：

小范围变更。这是红线原则。
通过RFC文档、架构决策记录（ADR）或专职架构委员会进行架构决策，具体取决于项目关联的风险等级。
API风格指南，确保API简洁、直观且一致。
设计系统中的可复用UI组件，通过创建标准化用户界面构建框架提升质量。
早期验证设计资产。
严格的代码审查实践及静态分析工具的应用。
在真正产生价值的位置合理分配自动化测试。正视现实：若仅验证一个想法，可能完全无需创建自动化测试；金丝雀测试或许已足够。
同时包含功能性和非功能性标准以及测试示例的验收标准。

因此，在进行结对测试时，质量保证工程师能够验证系统是否按预期运行，且实现本身准确无误。这包括检查开发人员是否复用标准组件而非新建组件，以及错误日志是否符合既定日志策略等要素。其目标是在可用时间和结对测试参与者知识范围内，尽可能预防问题。这正是测试左移（shift left）的实际体现。

这是否意味着开发者无需自行测试代码呢？

并非如此。在理想世界中，独角兽从一道彩虹跃向另一道彩虹，系统行为只需定义一次，无需在多处重复逻辑。然而现实中，我们会在不同层级制定规范和测试系统。这些测试往往存在重叠，以多种方式检查相同元素，从而尽可能多地识别潜在问题。

但如果我们能编写作为可执行测试的规范呢？通过正面和负面示例明确系统行为要求，即可创建后续用于验证这些要求的测试。这种方法被称为"基于示例的规范（Specification by Example）"，它强调以Gherkin语言编写的BDD场景形式制定需求，并可转化为可执行代码。

然而，在高度复杂的系统中，我曾目睹团队试图为供应链工作流创建此类场景——理解系统运作方式变得异常困难。尽管如此，我确实喜欢在需求细化阶段制定轻量级测试策略（即测试清单）。缺少这一步骤，团队将无法全面评估准确估算任务所需的工作量。在复杂的单体系统中，由于影响范围广泛，小型代码变更有时需要投入大量测试精力，且并非所有组织都愿意为遗留系统投入自动化。最终，开发人员应能自行确认系统按预期运行，而实现这一目标所需的一切信息都应集中记录在一个地方——任务清单上。

结对测试为何真正有效

其有效性源于结对编程的可行性：两人协作优于单打独斗——它整合了不同的视角、经验和问题解决方式。同样的原则也适用于开发人员与测试人员之间的协作。

我曾遇到过许多开发人员，他们并不完全理解语句覆盖（statement coverage）与决策覆盖（decision coverage）的区别，甚至不清楚最基本的要求是什么。许多人也不熟悉测试设计技术，且往往缺乏测试人员和质量保证工程师所具备的深度业务知识。

“测试的独立性带来的主要好处是，由于独立测试者拥有不同的背景、技术视角和认知偏差，他们可能比开发者更容易识别出不同类型的故障和缺陷。”
——国际软件测试资格认证委员会（ISTQB）基础级第4版（FL v4）

长期成效

我曾经定期与各级工程师进行面谈，以评估部门的工作成效。起初，大家对结对测试当然存在抵触情绪。然而，一段时间后，我开始看到成效，开发人员实际上更愿意花时间参与会议，而非事后单独处理多个问题。以下是我对成效的总结：

质量保证工程师与开发人员之间的关系更加紧密，测试不再被视为破坏性的活动，而是降低风险的措施。
代码质量得到提升，因为开发人员开始了解各种测试设计技术，并能够预防更多问题。
开发人员对系统的整体运作有了更深入的理解，并在新变更的影响分析中发挥更有效的作用。
减少了约50%可能原本会被标记为"不予修复"的小缺陷，从而全面提升了系统的一致性。
周期时间缩短。尽管在集成环境的系统探索阶段仍会发现少量问题，但数量已不关键。
即使质量保证工程师有几周不在岗，也不会引发恐慌。