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
How this role works with your team
Engineers work inside your team, on your priorities, to your standards. You direct the work; Talent.ID carries the employment. The division below is the whole arrangement.
You keep
- 产品
- 业务优先级
- 路线图
- 架构
- 冲刺优先级
- 工程标准
- 日常技术协作
Talent.ID handles
- 雇佣关系
- 薪资发放
- 员工福利
- 人才管理
- 持续的员工关系
招聘时应该关注什么
QA 候选人常常被放在错误的坐标轴上评估。工具熟悉度和证书容易核实，预测力却很弱；把一位出色的 QA 工程师与一位称职的 QA 工程师区分开的，是分析能力与沟通能力，而这些只有在您追问具体细节时才会显露出来。
风险推理
给出一个产品领域，问他们会先测什么、又会放着不测什么。回答会暴露他们是按后果与可能性来思考，还是按“把能看到的都覆盖一遍”来思考。说不出任何一项自己会有意不测的候选人，通常没有在真正的截止日期下工作过。
- 能区分“容易出问题的”和“一旦出问题代价很大的”
- 在提出测试方案之前，先问用户、交易金额或合规暴露面
- 能说出一个自己接受了的风险，并解释他们如何让别人也看见它
需求审问
交给他们一条简短、且刻意不完整的验收标准，看他们会问什么。这是这个角色最有信息量的一项练习，因为它的回报集中在预防上，而这项技能无法在现场临时伪装。
- 直接切入边界、空输入和失败行为
- 关注这条标准没有说什么，而不只是核对它说了什么
- 提问的方式让编写者觉得有帮助，而不是觉得被针对
探索性测试能力
请他们详细描述一次会话：他们打算弄清楚什么、在什么都没浮现时如何调整方法、以及记录了什么。弱一些的候选人描述的是四处点击；强的候选人描述的是一套有目的的方法，以及一份关于覆盖了什么的记录。
- 从一个 charter 或一个明确的问题出发，而不是泛泛地看一遍
- 能说明某一个观察如何改变了这次会话余下的方向
- 留下的笔记是另一个人可以据以行动的
缺陷沟通
请他们讲一个自己不得不为之争取的缺陷，以及一个自己决定不提的缺陷。前者显示他们能否把影响讲给没有在看这个软件的人听懂；后者显示他们是在运用判断力，还是把注意到的一切都记成单。
- 描述用户影响或商业影响，而不只是描述错误的行为
- 把严重程度和优先级分开，并且不把这个区分当作学术讨论
- 曾经因为证据而改变对某个缺陷的看法，而不是靠反复坚持
发布判断
问他们在还有问题没有解决时，会如何就是否发布给出建议。这能看出他们把这个角色理解为一道关卡，还是一个信息来源。一个把残余风险讲清楚、然后让负责的人来决定的人，比一个直接卡住、或者一路放行的人更有用。
- 在报告已验证内容的同时，也报告仍然未知的部分
- 把发布后的监控作为继续做发布前测试的替代方案提出来
- 不把一个未关闭的缺陷自动视为不可发布
与工程师的关系
质量工作一旦变成对立关系就会失败。问他们如何处理过与开发者的分歧，以及他们如何帮助团队把自己的工作测得更好。一个能把所有人的标准都提上去的人，价值远高于一个自己找到更多缺陷的人。
- 谈的是提升团队的测试能力，而不只是自己的产出
- 在实现之前就参与进来，而不是等到交接之后
- 能就一个缺陷持不同意见，而不让它变成立场之争
对产品的好奇心
最有诊断价值的问题，往往就是这个产品做什么、谁在用它。理解领域的候选人会用对用户的后果来描述测试；不理解的候选人会用界面和按钮来描述。这两种回答之间的差距既大又稳定。
- 先解释上一个产品是为什么而存在，再描述自己如何测试它
- 曾把一条领域规则学得足够深，并因此抓到过一个隐蔽的错误
- 会追问某个行为出错时，受到损害的究竟是谁
值得一问的面试问题
以下问题旨在引出推理过程而不是术语，供您自己的面试流程参考，如何使用由您决定。面试每一位候选人、并决定谁加入您团队的是您。
距离发布还有两天，而您可以做的测试远不止两天的量。您怎么决定测什么？
What a strong answer shows
优先级排序对他们是一种练成的习惯，还是临场发挥。好的回答会从变更范围、后果和可能性出发推理，说出自己会有意跳过什么，并描述残余风险将如何被传达出去，而不是被悄悄吸收掉。
这里有一条某个功能的验收标准。在开发开始之前，您会问哪些问题？
What a strong answer shows
预防的本能。留意边界、空值与最大值、并发访问、依赖方失败，以及系统中已有的数据应当如何处理。问题的数量并不重要，重要的是它们是不是那些一经提出就会促成重写的问题。
请讲一个从所有环节都溜过去的缺陷。是什么让它出去的，之后又改变了什么？
What a strong answer shows
他们是把逃逸的缺陷当作系统性问题来分析，还是当作运气不好。最有说服力的回答会指出这个缺陷最早本可以在哪一环被抓住，并描述对那一环的改动，而不是再补一条测试用例。
100% 的测试覆盖率是一个值得追求的目标吗？为什么？
What a strong answer shows
他们是否理解覆盖率衡量的究竟是什么。想要全覆盖的候选人通常没有维护过一套测试；把覆盖率完全否定的候选人，可能根本不用它。好的回答把它当作寻找未测区域的信号，而绝不当作一个需要达成的指标。
一位开发者说您提的缺陷不值得修。您会怎么处理？
What a strong answer shows
推动力与分寸感同时在场。留意那种能用开发者或产品负责人在意的语言重述影响的人，能够接受讲得出理由的决定，并且知道一个分歧在什么时候应该被升级，而不是被重复。
如果要测试一个您并不理解的东西——一个陌生的业务领域，或者一个没有任何文档的功能——您会怎么做？
What a strong answer shows
不确定条件下的方法，而这正是这份工作的常态。好的回答会描述先弄清楚用户是谁、读完现有的一切材料、建立一个关于预期行为的模型，然后拿软件去对照这个模型来测试。
有哪件事是您做了之后提升了质量，但您本人并没有因此找到缺陷的？
What a strong answer shows
他们是否理解这个角色在哪里回报最高。回答可能涉及重写验收标准、引入一次 example mapping 会议，或者改进缺陷分级的方式。只用缺陷数量衡量自己的候选人，往往答不上来。
请描述一次您在仍有问题没有解决的情况下，判断某个版本可以发布的经历。
What a strong answer shows
面对判断而非规则时的自在程度。留意对风险的清晰陈述、这个决定由谁作出、安排了什么监控，以及事后是否复盘过结果。完全不愿意接受任何已知问题，本身就是一个警示信号。
What this looks like in practice
A hypothetical scenario, written to show how the working model applies. It does not describe a Talent.ID client or a completed project.
- Challenge
- 某个团队正在转向更高频的发布节奏，却发现自己的质量流程撑不住这个变化。验证一直集中在每个周期的末尾进行，缺陷浮现得太晚、来不及在不推迟日期的前提下修复，而在部署之前，也没有人能向产品负责人清楚地说明哪些已经检查过、哪些还没有。
- Approach
- 新增的质量力量在团队已有的交付流程之内工作——他们的工单流转方式、他们的完成定义、他们的发布节奏和他们的质量标准。客户的工程师与产品负责人继续决定优先级、也继续决定发布什么；新增的力量与他们并行地承担风险分析、测试设计和探索性测试，而不是作为工作必须经过的一个独立环节来运作。
- What this adds to the team
- 团队在保有产品决策权和工程标准的前提下，扩展了自己在质量方面的投入能力。什么算作可以发布，始终由客户来判断。
Related disciplines
Frequently asked questions
- QA 工程师和测试自动化工程师有什么区别？
- QA 工程师对质量这门学科负责：哪些风险重要、规格里有哪些没有定义清楚的地方、有哪些是既定脚本永远不会去找的、以及一个版本是否应该发布出去。测试自动化工程师则对自动化测试系统本身负责——框架设计、测试数据、环境控制、让结果保持确定性，以及让执行速度快到值得等待。前者由判断力的广度定义；后者是一个工程角色，其交付物就是这套测试。两者是互补关系，而不是可以互换：一套在缺少质量判断的情况下建起来的测试，会非常可靠地检查错误的东西。
- QA 工程师需要写代码吗？
- 需要到足以把工作做好的程度，而这通常低于招聘广告所暗示的水平。能读代码库、能查数据库、能直接调用 API、能顺着堆栈跟踪往下看、能检查网络请求，都会明显提升工作的质量。构建并维护一套自动化框架是另一份工作，重心也不一样；在 QA 岗位上要求很强的编程能力，往往会把这个角色最依赖的分析型和沟通型候选人筛掉。
- 配备 QA 工程师会拖慢团队吗？
- 当质量被安排成一道关卡时会：工作完成、交接、排队、退回、返工，交接本身成了约束条件。而当 QA 工程师从需求书写阶段就参与进来时，通常不会，因为那些从未被构建出来的缺陷，正是原本最耗时间的那些。如果增加质量投入之后团队反而变慢了，原因通常在安排方式，而不在人。
- 开发者自己测自己的工作，不就够了吗？
- 他们应该测，但这本身并不够。开发者测试自己的工作，验证的是它是否做了自己想让它做的事，这就让那些他们从未考虑过的情况完全没有被触及——而且再怎么认真也无法完全消除这个限制，因为它是“亲手构建过这个东西”所带来的固有属性。QA 工程师带来的是一个关于软件应该做什么的独立模型，以及一套面向意外而不是面向预期的习惯。
- QA 应该汇报给工程线，还是作为一个独立职能存在？
- 把 QA 工程师嵌入交付团队通常效果更好，因为近距离才让预防成为可能，而距离会把质量变成一次交接。一条独立的汇报线在较大的组织里有助于维持专业标准，但当质量保障变成一个只接收成品的独立部门时，那个熟悉的失效就会随之而来：工程师测得更随意，队列越排越长，质量则变成团队以为自己已经交给别人负责的事情。
- 质量工作需要什么资历水平？
- 这取决于有多少事情尚未确定。针对规格明确的功能执行一套已经确立的做法，中级水平就可以做好。而要确立一个团队究竟应该测什么、与产品负责人协商风险，或者在没有质量实践的地方从头建立一套，则需要见过这些决策在较长时间里如何演变的人——在这里，判断力不足的代价要到几个月之后才显现，形式是这个团队不再注意到的那些东西。
- QA 工程师如何与现有的工程团队协作？
- 加入您团队的 QA 工程师遵循您既有的交付流程——您的工作流、您的完成定义、您的工程标准和您的发布节奏。这是一种技术团队扩展的安排，因此日常优先级、产品方向以及是否发布的决定，都仍然属于您。Talent.ID 负责雇佣关系、薪资发放和员工福利，以及人才管理和持续的员工关系。
Tell us what your team needs
Describe the gap — the work, the stack, the way your team runs — and we will tell you what we can support. If it is not something we can help with, we will say so.