现代质量保证工程师的实际工作内容：远不止是发现漏洞而已

如果你问别人QA工程师是做什么的，你很可能会听到这样一个熟悉的答案：“他们负责测试软件并找出其中的缺陷。”

这种看法非常普遍，而且公平地说，找出缺陷确实是QA工作的重要组成部分。但如果你在现代软件团队中工作几周，你就会很快意识到，这其实只是QA工程师实际工作内容的很小一部分。

在过去十年里，软件开发发生了巨大的变化。各个开发团队不再需要等待数月才能发布新功能；许多机构甚至每周、每天，甚至是每天多次进行系统更新。应用程序已经变得越来越复杂，云服务、API、微服务、移动应用以及第三方集成组件都在幕后共同发挥作用。

随着软件的发展，QA的角色也在不断演变。

如今的QA工程师会在某个功能开始进入测试阶段之前就参与其中。他们协助审查需求文档，识别潜在风险，明确业务目标，验证API和数据库的稳定性，自动化重复性测试，排查生产环境中的问题，并在整个开发生命周期中与开发人员紧密合作。

换句话说，QA的工作并不仅仅是在软件开发完成后寻找存在的问题，更重要的是要帮助预防这些问题的发生。

无论你是想成为一名QA工程师，想要从手工测试转向自动化测试，还是仅仅对现代质量保障工作的内容感到好奇，了解这一职业角色是如何变化的，都是非常重要的第一步。

在本文中，我们将探讨QA工程师实际负责的工作内容，了解这一职业为何会发生变化，以及在当今这个发展速度极快的环境中，哪些技能对于开发可靠的软件来说是必不可少的。

QA角色的变化

过去，许多软件开发团队都遵循着一种简单的工作流程：业务分析师负责收集需求信息，开发人员负责编写代码，当开发工作完成后，软件就会交给QA团队进行测试。如果发现了缺陷，应用程序会重新回到开发团队手中，经过修改后再进行最终发布。

在那种模式下，质量保证工作通常被视为发布前的最后一个环节。测试工作往往是在大多数重要的技术决策已经确定之后才进行的。

当软件发布的频率仅为每年几次时，这种做法效果还算不错。团队有足够的时间完成开发工作，进行数周的手动测试，修复缺陷，然后为预定的发布做好准备。

然而如今的软件开发情况已经发生了很大的变化。

许多组织开始采用敏捷开发方法、持续集成以及持续交付机制。团队不再每隔几个月才发布一次软件，而是通过短周期的开发流程不断添加新功能、修复漏洞，并及时推出改进版本。

由于开发速度大大加快，质量已经不能再被视为项目的最后一个环节了。

如今，质量保证工程师从项目开发的最初阶段就开始与开发人员、产品负责人、业务分析师、用户体验设计师以及DevOps工程师一起合作。他们参与冲刺计划的制定，审查用户需求文档，讨论验收标准，识别潜在风险，并确保在新功能的设计阶段就充分考虑测试的需求。

这种转变使得质量保证的工作重点从“对已完成的软件进行测试”转变为“帮助团队从项目一开始就确保软件的质量”。

举个例子，假设某个团队正在开发一款在线银行应用程序，允许客户在不同的账户之间转账。采用传统的测试方法，可能会等到该功能开发完成后才去验证转账操作是否能够成功。

而经验丰富的质量保证工程师则会提前考虑许多问题，例如：

如果在转账过程中网络连接中断，会发生什么？
如果客户的账户余额不足，系统应该如何处理？
是否有可能不小心提交两次相同的转账请求？
如果接收银行暂时无法正常运行，应用程序应该如何响应？

这类问题有助于在开发人员开始编写代码之前发现潜在的问题。及早处理这些隐患通常比在测试阶段或软件发布后才发现问题要节省很多时间和成本。

正是由于这个原因，质量保证的工作职能已经发生了根本性的变化——它不再仅仅是专注于测试的一个环节，而是贯穿整个软件开发生命周期的重要部分。

质量不再是在项目结束时才进行检验的东西，而是一个需要整个团队共同努力、一步步逐步打造的成果。

传统开发模式

需求分析 -> 开发 -> 质量保证测试 -> 发布

现代开发模式

需求分析 -> 开发+质量保证+产品负责人协作 -> 持续开发 -> 持续测试 -> 发布

良好的测试工作应在第一个测试用例编写之前就开始了

对于那些刚开始从事软件测试工作的人来说，最大的意外之一就是会发现：质量保证工程师的大量工作其实是在编写任何一个测试用例之前就已经开始了。

很多人认为测试工作只有在开发人员完成某个功能的实现之后才开始。但实际上，经验丰富的质量保证工程师会早在这个阶段就参与进来，因为只有在这个时候，他们才能发挥出最大的作用。

以这样一个简单的需求为例：

用户必须创建一个至少由八个字符组成的密码。

乍一看，这个需求似乎非常明确。开发人员可以据此进行实现，测试人员也可以验证长度小于八个字符的密码是否会被系统拒绝。

