Quality Assurance Interview Questions that Suck
糟糕的质量保证面试问题

My frustration with QA interview guides
我对质量保证面试指南的不满

I have previously written about the Quality Engineering Interview, a topic I am passionate about. That article, as well as the follow up article Quality Engineering Interview Questions, were written for the Slalom Build publication — where I work. Because of this, I had to tone down my rhetoric and curtail my stronger opinions. Specifically, I removed a whole section that describes how many interview guides found on the internet just plain suck.
我曾写过一篇关于质量工程面试的文章，这是我热衷的一个话题。那篇文章以及后续文章《质量工程面试问题》都是为我工作的《Slalom Build》杂志撰写的。因此，我不得不收敛我的言辞，减少我的强烈观点。具体来说，我删去了一整节描述互联网上许多面试指南如何糟糕的内容。

This is not my work publication, so I’m under no such constraints here. Read on to see why most interview questions suck, why they fail to correctly identify great candidates, and why you don’t want to work for any company that asks them anyway.
这不是我的工作刊物，所以我在这里没有这种限制。请继续阅读，了解为什么大多数面试问题都很糟糕，为什么它们不能正确识别优秀的候选人，以及为什么你无论如何都不想为任何会问这些问题的公司工作。

For the Interviewer — why your questions suck
给面试官--为什么你的问题很烂

This isn’t going to be some long thesis on interviewing so I’ll get right to the point: your interview questions suck because they are asked as trivia challenges and tell you very little about a candidate other than do they know this specific fact.
这不会是一篇关于面试的长篇论文，所以我就直奔主题了：你的面试问题之所以糟糕，是因为这些问题都是作为琐事挑战而提出的，除了能让你了解应聘者是否知道这一具体事实外，几乎不能让你了解应聘者的其他情况。

These questions follow the pattern of “What is the definition / meaning / purpose of X?”, where X is some specific quality related concept. Here’s an example from the first interviewing article returned by a Medium search:
这些问题的模式是 "X 的定义/含义/目的是什么？"，其中 X 是一些与质量相关的具体概念。下面是 Medium 搜索返回的第一篇采访文章中的一个例子：

What is Monkey Testing?
什么是猴子测试？

This question is horrible. What does it tell me? It tells me if the candidate knows the definition of the term ‘monkey testing’, and that’s it.
这个问题太可怕了。它能告诉我什么？它告诉我候选人是否知道 "猴子试验 "一词的定义，仅此而已。

Some problems:
一些问题

1. Great testers might not know about monkey testing
   优秀的测试人员可能不知道猴子测试
2. Great testers might know the concept, but by another name (like… chaos testing, or even resiliency testing)
   优秀的测试人员可能知道这个概念，但知道它的另一个名字（比如......混沌测试，甚至弹性测试）
3. Horrible testers might know the concept well, because they read about it in a blog, but couldn’t implement it if you gave them a thousand years.
   糟糕的测试人员可能很清楚这个概念，因为他们是在博客上读到的，但给他们一千年时间也无法实现。

Now, if this question were given as the starting point to a deep conversation about testing software resiliency, it would be fine. However, the particular article above did not do this — it was a simple “What is X?” question followed by a short two paragraph definition, with the strong implication that as an interviewee, this is what you need to say. I almost puked.
现在，如果这个问题是作为关于测试软件弹性的深入对话的起点，那还不错。然而，上面这篇文章并没有这样做--它只是一个简单的 "什么是 X？"的问题，然后是简短的两段定义，并强烈暗示作为受访者，这就是你需要说的。我差点吐了。

Some additional examples of trivia questions found in interview guides:
面试指南中的其他琐碎问题示例：

What are Quality Control and Quality Assurance? What are the classes of Defects? What is Rapid Application Development? What is DFD (Data Flow Diagram)? Describe the PDCA cycle. What is meant by latent defect?
什么是质量控制和质量保证？ 缺陷分为哪几类？ 什么是快速应用程序开发？ 什么是 DFD（数据流图）？ 描述 PDCA 循环。 什么叫潜在缺陷？

Some trivia questions are even worse, because the topic they address has no universally understood definition or is in some way subjective or contextual. Here’s a few I’d put in that category:
有些琐事问题甚至更糟糕，因为它们所涉及的主题没有普遍理解的定义，或者在某种程度上是主观的或与上下文有关的。以下几个问题就属于这一类：

