让我们探讨在测试左移的世界中，质量保证的角色如何增长。
译自 Who Should Run Tests? On the Future of QA，作者 Nočnica Mellifera。
这是正在进行的系列的一部分。阅读前几部分：
QA 很有趣。它的含义从“在所有代码上盖上最终印章的最资深工程师”到“只是随机点击并查看是否有任何故障的人”。我看到 QA 在组织的不同级别运作，从 与每个团队紧密集成的工程师 到一个独立的、几乎是外部的组织。
在我们考虑左移测试时，一个基本问题是，随着我们向产品团队分配更多测试责任，QA 在这种新安排中的作用是什么。这可以概括为“谁应该拥有测试？”微软于 2014 年取消了其“专门的软件工程师测试”(SDET)职位，而苹果和亚马逊仍然高度关注专门的 QA。如果 FAANG 公司无法决定我们是否需要专门的 QA 角色，我们其他人如何回答这个问题？
让我们探讨在测试左移的世界中 QA 的角色如何增长。
在我担任 New Relic 的第一个技术职位时，我遇到了所有为主要 Web 开发语言编写 APM（应用程序性能管理）代理的工程团队。每个团队都有类似的构成，但我问，“Ruby 团队的 QA 人员是谁？”
“没有，”Ruby 团队负责人回答。“Rails 不需要 QA。”
可以原谅该团队的傲慢：在没有人在坚持它解决了所有已知的软件问题，并且使错误、故障和意外行为变得不可能的情况下，现场永远不会出现新的热门语言。然而，这次谈话让我得出更一般的原则：有些人总是会将 QA 视为需要的一件令人尴尬的事情，这意味着一些团队会自豪地宣称他们不再需要专门从事测试的人员。
在这次谈话后的十年里，很明显，没有一种语言或框架可以免除测试的需要。这项工作可以高度分布，每个工程师都尽力编写测试、运行测试并解释结果。或者，这项工作可以集中化，由选定的少数人在每次发布时运行全面的测试集。
“过去，QA 负责运行所有测试，而开发人员只编写代码。”这从来都不是真的。自 格蕾丝·霍珀 等开创性人物的时代以来，开发人员一直能够运行他们编写的代码，并且没有人将真正未经测试的代码交给 QA。我们都添加了调试语句，检查了控制台日志输出，并单击了在本地主机上运行的界面。如果我们现在将测试左移，并不意味着开发人员将首次运行测试。
相反，左移意味着为开发人员提供一组完整且高度准确的测试，而不是仅仅根据他们对 API 契约和一些单元测试的理解来猜测他们的代码是否有效，我们希望开发人员在将其代码部署到生产环境之前真正确信他们正在移交有效代码。
这是一个简单、不言而喻的原则：当 QA 发现问题时，这应该让开发人员感到惊讶。如果开发人员将代码发送出去进行测试，并且他们不知道它是否有效，那么将会有许多简单、易于检测的错误，这些错误本可以在一天内解决，但现在将额外等待一周，等待外部循环反馈周期。
所有这些听起来可能不言而喻，但当涉及到集成测试时——了解你的代码如何真正与堆栈中的其他服务和依赖项相关——许多组织仍然依赖一个单独的团队来运行此级别的测试。在无法访问完整且准确的集成测试的情况下，当开发人员提交拉取请求时，他们会创造出一种情况，即前方潜伏着许多惊喜。
与在发布到生产环境之前监督代码的独立 QA 团队不同，在微服务环境中可能行之有效的方法是将 QA 专业人员和/或 SDET 嵌入到团队中。
嵌入到团队中的 QA 专业人员不应仅仅执行测试；他们的职责还包括编写全面的测试套件和识别服务中的回归。这种主动方法可确保在整个代码库中保持质量。工程师不应该测试他们过于熟悉的代码；当专门的 QA 客观地评估代码时，效果会更好。
QA 带来的一个关键价值是评估代码库的可测试性。通过专注于封装业务逻辑，QA 专业人员可以促进更轻松的测试，并有助于构建更健壮的架构。例如，这种方法允许根据需要更换数据库服务以进行财务优化，而不仅仅是提高可测试性。
在团队拥有各个微服务的基于微服务的环境中，QA 专业人员在监督这些服务之间的交互方面发挥着至关重要的作用。各个团队通常专注于其特定的微服务，可能会忽视经常出现问题的更广泛的系统交互。通过充当一个独立实体，QA 可以全面评估架构，确保全面的测试覆盖，并协助团队引导其测试工作。
然后，随着 QA 嵌入到团队中，更多开发人员了解如何运行高质量测试，QA 最终会做更多的事情，而不是更少的事情。QA 所做的工作变得更具战略性，并且对整体开发人员速度产生了更大的影响。诸如：
- 制定测试策略
- 构建测试框架
- 选择合适的测试工具
- 专注于更复杂的端到端自动化
- 向左移动并嵌入到产品团队中以实现更早的测试
随着对开发速度和可靠部署的需求不断增长，QA 将变得比以往任何时候都更有价值。
在 Signadot，我们正尝试让软件开发生命周期的每个部分的测试变得更容易。如果您有兴趣了解更多信息，加入我们的 Slack 以结识我们的社区。