但软件需求很少会如此简单明了。

质量保证工程师会自然地深入思考一些细节，他们会提出这样的问题：

空格是否应该被计入字符数量中？还是说前导或尾随的空格应该被自动去除？
密码是否有长度上限？
是否需要使用特殊字符或Unicode字符？
这个验证规则是同时适用于网页应用还是移动应用？
如果密码无效，用户应该看到什么样的错误提示信息？

提出这些问题的目的并不是为了找出开发人员所犯的错误，而是为了确保整个团队对这一功能的实现方式有相同的理解，这样开发工作才能顺利推进。

这个过程通常被称为“需求澄清”，这也是质量保证工程师能够做出的最有价值的工作之一。

如果没有进行这样的讨论，开发人员可能会按照自己的理解来实现这一需求，而测试人员则会发现与之不同的结果；业务相关方也可能会有完全不同的期望。即使所有人都付出了努力，不清晰的需求仍然会导致不必要的缺陷、返工和麻烦。

尽早提出这些有深度的问题，有助于避免这类情况的发生，同时也能节省时间。

在规划阶段发现需求不明确，通常只需要几分钟就能解决；而如果在开发、测试和部署之后才发现同样的问题，那么可能需要花费数小时甚至数天的时间来调查和修复。

优秀的质量保证工作并不仅仅是为了验证软件是否能够正常运行，更重要的是要确保团队从一开始就在构建正确的软件产品。

实际案例

想象一下，有一个提供折扣优惠券的在线购物网站。

现代的质量保证工作并不仅仅是自动化

如果你浏览招聘信息中关于质量保证工程师的职位描述，你很可能会立刻注意到一点：

许多职位描述都会提到诸如Selenium、Plawright、Cypress、Appium、Javascript、Java、Python等自动化工具——这样的清单还可以继续列举下去。

因此，人们很容易认为质量保证工程师整天都在编写自动化测试脚本。当然，自动化确实是这项工作的重要组成部分，但它并不是全部内容。

以一款外卖应用新增功能为例：现在顾客可以保存多个收货地址，在结账时选择其中一个。但在任何自动化测试脚本被编写之前，质量保证工程师就已经开始参与相关工作了。

他们会仔细研究需求文档，了解这项功能应该如何实现；还会与开发人员和产品负责人讨论各种可能的情况，比如如果顾客删除了默认地址或输入了无效的邮政编码，系统应该怎么做。他们会识别出在规划阶段可能被忽略的特殊情况，并思考这项新功能如何与现有系统功能协同工作。

只有在这些讨论完成之后，他们才会开始设计测试用例。

其中一些测试最终可能会被自动化处理，尤其是那些会在未来的回归测试中使用的测试；而另外一些测试则更适合采用探索性测试的方法，因为这些测试需要人类的观察和判断。

质量保证工程师会根据他们所要解决的问题来选择合适的测试方法，而不是试图将所有事情都自动化。

一名质量保证工程师一周的工作内容通常会包括以下几项任务：

在开发开始之前审阅新的功能需求。
设计功能测试用例以及针对特殊情况的测试方案。
使用Postman或Bruno等工具验证REST API的响应结果。
通过SQL查询来检查后端数据是否正确。
构建或维护自动化回归测试脚本。
调查生产环境中出现的各种问题。
与开发人员合作，重现并分析缺陷产生的原因。
在软件发布之前确认所有的错误都已经得到修复。

有些周的工作会更多地涉及自动化测试，而有些周则会侧重于问题调查、团队协作或探索性测试。

这就是为什么质量保证工程是一个如此多样化的领域的原因之一：没有两个项目是完全相同的，工作内容也会根据产品类型、开发团队以及所处的开发阶段而有所不同。

自动化工具能够帮助质量保证工程师减少重复性工作的时间，使他们能够将精力集中在那些需要运用批判性思维来完成的任务上。

它是一种支持质量保证工作的工具——而非质量保证本身的定义或核心要素。

不同类型的测试适用于哪些场景

另一个常见的误解是认为质量保证工程师只负责测试用户界面。实际上，软件可以在许多不同的层面进行测试。

例如：

测试类型	目的
用户界面测试	验证用户能否顺利与应用程序进行交互。
API测试	确认各服务之间的通信是否正常，以及它们是否能返回预期的响应结果。
数据库测试	验证数据是否能够被正确地存储、更新和检索。
回归测试	确保新的变更没有破坏现有的功能。
探索性测试	通过人类的观察与创造力来发现潜在的问题。
性能测试	评估应用程序在不同工作负载下的运行表现。

质量保证工程师并不一定每天都会进行所有这些类型的测试，但了解每种测试方法在什么情况下以及为什么有用，可以帮助他们在不同情境下选择合适的策略。

质量的保障并非依赖于某一种测试技术，而是通过结合多种测试方法来确保软件在现实环境中能够正常运行。

一张流程图，展示了新软件功能是如何经过用户界面测试、API测试和数据库测试，然后再进行回归测试，最终投入生产环境的

