我对质量保证面试指南的不满
我曾写过一篇关于质量工程面试的文章，这是我热衷的一个话题。那篇文章以及后续的文章《质量工程面试问题》都是为我工作的《Slalom Build》杂志撰写的。因此，我不得不收敛我的言辞，减少我的强烈观点。具体来说，我删去了一整节描述互联网上许多面试指南如何糟糕的内容。
这不是我的工作刊物，所以我在这里没有这种限制。请继续阅读，了解为什么大多数面试问题都很糟糕，为什么它们不能正确识别优秀的候选人，以及为什么你无论如何都不想为任何会问这些问题的公司工作。
给面试官 —— 为什么你的问题很糟糕
这不会是一篇关于面试的长篇论文，所以我就直奔主题了：你的面试问题之所以糟糕，是因为这些问题都是作为琐事挑战而提出的，除了能让你了解应聘者是否知道这一具体事实外，几乎不能让你了解应聘者的其他情况。这些问题的模式是 “X 的定义/含义/目的是什么？”，其中 X 是一些与质量相关的具体概念。下面是 Medium 搜索返回的第一篇采访文章中的一个例子：
什么是猴子测试？
这个问题太可怕了。它能告诉我什么？它告诉我候选人是否知道 “猴子试验 “一词的定义，仅此而已。
一些问题:
- 优秀的测试人员可能不知道猴子测试
- 优秀的测试人员可能知道这个概念，但知道它的另一个名字（比如……混沌测试，甚至弹性测试）
- 糟糕的测试人员可能很清楚这个概念，因为他们是在博客上读到的，但给他们一千年时间也无法实现。
现在，如果这个问题是作为关于测试软件弹性的深入对话的起点，那还不错。然而，上面这篇文章并没有这样做—它只是一个简单的 “什么是 X？”的问题，然后是简短的两段定义，并强烈暗示作为应聘者，这就是你需要说的。
面试指南中的其他琐碎问题示例：
- 什么是质量控制和质量保证？
- 缺陷分为哪几类？
- 什么是快速应用程序开发？
- 什么是 DFD（数据流图）？
- 描述 PDCA 循环。
- 什么叫潜在缺陷？
有些琐碎问题甚至更糟糕，因为它们所涉及的主题没有普遍理解的定义，或者在某种程度上是主观的或与上下文有关的。以下几个问题就属于这一类：
- 什么是风险的五个方面？
- 定义敏捷测试，并说明其重要性。
- 缺陷和错误之间有什么区别？
提出这些问题的文章往往都有一个所谓 “正确 “的答案，这太荒谬了。我对每个问题的看法：
只有在参加 ISTQB 认证考试的 30 分钟内，你才需要了解验证和确认之间的区别。在此之后，这种区别就完全没用了，因为没有人会使用准确的定义。
我在这个行业工作了 22 年，从来没听说过软件质量风险的五个维度的明确清单。谷歌搜索的热门答案与他们的列表（进度、客户、人力资源、系统资产、质量）不符，甚至与其他搜索结果也不符。
定义敏捷测试？人们甚至无法就敏捷的定义达成一致。
在 ISTQB 的语境中，缺陷和错误确实有精确的定义，但在大多数公司中，这些区别很少被使用，甚至不为人知。如果您要组建一支 ISTQB Trivia 团队，这是一个很好的问题，但如果您要招聘一支软件开发团队，这个问题就不那么好回答了。
解决问题
所有这些问题都可以通过从回答关于特定术语或主题的小问题到关于概念的深度对话来加以改进。
例如:
- 风险的五个方面是什么？(小问题）
…变成…
- 软件项目失败的原因有哪些？
- 您认为质量保证工程师在避免或减轻这些失败方面扮演什么角色（如果有的话）？(邀请大家讨论他们对软件质量、风险、质量保证工程师在团队中的作用以及许多其他相关主题的理解和看法）
例如：
- 定义敏捷测试（小问题）
….变成…
- 在规定了冲刺长度并承诺每个冲刺都要交付工作的开发模式（如 Scrum）中，质量保证有哪些常见的挑战或挫折？
- 应对这些挑战/挫折的策略有哪些？(邀请大家讨论他们在敏捷方法中测试软件的经验、他们遇到的挑战、他们如何解决或希望解决这些问题、他们对敏捷的总体看法及其对质量的影响，等等……）。
在采访中穿插一两个琐碎的问题很可怕吗？绝对不会。就像放盐一样，少量就好，甚至还能增加多样性。问题是，在互联网上或 Medium 上找到的许多面试指南通常只列出了这些琐碎的问题，每个问题都有一个简短而明确的答案。它们的标题是 “你必须知道的 40 个质量保证面试问题！”或 “你必须回答的 20 个测试问题，以获得下一份质量保证工作！”。但事实并非如此。
精心设计真实的问题并与应聘者进行深入的交谈需要你投入更多的精力，但如果应聘者在一天的工作中抽出时间与你交谈，他们就值得你付出更多的努力。如果你不喜欢这样，只想照本宣科地回答一些琐碎的问题，也许面试并不适合你。我肯定不会让你来面试。
给应聘者 —— 关键在于你如何思考，而不是你背诵了什么
如果我是这个行业的新手，而我的入门策略又是基于互联网上的面试指南，那么我就会建立一个庞大的术语表及其定义。这将有数千条。有了这本词汇表，我就可以在任何质量保证面试中自信满满地说出定义。如果所有的质量保证面试都像面试指南上说的那样进行，我可能会做得很好。不幸的是，一旦被录用，我就会彻底失败。记住一串定义并不能成为测试员。
令人沮丧的是，面试指南所准备的内容与成功胜任这些职位所需的实际技能之间存在脱节。担任软件质量工程师或相关职位（质量保证、SDET、SET、测试人员等）需要批判性思维、解决问题、分析技能，最重要的是要不断学习才能取得成功。这些都是你应该培养的技能，也是面试应该评估的技能。
大多数面试指南为你准备的都是几十个精选话题的快速琐碎测试。如果你真的想进入这个行业，或者想从现有的职位提升到新公司更有意义、更具挑战性的职位，就不要走死记硬背术语的“捷径”。相反，在广泛了解质量基础知识的基础上，培养理解能力和心理可塑性，以便在新情况下通过创造性的解决方案取得成功。
当然这并不意味着你应该忽略定义。你仍应熟悉测试金字塔、合约测试或基于风险的测试等基础概念和术语。但是，你要知道，当真正提供有意义职业的公司面试你时，他们更看重的是你对概念的理解以及将这种理解应用于实际问题的能力，而不是对特定术语的正确记忆。如果你是一个聪明、充满活力、好奇心强、注重细节的人，却碰巧把验证和检查混为一谈，我绝对还会雇用你。
但是…为什么要讲这么多琐碎问题呢？？
面试应该是对复杂概念的深入讨论，而不仅仅是一套 “你知道 X 吗？”的琐碎问题，这种观点并不深刻。然而，一些公司仍在以这种方式进行面试。因此，这不能怪面试指南的编写者，他们只是正确地让你为糟糕的面试做好了准备。为什么琐碎类问题仍然很常见？我的理论是，因为这些类型的问题可以让面试过程更有条理。
如果我需要招聘一千名测试人员，而我关注的是人才招聘的速度和成本，而不是招聘到绝对最优秀的人才，那么琐碎的问题也行得通。我聘用的面试官甚至不需要是合格的质量保证工程师。我可以随便找两百个人，交给他们一份附有 “正确 “答案的问题清单，然后让他们在 LinkedIn 上对每个人进行地毯式搜索。如果每个面试官找到五个人，我就成功了。
真正的面试问题，是关于概念的深入对话，需要面试官理解和解释回答。向十个不同的面试者提出同样的问题，你可能会得到十个不同的答案，每个答案都有自己的见解。因此，我不能随意快速组建一支由两百人组成的面试团队，因为每位面试官都需要对质量保证有深刻的理解。组建这支团队需要花费更多的时间、精力和费用，因此，那些以扩大规模为首要任务的公司不会这样做，即使这意味着要雇用资质较低的人员。
直截了当地说：由不合格的面试官进行的低强度琐碎面试，优先考虑的是效率而非质量，在大规模招聘商品职位时会用到。对于任何面试者来说，这些面试都应该是一个警示。如果你发现自己被问到一系列 X 意味着什么或定义 Y 的问题，那么在接受任何聘用时都要格外谨慎 。这样的公司不是在为高价值、高影响力的职位寻找高价值人才。他们寻找的是能满足配额要求的人才。一旦你被录用，他们在面试过程中表现出的对质量的漠视将不会改变。在这种组织中，你将成为一个数字和账单率，仅此而已。
有些组织急需对质量有深刻理解的聪明人来帮助构建和交付真正的、复杂的现代软件。去找到他们吧。他们在面试中提出的问题的性质将是你找到你一直在寻找的职位的最初迹象。
