如果你听取思想领袖的意见，QA 正在走向死亡。它毫无用处，而且很昂贵，此外，我们现在有机器可以做这些。根据我自己的经验，我已经在没有专门的 QA 团队的组织中工作了几年……我所说的转型是质量保证从开发的独立最终阶段转变为核心阶段。
译自 QA's Dead: Where Do We Go From Here?，作者 Kenn Hussey Ambassador Labs。译者最近也与一位资深的测试（许多企业测试属于QA）聊过，感觉测试的定位似乎越来越尴尬。
如果你听取思想领袖的意见，QA 正在走向死亡。它毫无用处，它很昂贵，而且，我们现在有机器可以做这件事。根据我自己的经验，我已经在没有专门 QA 团队的组织中工作了几年，我认为世界其他地方终于赶上了。
如果我们对“QA 正在消亡吗？”这个问题采用贝特里奇(Betteridge)标题定律的方法，不可避免的答案是否定的。QA 并没有消亡；它已经死了。这种死亡已经对 QA 团队产生了巨大的影响。然而，转型已经发生，最终提高了软件开发生命周期中质量的重要性。
我所说的转型是指质量保证从开发的独立最终阶段转变为软件创建的核心阶段，每个开发人员都期望拆解自己的代码以构建更好的产品。如果你还没有接受这种转变，我有一个坏消息要告诉你。
传统的 QA 是这样的：
- 设计：PM、架构师和开发人员定义产品需求并设计初始架构。
- 开发：开发人员根据需求和设计编写代码。
- 测试：QA 团队接收完成的代码，创建测试计划和用例，并执行手动/自动化测试以涵盖各种场景。他们将错误报告回开发团队。
- 错误修复：开发人员接收错误报告，修复问题，并将代码传递回 QA。
- 重新测试：QA 验证修复并可能执行另一轮回归测试。
- 发布：一旦 QA 批准，软件将进入生产。
这种分隔的模型几十年来一直是软件开发的标准，但它已成为“扔过墙”心态的代名词。编码人员编码，测试人员测试。但是，当像这样列出来时，它很快就会清楚地表明问题是什么：
首先，每个人都被孤立了。开发和测试团队独立工作，导致沟通差距和期望不一致。这种分隔可能会导致一个很棒的产品，但会产生巨大的开销。
其次，开发过程发生在任何实质性测试开始之前。这种后期错误发现可能效率更高。在开发周期早期发现的错误通常更容易修复且成本更低。然而，这种模型将错误检测推迟到最后，增加了开发的总成本和时间。
第三，测试和错误修复之间的循环造成了严重的瓶颈。当发现错误时，它们会被返回给开发人员，修复，然后返回给 QA 进行重新测试。这种来回非常耗时，可能会延迟发布，尤其是在流程后期发现了重大问题。
在这个框架中，你会得到更慢的开发周期、更高的成本和潜在的质量问题。所有这些都源于一个问题：在整个过程中需要更多地拥有质量。
过去，QA 团队是组织中质量的仲裁者。现在，这种责任已经转移到了开发人员身上。这种转变不仅仅是一个小的调整；它是对软件质量方法的根本性重构。
我们上面提到的线性过程已转变为构建、测试、重建和推送到生产的循环过程：
所有这些都发生在上面的开发框内。开发人员现在是质量控制的第一道防线。
这可以通过两项举措实现。
首先，迭代开发。敏捷方法意味着团队现在以短周期工作，更频繁地交付功能性软件。这允许持续测试和反馈，在流程早期发现问题。这也意味着质量不再是最终的检查点，而是在整个开发周期中持续考虑的因素。
其次，工具。自动化测试框架、CI/CD 流水线和代码质量工具使开发人员能够承担更多质量控制责任，而不会冒倦怠的风险。这些工具允许对代码质量进行即时反馈，对每次提交进行自动化测试，并将质量检查集成到开发工作流程中。
在实践中，这看起来像什么？
让我们以全栈 API 开发为例。单个开发人员现在可以利用自动化大部分样板工作的工具，并提供即时反馈。例如，这些工具使开发人员能够执行以下操作：
- API 设计：开发人员现在可以快速创建标准化的 OpenAPI 规范。这使他们能够几乎立即开始编码，而无需花费整个冲刺来构建初始设计。
- API 模拟：借助合适的工具，开发人员可以创建动态、可共享的模拟。这消除了手动编写和维护模拟代码的需要，从而实现快速验证和迭代。
- 代码生成：AI 驱动的代码生成工具现在可以处理客户端和服务器端 API 的大部分样板代码。这使开发人员能够专注于 API 实现的独特方面。
- 测试和调试：现代平台提供公开可用的 URL 用于测试，使开发人员能够在类似生产的环境中运行其代码。这些直接与 IDE 集成，使开发人员能够设置断点并有效地调试，最大限度地减少错误进入生产环境的可能性。
- 部署：现在存在提供托管的、容器化的测试环境的工具。这允许轻松进行渐进式和重复测试，而无需不断重新配置。
这些只是开发人员现在可以处理 API 开发和测试的许多方面的进步，这些方面以前是孤立的，或者需要与其他团队进行大量来回沟通。
这种转变并没有消除对专业 QA 知识的需求。相反，它将质量考虑因素整合到整个开发过程中，开发人员承担了更多责任，从一开始就确保其 API 的质量。
这会让 QA 变得怎样？
没有家了吗？有点，但也不完全是！更准确地说，他们现在有了多个家。QA 可以变得更具战略性或更具技术性，向上或向下移动堆栈。
第一个机会是向下移动堆栈，进入更技术性的角色。QA 专业人员可以利用他们以质量为中心的思维方式成为自动化专家或 DevOps 工程师。他们在全面测试方面的专业知识对于开发健壮、可靠的自动化测试套件至关重要。 “不稳定的测试比没有测试更糟糕”的概念在测试是阻止组织发布低质量代码的唯一手段时变得更加重要。
QA 擅长识别边缘情况和潜在的故障点，这使得他们在创建全面的测试覆盖范围方面非常宝贵，而不仅仅是基本的正常路径场景。这种严格性可以平衡快速开发环境中的任何 YOLO 驱动的开发。
第二个机会是向上移动堆栈，进入战略性角色。测试现在是开发生命周期中不可或缺的一部分，它需要思考。QA 专业人员可以发展成为质量策略师，专注于设计涵盖整个软件生命周期的全面测试策略。
QA 团队已经消失，但质量工程的思维方式将永远需要。这种思维方式现在已经从特定的团队转变为融入每个从事产品开发的开发人员。组织现在必须找到方法，通过为他们提供生产高质量软件所需的工具和支持，来利用这种思维方式。
QA 的“消亡”最终不是关于它的消亡，而是关于它融入软件开发的各个方面。组织面临的挑战将是培养一种文化，在这种文化中，质量是每个人的责任，同时仍然重视和利用 QA 专业人员带来的专业技能。利用可以提供 QA 检查的工具，并赋予您自己的开发人员每个人都戴上自己的 QA 帽子。