每位质量保证工程师都应该掌握的技能

如果你刚刚开始从事质量保证工作，很容易就会把重点放在学习具体的工具上。虽然这些工具确实很重要，但它们只是整个工作中的一部分。最成功的质量保证工程师通常会同时具备技术能力、解决问题的能力以及有效的沟通技巧。

以下是一些能够帮助你在质量保证领域取得进步的核心技能：

技能	重要性
沟通能力	有助于明确需求、解释缺陷，并与团队有效协作。
批判性思维	能够识别那些看似不明显的问题或风险。
API测试	验证应用程序之间的交互机制，确保后端服务正常运行。
SQL技能	确认数据能否在数据库中被正确存储、更新和检索。
测试自动化	减少重复性测试工作，提高回归测试的效率。
持续集成/持续交付知识	有助于将测试流程融入现代的软件发布流程中。
持续学习	随着工具、技术和开发方法的不断发展，持续学习是保持技能更新的关键。

我们没有必要在一夜之间掌握所有这些技能。最重要的是打下坚实的基础，保持好奇心，并随着行业的发展不断学习。

关于质量保证的常见误解

如果你是软件测试领域的新人，那么你可能已经听说过其中一些说法。虽然这些观点听起来似乎合情合理，但实际上它们并不能反映现代质量保证团队的工作方式。

误区：质量保证工程师只负责发现漏洞

事实：发现漏洞仅仅是质量保证工作的一部分。质量保证工程师还需要审查需求文档、识别潜在风险、设计测试策略、自动化重复性测试、验证API和数据库的功能，并帮助团队在软件交付给用户之前防止出现缺陷。

误区：自动化会取代质量保证工程师

事实：自动化只是一种工具，它无法替代人类的思考能力。自动化测试可以执行重复性任务，但它们无法决定应该测试哪些内容、也无法理解那些模糊不清的需求要求，更无法评估某个功能是否能够提供良好的用户体验。

误区：质量保证工作就是负责确保质量

事实：质量保障是整个团队共同的责任。开发人员需要编写可靠的代码，产品负责人需要明确需求规格，设计师要关注产品的可用性，DevOps工程师要构建可靠的部署流程，而质量保证工程师则要确保所有这些环节能够协同运作，从而达到预期的质量标准。

误区：手动测试已经不再有用

事实：自动化测试在处理重复性的回归测试时确实非常有效，但手动测试在探索性测试、可用性验证以及排查异常行为方面仍然具有不可替代的价值。这两种测试方法实际上是相辅相成的，而不是互相竞争的。

误区：质量保证工作比软件开发更容易

事实：现代的质量保证工作需要强大的分析能力、扎实的技术知识、良好的沟通技巧，以及对软件系统运行原理的深入理解。虽然质量保证工程师和软件开发人员的职责有所不同，但他们在确保软件质量这一目标上扮演着同样重要的角色。

如果你正在考虑从事质量保证工作

如果你想成为一名质量保证工程师，即使现在还不知道所有的测试工具或自动化框架，也无需担心。每一位经验丰富的质量保证专家都是从学习基础知识开始的。

首先，你需要了解软件的工作原理——比如Web应用程序是如何与API进行交互的，数据又是如何存储在数据库中的，以及不同的系统组件是如何协同工作来实现某个功能的。掌握这些基础知识后，你才能真正理解自己为什么要进行测试，而不仅仅是知道该用什么样的方法来进行测试。

同时，要学会站在用户的角度来思考。要多提出问题，探索各种不同的情况，并且不要只关注那些“理想的发展路径”。有些非常有价值的缺陷，正是由于有人提出了这样的疑问——“如果事情没有按照预期的方式发展，会怎么样？”才被发现的。

随着你的成长，逐步掌握诸如SQL、API测试、自动化开发、版本控制以及持续集成/持续部署等技术技能。要注重持续学习，一次专注提升一项技能。

最重要的是，请记住：软件质量绝不是由某一个人或某个团队单独创造的。优秀的质量保障工程师会与他人协作，有效沟通，共同助力打造更优质的软件。

总结

软件测试已经发生了巨大的变化——它不再被视为发布前的最后环节。

如今的质检工程师会在整个软件开发生命周期中发挥重要作用：他们会提出富有洞察力的问题，明确需求，自动化执行重复性测试，验证API和数据库的功能，排查生产环境中的问题，并帮助团队自信地交付可靠的软件产品。

发现漏洞始终是质量保障工作的重要组成部分，但这已不再是衡量一名优秀质检工程师的标准。

真正决定其价值的是：能够在问题发生之前就加以预防，能够深入思考软件的使用方式，并能与整个团队携手合作，共同打造更好的产品。

如果你刚刚开始从事质量保障工作，不要用自己掌握了多少测试工具来衡量自己的进步。应该专注于夯实基础知识，保持求知欲，不断提升解决问题的能力。

技术会不断发展变化，但这些品质永远都具有价值。