QA 工程师
QA 工程师把质量当作一门学科来承担，而不是当作冲刺末尾的一道检查关口。这项工作始于在任何东西被构建之前质疑需求，经过判断究竟哪些地方值得测试，最终落在一个站得住脚的结论上：这个版本是否适合交到用户手里。本指南说明这项工作的范围、让它变得必要的那些压力，以及它如何与开发团队衔接。
QA 工程师做什么？
QA 工程师研究一个软件产品可能以哪些方式失效，并确保团队比它的用户更早知道这些失效。工作范围包括：在开发开始之前审阅需求与验收标准中的歧义；围绕风险真正所在的位置设计测试；通过探索产品发现任何既定用例都不会去找的问题；把缺陷描述得足够清楚，使它能被正确理解并被正确排序；以及就一个版本是否已经可以发布给出意见。这从根本上是一个依赖判断力的角色：其决定性的技能在于，在可用的时间之内判断什么值得投入注意力，什么不值得。
这份工作最难的部分是做减法。穷尽式测试不只是不切实际，在算术上就是不可能的——一个有十个字段、每个字段各有若干合法状态的表单，产生的组合数就超过任何团队一辈子能够执行的量。因此每一个测试决策都是一次投入分配决策，两个人可以执行同样数量的用例，产出的信息量却完全不同。这也是为什么“全覆盖”是一个糟糕的目标：代码覆盖率记录的是测试运行时哪些代码行被执行过，而不是由此产生的行为是否正确、断言是否有意义，更不是需求本身一开始是否就是对的。
价值最高的工作，很大一部分发生在代码存在之前。缺陷绝大多数源自理解偏差而不是敲错字母——一条没有说明输入为空时会发生什么的验收标准、一条被两个人读出两种含义的业务规则、一个从未讨论过失败行为的集成。在规格还在书写阶段就追问边界上会发生什么，等于消除掉一个原本要经历发现、上报、分级、修复、评审、回归的缺陷。找出缺陷是这个角色可见的那一半；预防缺陷是更有价值的那一半，而它基本上是不可见的——正因如此，它必须被明确地认可为这份工作的一部分。
围绕这个角色，存在一个反复出现的组织陷阱。当质量被当作一个部门、而不是团队共同承担的属性时，QA 就变成了一道把工作扔过去的关卡：工程师因为反正有别人会测而测得更随意，未经验证的工作在每个冲刺末尾堆积，本应改善质量的人则把时间花在处理队列上。有效的安排恰恰相反——提升整个团队的测试能力，让风险尽早可见，并去做其他人没有时间、也没有那种思维方式去做的探索与分析。
团队在什么时候需要这项能力
大多数团队在一段时间里都能把自己的工作测得够用。以下这些压力，通常会暴露出这种安排的边界。
逃逸的缺陷总能追溯回需求
上线后出现的问题，查下去并不是编码错误，而是对本应发生什么的理解不一致。在需求进入冲刺之前，没有人去审问其中的歧义，于是同一个理解偏差，在整个周期里代价最高的那一点上被反复发现。
没有人说得清一个版本是否可以安全发布
这个决定靠的是感觉、靠流水线是不是绿的，或者靠站会上谁听起来最有把握。事后一旦出问题，没有任何记录说明当时哪些是已知的、哪些是假设的，于是下一个版本还会再讨论一遍同样的话题。
故障集中出现在功能与功能的交界处
每个功能单独看都正常，问题出现在它们的相互作用里——一次权限改动改变了导出的内容，一项货币设置到达了一个界面却没有到达另一个。工程师测试自己的工作时很少跨过这些边界，因为边界不属于任何人。
缺陷报告的成本已经超过缺陷本身
报告送过来时没有复现步骤、没有环境信息、没有实际结果与预期结果的对照，有时甚至连这个行为是不是错的都没有共识。工程师把相当一部分时间花在还原报告上，而不是修复报告所描述的问题。
产品需要承担的不只是功能正确
无障碍合规、法规要求、数据处理规则或者合同中的服务承诺，构成了一类功能测试不会去寻找的失效，而开发者在构建过程中也不处在能够注意到它们的位置上。
团队始终只是在确认自己的预期
人们测试的是自己打算构建的东西。这是认知上的限制，而不是纪律问题，也正因如此，一位工程师可以把自己的工作测得很彻底，却仍然漏掉那个他从未设想过的情况。而一个职业习惯就是寻找意外的人，找到的是完全另一类缺陷。
核心能力
风险分析
判断产品的哪些部分一旦损坏损失最大、各自出问题的可能性有多高，并据此分配投入。这既依赖对软件的理解，也依赖对业务的理解——技术上最脆弱的组件和商业上最关键的组件，往往并不是同一个。
测试策略
决定哪些由自动化检查、哪些由人来检验、哪些通过生产环境的监控来验证，以及哪些是明知而有意不测的。一份不说明什么不会被测试的策略，是愿望清单而不是计划。
需求与验收标准分析
从一份规格里读出它没有说出来的部分：缺失的边界条件、未定义的错误行为、关于顺序或状态的隐含假设，以及两个读者会解释出两种含义的规则。这个阶段提出的问题是在消除缺陷，而不是在检测缺陷。
测试设计方法
运用等价类划分、边界值分析、判定表、状态迁移建模和成对组合，把一个不可能穷尽的输入空间收敛成一组说得出理由的用例。这正是“论证出来的覆盖”与“声称的覆盖”之间的区别。
探索性测试
一种有结构的调查：设计、执行与学习同时发生，通常组织成带有明确 charter 的限时会话。做得好的时候它是有纪律、有记录的，并且能找到预设脚本找不到的缺陷，因为一份脚本只会去找已经有人想到过的东西。
缺陷报告与推动
写出一份陌生人也能复现的报告，然后论证这个问题为什么重要。推动是被低估的那一半：一个报告本身正确、却被填了错误的严重级别，或者其描述方式掩盖了对用户的影响，它就会被悄无声息地降低优先级，然后随版本发布出去。
分级与严重程度判断
把严重程度与优先级区分开，识别出多份报告其实指向同一个根因，并挑出那些看起来只是外观问题、实则暗示结构性错误的报告。可靠的分级让缺陷待办保持为一件决策工具，而不是一片坟场。
发布就绪判断
把已知的和未知的整理成一个决策者可以据以行动的陈述：哪些风险被检视过、哪些被接受了、哪些没有被覆盖，以及部署之后应当观察什么。这个角色的职责是用证据为发布决策提供依据，而不是握有否决权。
可用性与无障碍观察
注意到那些技术上正确、实际上不对的行为——一个没有二次确认的破坏性操作、一条没有告诉用户任何可执行信息的错误提示、一条无法只用键盘完成的流程。专业审计自成一个领域，但相当一部分问题在审计人员看到之前就已经被发现了。
领域理解
知道这个软件是为什么而存在、谁在依赖它。领域知识能把“总额和我预期的不一样”变成“对发往第二个税收辖区的订单，这里的税额舍入方向错了”，而它通常也是一位 QA 工程师手上增值最快的资产。
技术生态
以下列出软件质量保障领域常见的技术。这描述的是该学科在业界的一般实践，而不是对任何特定工程师技术栈的说明。在这个角色里，工具的重要性低于多数工程岗位，因为工作的实质是分析与判断，而不是操作某一款特定产品。
测试管理与跟踪
- Jira
- TestRail
- Xray
- Zephyr
- Azure Test Plans
检查与探索
- Browser developer tools
- Postman
- Charles Proxy
- Fiddler
- SQL clients
- Feature flag consoles
规格与协作
- Gherkin
- Example mapping
- Confluence
- Notion
- Miro
无障碍与可用性检查
- axe DevTools
- WAVE
- NVDA
- VoiceOver
- Lighthouse
生产环境信号
- Sentry
- Datadog
- Grafana
- Kibana
- Session replay tools
设备与平台覆盖
- BrowserStack
- Sauce Labs
- Xcode Simulator
- Android Emulator
这个角色如何与您的团队协作
工程师在您的团队内部工作，遵循您的优先级和标准。日常开发方向由您掌握，Talent.ID 负责雇佣关系。下面的分工就是全部安排。
由您掌握
- 产品
- 业务优先级
- 路线图
- 架构
- 冲刺优先级
- 工程标准
- 日常技术协作
由 Talent.ID 负责
- 雇佣关系
- 薪资发放
- 员工福利
- 人才管理
- 持续的员工关系
实际协作大致是这样
这是一个假设场景，用于说明协作方式如何落地。它并不描述 Talent.ID 的客户或已完成的项目。
- 挑战
- 某个团队正在转向更高频的发布节奏，却发现自己的质量流程撑不住这个变化。验证一直集中在每个周期的末尾进行，缺陷浮现得太晚、来不及在不推迟日期的前提下修复，而在部署之前，也没有人能向产品负责人清楚地说明哪些已经检查过、哪些还没有。
- 做法
- 新增的质量力量在团队已有的交付流程之内工作——他们的工单流转方式、他们的完成定义、他们的发布节奏和他们的质量标准。客户的工程师与产品负责人继续决定优先级、也继续决定发布什么；新增的力量与他们并行地承担风险分析、测试设计和探索性测试，而不是作为工作必须经过的一个独立环节来运作。
- 为团队带来什么
- 团队在保有产品决策权和工程标准的前提下，扩展了自己在质量方面的投入能力。什么算作可以发布，始终由客户来判断。
相关领域
常见问题
- QA 工程师和测试自动化工程师有什么区别？
- QA 工程师对质量这门学科负责：哪些风险重要、规格里有哪些没有定义清楚的地方、有哪些是既定脚本永远不会去找的、以及一个版本是否应该发布出去。测试自动化工程师则对自动化测试系统本身负责——框架设计、测试数据、环境控制、让结果保持确定性，以及让执行速度快到值得等待。前者由判断力的广度定义；后者是一个工程角色，其交付物就是这套测试。两者是互补关系，而不是可以互换：一套在缺少质量判断的情况下建起来的测试，会非常可靠地检查错误的东西。
- QA 工程师需要写代码吗？
- 需要到足以把工作做好的程度，而这通常低于招聘广告所暗示的水平。能读代码库、能查数据库、能直接调用 API、能顺着堆栈跟踪往下看、能检查网络请求，都会明显提升工作的质量。构建并维护一套自动化框架是另一份工作，重心也不一样；在 QA 岗位上要求很强的编程能力，往往会把这个角色最依赖的分析型和沟通型候选人筛掉。
- 配备 QA 工程师会拖慢团队吗？
- 当质量被安排成一道关卡时会：工作完成、交接、排队、退回、返工，交接本身成了约束条件。而当 QA 工程师从需求书写阶段就参与进来时，通常不会，因为那些从未被构建出来的缺陷，正是原本最耗时间的那些。如果增加质量投入之后团队反而变慢了，原因通常在安排方式，而不在人。
- 开发者自己测自己的工作，不就够了吗？
- 他们应该测，但这本身并不够。开发者测试自己的工作，验证的是它是否做了自己想让它做的事，这就让那些他们从未考虑过的情况完全没有被触及——而且再怎么认真也无法完全消除这个限制，因为它是“亲手构建过这个东西”所带来的固有属性。QA 工程师带来的是一个关于软件应该做什么的独立模型，以及一套面向意外而不是面向预期的习惯。
- QA 应该汇报给工程线，还是作为一个独立职能存在？
- 把 QA 工程师嵌入交付团队通常效果更好，因为近距离才让预防成为可能，而距离会把质量变成一次交接。一条独立的汇报线在较大的组织里有助于维持专业标准，但当质量保障变成一个只接收成品的独立部门时，那个熟悉的失效就会随之而来：工程师测得更随意，队列越排越长，质量则变成团队以为自己已经交给别人负责的事情。
- 质量工作需要什么资历水平？
- 这取决于有多少事情尚未确定。针对规格明确的功能执行一套已经确立的做法，中级水平就可以做好。而要确立一个团队究竟应该测什么、与产品负责人协商风险，或者在没有质量实践的地方从头建立一套，则需要见过这些决策在较长时间里如何演变的人——在这里，判断力不足的代价要到几个月之后才显现，形式是这个团队不再注意到的那些东西。
- QA 工程师如何与现有的工程团队协作？
- 加入您团队的 QA 工程师遵循您既有的交付流程——您的工作流、您的完成定义、您的工程标准和您的发布节奏。这是一种技术团队扩展的安排，因此日常优先级、产品方向以及是否发布的决定，都仍然属于您。Talent.ID 负责雇佣关系、薪资发放和员工福利，以及人才管理和持续的员工关系。
告诉我们您的团队需要什么
描述一下缺口——工作内容、技术栈、团队的运作方式——我们会告诉您能支持到什么程度。如果这不是我们能帮上忙的事情，我们会直说。