Distinguish between verification and validation. What are the five dimensions of risk? Define agile testing, and state its importance. What is the difference between bug, defect, and error?
什么是风险的五个方面？ 定义敏捷测试，并说明其重要性。 错误、缺陷和错误之间有什么区别？

The articles that suggest these questions all include a specific, precise, and purportedly “correct” answer, which is asinine. My thoughts on each:
提出这些问题的文章都有一个具体、精确和所谓 "正确 "的答案，这太荒谬了。我对每个问题的看法：

The only time you need to know the difference between verification and validation is for the 30 minutes you happen to be taking an ISTQB certification exam. After that the distinction is utterly useless as nobody uses the precise definition.
只有在参加 ISTQB 认证考试的 30 分钟内，您才需要了解验证和确认之间的区别。在此之后，这种区别就完全没用了，因为没有人会使用准确的定义。

I have been in this industry for 22 years and I have never heard of a definitive list of the five dimensions of risk within software quality. Never. The top answers from a Google search don’t match their list (Schedule, Client, Human Resources, System Assets, Quality), nor do they even match other search results.
我在这个行业工作了 22 年，从来没听说过软件质量风险的五个维度的明确清单。从来没有。谷歌搜索的热门答案与他们的列表（进度、客户、人力资源、系统资产、质量）不符，甚至与其他搜索结果也不符。

Define agile testing? HA! People can’t even agree on the definition of agile.
定义敏捷测试？HA！人们甚至无法就敏捷的定义达成一致。

Bug, defect, and error do have precise definitions within the context of ISTQB, but in most companies these distinctions are rarely used or even known. This is a great question if you are assembling an ISTQB Trivia Team, not so much if you are hiring a software development team.
在 ISTQB 的语境中，错误、缺陷和错误确实有精确的定义，但在大多数公司中，这些区别很少被使用，甚至不为人知。如果您要组建一支 ISTQB Trivia 团队，这是一个很好的问题，但如果您要招聘一支软件开发团队，这个问题就不那么好回答了。

Fixing the Problem
解决问题

All of these questions can be improved by moving from a challenge-response trivia question on a specific term or topic, to a deep conversation on a concept.
所有这些问题都可以通过从关于特定术语或主题的挑战-回答式小问题到关于概念的深度对话来加以改进。

For example:
例如

