为何我们要将测试左移？回到过去的美好时光

以下为作者观点：

为何我们将测试左移？在传统的开发周期中，测试通常在功能完成后甚至在开发阶段结束时进行。左移测试通过从开发过程开始到整个开发过程整合测试活动来挑战这一点。

让我们首先讨论一下为什么我们选择“左移”，因为这不是解决软件开发生命周期（SDLC）扩展问题的唯一方法。

一个古老的故事：无法扩展的 SDLC

在我们决定将更多的测试转移到流程的开发之前，让我们首先讨论一下领导者为什么会做出这个决定。

有一种对“左移”的愤世嫉俗的解读是“让人们做更多的工作，但支付相同的报酬”。压力重重的开发团队可能会反对在他们的工作清单上增加更多关注点的想法。但将测试左移的真正动机是对软件发布周期陷入僵局的沮丧，开发人员被迫进行上下文切换，永远无法进入流动状态，以及缓慢的开发速度。

一家测试流程不完善的扩张型公司

想象一下，你所在的公司已经从初创阶段发展到现在。你都记得曾经有一段时间，功能会在几周甚至几天内发布，但那样的日子已经一去不复返了。现在，多个团队正在尝试同时发布分支，而 QA 则在发布到生产之前努力发现问题，压力很大。

更糟糕的是，微服务架构的复杂性意味着开发人员无法在将代码交付 QA 之前有效地进行集成测试。关于改进合同测试的讨论很多，但同样，事情正在迅速发展，编写清晰的服务内合同并进行相应的重构估计需要几个月的时间。与此同时，开发人员被困在编写单元测试和为外部服务（如支付提供商）甚至其他团队的服务创建粗略的模拟上。当代码部署到预发布环境（如暂存）时，这会导致更多意外。

选择将测试转移到左侧

因此，我们的工程主管面临着一个选择：如何提高开发速度，同时减少生产过程中的错误？你有几个选择，其一：

增加QA团队，并扩展其测试/登台环境的资源，以便他们能够更快地进行更多测试。

这不是一个可扩展性极强的选择。团队已经偶尔会就谁可以部署到临时环境以及需要保留环境多长时间发生冲突。此外，即使有更多的 QA 工程师，你仍然需要让开发人员编写代码、运行有限的测试、推送，然后等待人工回复检测到的问题。结果是一个“外循环”反馈周期，开发人员要么必须暂停所有工作，直到他们得到 QA 反馈，要么在两个分支之间切换上下文，因为他们试图开发下一个功能，同时切换回来并发现他们推送的最后一个内容存在问题。即使 QA 团队的预算无限，这也绝对无法扩展到数百名开发人员。

增加QA并不是向左移动的替代方案

随着工程团队将测试工作向左转移，QA 在测试的战略愿景和架构决策中发挥着重要作用。但仅仅扩大 QA 团队并不能完美地实现确保更多版本成功的目标。这是为什么呢？

由于开发人员在合并代码之前只进行基本测试，因此 QA 很可能会发现琐碎的集成错误。

属性列表是数组还是对象？定位器是否从 0 开始索引？当 QA 测试这些小的集成错误时，它们可能会阻止发布。现在 QA 需要记录并反馈问题，而不是由开发人员自己发现代码中的小问题并快速修复错误。更糟糕的是，QA 不知道该与谁沟通：

QA 团队通常会编写端到端测试来测试业务/用户流程。如果任何测试失败，则不清楚该将问题归咎于谁，因为流程可能会涉及多个前端和后端服务。

作为开发人员，你会更新user_state_controller，但作为 QA，你可能正在测试诸如“用户能够更新其登录信息”之类的内容。这并不是不匹配，因为团队有不同的目标。但是，当 QA 在用户流程中发现错误时，他们不一定知道开发部门中谁是最适合沟通的人。这会导致进一步的延迟。

运行测试的节奏不明确。QA 应该每天运行测试吗？每次合并拉取请求后都运行测试吗？由于测试套件可能很大，因此每次提交都运行整个套件是不切实际的。