What are the five dimensions of risk? (Trivia question!)
风险的五个方面是什么？(小问题）

… turns into…
......变成...

What are some ways software projects fail? What role (if any) do you think quality assurance engineers have in averting or mitigating these failures? (An invitation to discuss their understanding and opinion on software quality, risk, the role of a QA withing a team, and many other related topics)
软件项目失败的原因有哪些？您认为质量保证工程师在避免或减轻这些失败方面扮演什么角色（如果有的话）？(邀请大家讨论他们对软件质量、风险、质量保证工程师在团队中的作用以及许多其他相关主题的理解和看法）

Define agile testing (Trivia question!)
定义敏捷测试（小问题）

… turns into…
......变成...

What are some common challenges or frustrations for QAs in development models (like Scrum) that have defined length sprints and a commitment to deliver work every sprint? What are some strategies to deal with these challenges/frustrations? (An invitation to discuss their experience testing software in an agile methodology, the challenges they delt with, how they fixed or wanted to fix them, their thoughts on agile in general and its implications on quality, and on and on…)
在规定了冲刺长度并承诺每个冲刺都要交付工作的开发模式（如 Scrum）中，质量保证有哪些常见的挑战或挫折？应对这些挑战/挫折的策略有哪些？(邀请大家讨论他们在敏捷方法中测试软件的经验、他们遇到的挑战、他们如何解决或希望解决这些问题、他们对敏捷的总体看法及其对质量的影响，等等......）。

Is it horrible have have one or two trivia questions sprinkled into an interview? Absolutely not. Like salt, a small amount is fine, and can even add variety. The problem is that many interview guides found on the internet or browsing on Medium are usually lists of only these trivia questions, each with a short, definite answer. They have titles like “40 QA Interview Questions you MUST know!” or “20 Testing Questions you must answer to get your next QA job!”. Nothing could be further from the truth.
在采访中穿插一两个琐碎的问题很可怕吗？绝对不会。就像放盐一样，少量就好，甚至还能增加多样性。问题是，在互联网上或 Medium 上找到的许多面试指南通常只列出了这些琐碎的问题，每个问题都有一个简短而明确的答案。它们的标题是 "你必须知道的 40 个质量保证面试问题！"或 "你必须回答的 20 个测试问题，以获得下一份质量保证工作！"。事实并非如此。

Crafting real questions and engaging with a candidate in a deep conversation takes significantly more investment on your part, but if the candidate is taking time from their day to talk to you, they deserve the extra effort. If you’re not up for this and just want to fire off a list of trivia questions from a script, maybe interviewing isn’t for you. You definitely won’t be interviewing for me.
精心设计真实的问题并与应聘者进行深入的交谈需要你投入更多的精力，但如果应聘者在一天的工作中抽出时间与你交谈，他们就值得你付出更多的努力。如果你不喜欢这样，只想照本宣科地回答一些琐碎的问题，也许面试并不适合你。我肯定不会让你来面试。

For the Interviewee — It’s how you think, not what you’ve memorized
给受访者 - 关键在于你如何思考，而不是你背诵了什么

If I was new to this industry and based my get-a-foot-in-the-door strategy on interviewing guides found on the internet, I would build a gigantic glossary of terms and their definitions. There would be thousands. With this list of terms fully committed to memory I could walk into any QA interview and regurgitate definitions with confidence.
如果我是这个行业的新手，而我的入门策略又是基于互联网上的面试指南，那么我就会建立一个庞大的术语表及其定义。这将有数千条。有了这本词汇表，我就可以在任何质量保证面试中自信满满地说出定义。

If all QA interviews are performed like how interview guides seem to indicate, I’d probably do quite well.
如果所有的质量保证面试都像面试指南上说的那样进行，我可能会做得很好。

Unfortunately, once hired I’d utterly fail. A memorized list of definitions does not make a tester.
不幸的是，一旦被录用，我就会彻底失败。记住一串定义并不能成为测试员。

It’s frustrating to see the disconnect between what interview guides prepare you for, and the actual skills necessary to succeed in these roles. Working as a software quality engineer or related role (quality assurance, SDET, SET, tester, etc.) requires critical thinking, problem solving, analytic skills, and above all continued learning to be successful. These are the skills you should be developing and the skills interviews should be assessing.
令人沮丧的是，面试指南所准备的内容与成功胜任这些职位所需的实际技能之间存在脱节。担任软件质量工程师或相关职位（质量保证、SDET、SET、测试人员等）需要批判性思维、解决问题、分析技能，最重要的是要不断学习才能取得成功。这些都是您应该培养的技能，也是面试应该评估的技能。

What most interview guides prepare you for is a rapid fire trivia test on a few dozen selected topics.
大多数面试指南为你准备的都是几十个精选话题的快速琐事测试。

If you are serious about entering this industry, or are looking to level up from an existing role into a more meaningful and challenging role at a new company, don’t take the easy path and memorize terms. Instead, foment understanding and the mental plasticity to succeed in novel situations with creative solutions based on a broad understanding of quality fundamentals.
如果你真的想进入这个行业，或者想从现有的职位提升到新公司更有意义、更具挑战性的职位，就不要走死记硬背术语的捷径。相反，在广泛了解质量基础知识的基础上，培养理解能力和心理可塑性，以便在新情况下通过创造性的解决方案取得成功。

This doesn’t mean you should ignore definitions. You should still be familiar with foundational concepts and terms like test pyramid, contract testing, or risk based testing.
这并不意味着您应该忽略定义。您仍应熟悉测试金字塔、合约测试或基于风险的测试等基础概念和术语。

However, know that when real companies offering meaningful careers interview you, they will be looking more for the understanding of a concept and the ability to apply that understanding to real problems, and less the correct memorization of a specific term.
但是，你要知道，当真正提供有意义职业的公司面试你时，他们更看重的是你对概念的理解以及将这种理解应用于实际问题的能力，而不是对特定术语的正确记忆。

If you are an intelligent, dynamic, inquisitive, and detail oriented person and happen to confuse validation with verification, I really couldn’t give a f*ck and would absolutely still hire you.
如果你是一个聪明、充满活力、好奇心强、注重细节的人，却碰巧把验证和核实混为一谈，我真的管不了那么多了，我绝对还会雇用你。

But then… Why so much Trivia?
但是......为什么这么多 Trivia？

The idea that interviews should be deep discussions on complex concepts and not just set of “Do you know X?” trivia questions isn’t profound. However, some real companies still interview this way. Thus, the interview guide writers aren’t to blame, they are just correctly preparing you for the bad interviews.
面试应该是对复杂概念的深入讨论，而不仅仅是一套 "你知道 X 吗？"的琐碎问题，这种观点并不深刻。然而，一些真正的公司仍在以这种方式进行面试。因此，这不能怪面试指南的编写者，他们只是正确地让你为糟糕的面试做好了准备。

Why are trivia style questions still somewhat common? My theory is that it’s because these types of questions allow the interview process to scale.
为什么琐事类问题仍然很常见？我的理论是，因为这些类型的问题可以让面试过程更有条理。

If I need to hire a thousand testers, and I’m focused on the speed and cost of talent acquisition and not getting the absolute best people, then trivia questions work. The interviewers I employ don’t even need to be qualified quality assurance engineers. I can get two hundred random people, hand them a list of questions with ‘correct’ answers and release them to canvas every person on LinkedIn. If each interviewer finds five people, I succeed.
如果我需要招聘一千名测试人员，而我关注的是人才招聘的速度和成本，而不是招聘到绝对最优秀的人才，那么琐碎的问题也行得通。我聘用的面试官甚至不需要是合格的质量保证工程师。我可以随便找两百个人，交给他们一份附有 "正确 "答案的问题清单，然后让他们在 LinkedIn 上对每个人进行地毯式搜索。如果每个面试官找到五个人，我就成功了。

Real interview questions, deep conversations on concepts, require the interviewer to understand and interpret the response. Ask the same question to ten different interviewees and you might get ten different answers, each one of them insightful in its own way.
真正的面试问题，是关于概念的深入对话，需要面试官理解和解释回答。向十个不同的面试者提出同样的问题，你可能会得到十个不同的答案，每个答案都有自己的见解。

Thus, I cannot just quickly throw together an interviewing team of two hundred random people as each interviewer needs a deep understanding of quality assurance. It would take significantly more time, effort, and expenditure assemble this team, so companies whose priority is to scale don’t do this, even if it means hiring less qualified people.
因此，我不能随意快速组建一支由两百人组成的面试团队，因为每位面试官都需要对质量保证有深刻的理解。组建这支团队需要花费更多的时间、精力和费用，因此，那些以扩大规模为首要任务的公司不会这样做，即使这意味着要雇用资质较低的人员。

Put bluntly: low effort trivia interviews by non-qualified interviewers prioritize efficiency over quality, and are used when hiring for commodity roles at scale.
直截了当地说：由不合格的面试官进行的低强度琐事面试，优先考虑的是效率而非质量，在大规模招聘商品职位时会用到。

These interviews should be a red flag for any interviewee. If you find yourself being asked a series of what does X mean? or Define Y. questions, be extremely cautious of accepting any offer. Such a company is not looking for a high value individual for a high value, high impact role. They are looking for bodies to meet a quota. The disregard they are showing for quality during the interview process will not change once you’re hired. In this type of organization you are going to be a number and a bill rate, and that’s it.
对于任何面试者来说，这些面试都应该是一个警示。如果你发现自己被问到一系列 X 意味着什么或定义 Y 的问题，那么在接受任何聘用时都要格外谨慎。这样的公司不是在为高价值、高影响力的职位寻找高价值人才。他们寻找的是能满足配额要求的人才。一旦你被录用，他们在面试过程中表现出的对质量的漠视将不会改变。在这种组织中，你将成为一个数字和账单率，仅此而已。

There are organizations out there who desperately need smart people with a deep understanding of quality to help build and deliver real, complex, modern software. Go find them. The nature of the questions they ask in your interview will be the first indication you’ve found the role you’ve been searching for.
有些组织急需对质量有深刻理解的聪明人来帮助构建和交付真正的、复杂的现代软件。去找到他们吧。他们在面试中提出的问题的性质将是你找到你一直在寻找的职位的第一个迹象。

If you are looking for a learning roadmap of the technical concepts necessary for a career in a quality engineering, read this:
如果您正在寻找质量工程职业所需的技术概念学习路线图，请阅读这本书：