如果没有一个工程师团队来确定要运行的最佳测试集，QA 最终会以较低的节奏运行测试，并且只能在大型组中发现问题。

当测试在 QA 阶段失败时，开发人员会经历非常缓慢的调试周期。当有多个提交一起测试时，不清楚哪一个是有问题的提交。

我认为这是一个值得进一步讨论的基本问题：由 QA 团队运行大型测试套件是一种确保一切都按设计端到端运行的有吸引力的方法。但高保真测试也需要高频率。否则，我们将失去源代码控制的基本好处：如果不对每个提交运行测试，我们将无法轻松回滚和修复。这是“左移”测试回归旧标准的众多方式之一：开发人员应该能够立即判断他们当前的一组更改是否破坏了某些东西。第一次依靠 QA 来发现问题意味着你要从一长串失败中挑选出哪些是由哪个提交引起的。

这个过程变得更像瀑布模型，其中开发和 QA 是截然不同的连续阶段。这与具有明显优势的敏捷方法相反。

再次强调，我们谈论的是 2005 年编码和交付标准的倒退。瀑布模型使得真正的持续交付生产变得不可能。

这里的一个基本思想是，QA 作为错误的唯一发现者会削弱工程师的权力。

增强工程师的能力

即使领导层不担心速度影响，你也可以想象，大多数反馈来自外循环的设置对工程师来说可能是令人沮丧和痛苦的。抛开我自己的自尊，我不想推广我没有信心的代码。这给我们带来了第二个选择：

将测试左移，让开发人员在编写代码的几分钟内就能运行集成测试甚至端到端测试，并确保在无法 95% 确定一切正常的情况下，不会对预发布版本进行任何质量保证。

在这种情况下，作为一名开发人员，打破常规又会变得有趣：我们正在试验，看看其他服务可以支持什么，并且只推动我们知道有效的方法。QA 仍然在这种设计中扮演着重要角色，但他们的角色不再是手动测试和发现单个错误。相反，QA 团队成为定义自动化策略、选择测试框架和让开发人员对自己的代码更有信心的战略领导者。由于每天都有测试可供每位工程师使用，因此将编写和运行更多的测试，但他们的反馈会通过内部反馈循环直接传递给开发人员。

将测试向左移动意味着回归更古老、更完善的系统

在最近的一次平台工程精益咖啡小组讨论中，一些参与者提到了一个想法，让我印象深刻：

“微服务有很多优点，但微服务的测试难度要大得多。这个问题非常严重，以至于许多团队看不到微服务的真正好处。”

我之前写过关于这个的文章，但总结一下：在单体时代，通常有一种方法可以在笔记本电脑上以最小的阻力运行整个系统或复制品。这意味着重要的测试可以在开发过程中进行。

所以，实际上，当我们谈论将测试向左移动时，我们谈论的是将其向后移动。我们仍然有 QA 团队的作用，但我们希望将第一轮测试重新交到编写该功能的工程师手中。

质量保证仍然发挥重要作用

有理由问，将测试工作向左转移是否意味着 QA 工程师将失业。

这完全是错的。当团队中的技术专家由于设计变更而将部分职责转移时，结果是这些专家最终会做更多而不是更少的工作，并且对他们所能实现的目标抱有更高的期望。

“这里还有谁配置电子邮件服务器？”

几年前，我听了 Kelsey Hightower 的一次演讲，他提倡转向无服务器和公有云托管工具，而不是直接管理虚拟机。听众中有人问：“你想让系统管理员丢掉工作吗？”

Kelsey 的回答很有见地。“这个房间里的每个人，如果你曾经配置过电子邮件服务器、其证书和身份验证，请举手。”

大约有 80% 的人举手。

“如果你仍在维护电子邮件服务器的配置，请举手。”

没有人举手。我在这里转述一下，但这是他接下来所说的话的关键：

“你们所有人都拥有丰富的系统管理经验。当一项服务出现并消除部分工作量时，正常结果并不是你们的工作量减少，而是我们期望更多。现在，我们希望虚拟机能够随着配置更改而自动出现，而不是要求启动新服务器并等待至少一天才能部署它。不要让我开始自动集群扩展。”

观点很正确：当一支合格团队的工作被取消时，结果是更高的期望，而不是工作量减少。被取消的是那些随意的繁重工作，而不是人。

想想过去几年许多系统管理员的遭遇：他们曾经负责手动设置和管理数十台服务器，而现在，同样的人负责编排数百或数千个容器。虽然没有人再配置电子邮件服务器，但我们对这些人的期望却只增不减。

质量保证作为战略领导者

将测试左移的目标不是要取消 QA，而是让 QA 成为战略领导者，帮助标准化测试文化，维护自动化以使事情顺利进行，并选择测试框架和标准以便共享结果。想象一下一个可以做到以下事情的 QA 团队：

帮助选择并更新应用程序不同领域的测试框架；
定义测试策略以及哪些新功能需要新测试；
监控“垃圾”，例如长期失败的测试或反馈不佳的测试，并努力解决技术债务，从而改善每个开发人员的体验；
添加已知边缘情况、安全风险和隐私故障的测试覆盖率，以确保代码保持合规。

由于没有不断的合并失败，QA 可以专注于发现自动化测试可能遗漏的突发行为和回归问题。QA 还可以花时间了解开发团队最需要的测试类型，定义使测试编写花费最少时间的实践，并优化测试运行器以减少测试执行时间，从而加快开发人员的内部反馈循环。

嵌入式QA：始终值得思考

在我的第一份技术工作中，每个语言团队都有一名QA专家和一名文档专家。我记得这一点，因为唯一的例外是Ruby和Java。Ruby没有QA，因为“Rails 不需要 QA。”Java 没有技术作家，因为“Java 是自文档化的。”我们真是太傻了！但在整个团队中嵌入 QA 的基本想法仍然很强大。

多年前，QA 专家使用了一些自动化技术，但同时也是手动操作产品以查找故障的大师。回想起来，我们低估了所有语言中 QA 和文档的必要性。Ruby on Rails 不需要 QA 或 Java 是自文档化的信念现在看来很幼稚。

如今，考虑嵌入式 QA 甚至更加重要，特别是软件开发测试工程师 (SDET)。这个想法是将 SDET 嵌入到可以拥有自动化的产品团队中。SDET 专注于编写自动化测试，通过嵌入到每个产品团队中，他们也具有领域意识并可以编写有意义的测试。

结论：向左移动是回到过去的美好时光

左移的动机主要源于希望提高开发速度并减少生产中出现错误的频率。

对于正在成长的公司来说，系统的复杂性（尤其是微服务）又增加了一层挑战。开发人员编写代码并依靠 QA 来发现问题的传统方法无法随着公司的发展而有效扩展。

测试左移选项提供了一种解决方案，它使开发人员能够在开发过程的早期执行更全面的测试（包括集成测试甚至端到端测试）。这一变化恢复了开发人员的主人翁意识和满足感，因为他们可以立即验证自己的工作并更有信心地提交拉取请求。

这种转变不会削弱 QA 的作用，而是会改变它。QA 更多地是领导战略、定义和维护自动化框架以及确保整个开发过程的质量。将测试向左移动不仅仅是回归更高效的开发实践，让人回想起以前系统更简单、可以更直接测试的时代，而且这是对现代软件开发复杂性的必要适应。这一转变旨在提高软件发布的速度和质量，这对于希望在不影响质量的情况下有效扩展的公司来说至关重要

感谢每一个认真阅读我文章的人！！！

作为一位过来人也是希望大家少走一些弯路，如果你不想再体验一次学习时找不到资料，没人解答问题，坚持几天便放弃的感受的话，在这里我给大家分享一些自动化测试的学习资源，希望能给你前进的路上带来帮助。