在庞大而复杂的当代IT世界中, 质量保证工程占有独特的地位. 不管正在开发的具体技术和手头项目的规模和范围如何, QA工程几乎总是努力的关键元素.
在整个开发生命周期中都是如此. QA帮助组织确保成功和有效的设计, 完成, 以及在这个过程的每个阶段对其技术产品的持续维护.
那么，一家公司如何评估一名熟练的QA工程师呢? 他们必须记住，候选人必须能够同时扮演直觉的技术侦探和熟练的技术工程师的角色. 他们还必须考虑到QA任务在现实世界中的广泛应用, 行业中的许多关键术语和相关概念经常在QA工程师之间争论不休.
在评估潜在候选人时, 请记住，他们的目的是通过复杂的演绎调查，找出并发现复杂技术产品的任何和所有负面问题. 他们会毫不留情地试图破坏和严格审查其他工程师花费长时间设计和开发的系统，以尽可能避免错误.
Meanwhile, 应聘者必须从头到尾与跨职能部门和人员积极沟通. 他们需要将消极的批评转化为有益的、积极的投入和反馈. And, 他们将需要计划和组织过程本身，以及具体的测试计划和测试结果. 此外，他们必须就每一个要素提供清晰和有组织的文件.
IT组织的总体目标, after all, 是否确保其产品的最终用户获得积极和顺畅的体验. 因此，QA工程师必须倡导具有洞察力、直觉和准确性的用户体验. 他们必须以协作的方式与QA和相关开发过程中的所有相关团队合作.
QA工程师角色的要点
本指南将重点介绍成功候选人应具备的三个互补的优势和技能领域:
直觉和自信的表现能力 密集的技术侦查 work.
专业技术 、专业经验和职业目标.
高级语言 沟通 文档和报告技能.
在我们开始之前，注意几个关于面试过程的要点是有帮助的.
技能的相互关系
上面概述的三个评估领域是密切相关的, 它们以不同的方式重叠. 这在面试中是有益的:专注于某一类技能, 我们可以同时更多地了解其他两个.
被置于窘境
面试过程中, 如果考生遇到一个他们不完全理解的话题，或者必须询问更多的信息才能继续, great!
这将为面试官和候选人提供一个独特的机会. 面对潜在的负面影响，这是候选人展示自信和沟通方式的理想时机, 施压, 尴尬的情况.
他们是否不怕坦率地承认自己缺乏知识或技能, 并大胆主动地参与相关问题，以便他们能够解决问题? 他们提出问题和使用答案的方式是否表明他们有能力在飞行中直观地推断, 勇敢地交流, 并在实时过程中逻辑智能地合并新获取的数据?
例如, 如果候选人承认他们从未听说过某个特定的术语，他们只是被问到, 好好谈谈, 因为这可能是个好兆头. 很可能他们对这个概念非常熟悉, 只是还没见过这个名字.
把面试当成自己的QA练习
在面试结束时, 你应该有一个全面的, 候选人技术技能的详细视角, 相关人格特征, 以及专业经验. 记住，面试本身可能被认为是质量保证的练习:这是一个测试测试人员和探索候选人QA能力程度的机会.
那么，我们开始吧.
评估类别#1:技术福尔摩斯
候选人首先应该表现出的优势是直觉和自信的能力, 技术侦查工作. 候选人需要进行推断, discover, 分类, 并将错综复杂的细节联系起来, 行为特征, 以及复杂系统的性能指标.
这个区域更多地代表了一组个性特征，而不是特定的技术技能. 潜在的QA工程师需要向你展示他们有能力进行细致而自信的技术调查. 这些特点包括对细节的高度关注, 顽强的承诺和坚持到底, 具有敏锐的逻辑和直观的演绎推理能力，对沟通和提出相关问题有信心和熟练程度.
许多QA领域的人认为这个领域是 最重要的 在评估候选人能力时, 当然还需要有技术知识和经验的补充. 无论组织在其IT产品中使用哪种特定的平台或技术，一个热心而执着的调查者都可能在QA方面表现出色, 或者QA团队使用的特定工具.
但评估候选人调查能力的最佳方法是什么呢? 我们建议你直接进入面试过程，让应聘者当场做一些实际操作练习, 接下来是几个简单的问答环节，讨论相关的素质和技能.
第一个书面练习:测试计划的基本部分
首先让你的测试工程师候选人在纸上写下测试计划的基本部分, 随附每个部分的快速总结. 如果他们之前已经成功地完成了测试周期, 他们应该熟悉生产——或者至少是参考——测试计划文档, 这一过程的核心部分是什么. 下面是测试计划的标准部分的列表，根据 ISO / IEC / IEEE 29119 - 3:2013 . (这取代了 IEEE 829标准测试计划模板 ，但后者提供了更方便的阅读.注意，不同级别的测试计划文档有不同的变体:
主测试计划 覆盖多个层次
阶段测试计划 覆盖单相和 可能包括 :
特定于测试级别的测试计划(例如.g.、集成)
特定于测试类型的测试计划(例如.g.、性能)
这里包含的IEEE 829模板通常适用于主测试计划和阶段测试计划(有时会合并到一个测试计划文档中)。.
测试计划标识符: 归档和引用每个测试计划文档的独特方式.
参考文献:支持测试计划的文档列表.
作品简介: 关于项目和测试计划文档的简要介绍(参考文献和术语表有时可能包含在本部分中).
测试项目: 要测试的软件项目列表.
软件风险问题:需要测试的关键软件领域和固有风险，例如复杂性.
需要测试的功能: 要测试的功能列表.
不需要测试的功能: 不需要测试的特性和不包含它们的原因.
Approach or 方法/技术: 测试的总体方法和相关技术.
项目合格/不合格标准: 要测试的元素的完成标准. (这有时简称为 Pass/Fail or 功能通过/失败 ，在这种情况下，它还可能包括计划级元素的标准.)
停牌准则及复业规定: 暂停测试的条件和随后恢复测试的条件.
测试可交付成果: 作为测试过程的一部分要创建的文档和工具.
测试任务: 计划和执行测试的任务.
环境需求: 环境要求，如硬件、软件、操作系统、网络配置、工具等.
人员配备和培训需求: 人员配置、技能和培训要求.
职责: 团队成员的相关角色和职责.
日程安排: 重要的项目交付日期和关键里程碑.
风险及意外事件[缓解措施] 高级项目风险和假设，以及针对每种风险的应急/缓解计划.
批准: 文件、相关章节和签署日期的每个审批人.
术语表:文档中使用的特定和/或不常见术语和缩略语的定义.
注意:考生不需要列出测试计划模板的所有可能部分, 但他们应该熟悉几个更常见的项目, 哪些用粗体标出. 在实际项目中使用的一般大纲有许多变体, 一些组织使用专有的测试计划, 因此，对不同的反应保持开放态度是很重要的.
测试计划概述了将在给定软件项目或更具体的软件项目的整个测试过程中应用的关键指导方针 模块或组件 在软件项目中.
有时，应试者可能没有编写测试计划的直接经验. 例如, 这个责任通常留给QA团队的其他成员, 比如测试主管或测试经理. 在这种情况下, 询问他们是否至少对参考和使用测试计划足够熟悉，以便写下一些核心部分. 如果他们不能, they should be able to sufficiently explain why; then also ask them, 以开放式的方式, 而不是写一个总结的基本阶段 软件测试生命周期 .
要求候选人写下他们熟悉的STLC阶段，可能会发现与QA相关的其他术语和流程. 这些讨论要点可以让你进一步了解他们在行业中的成功程度和经验类型. STLC的主要步骤包括:
需求/设计评审:对可测试的软件需求和设计元素进行组织和评审.
测试计划:测试策略是计划和定义的.
测试设计/测试用例开发:准备好测试用例、测试数据和自动化脚本.
环境设置:设置测试环境以复制最终用户环境.
测试执行:运行测试用例/脚本，记录和跟踪结果，等等.
测试报告和测试周期结束:准备/审查报告并结束测试周期.
在任何情况下, 在这部分练习之后，对应试者的书面回答进行口头回顾. 正如我们提到的, 在早期阶段这样做可以让面试官有机会看到候选人在突然出现的聚光灯下是如何沟通和回应的. 这个测验有助于发现他们的知识和经验，同时测试他们的行为反应和相关的人格特征.
It’s certainly okay to ask for both STLC and test plan outlines up front; however, 这并不是特别必要的，因为如果应试者对测试计划的部分或全部都很了解, 他们也很可能熟悉STLC阶段总结. (注:STLC将在后面的采访中更详细地讨论.)
注意:一个熟练的QA工程师的一个标志性的行为特征是，他们倾向于在面试过程中自发地问相关的问题. 例如, 当开始编写测试计划的基本部分时, 经验丰富的求职者可能会询问总体规划, 测试级计划, 或者一个测试类型的计划是专门为练习考虑的. 这可能是熟练工程师的一个很好的指标, 这样一个问题的答案可能只是考虑一个一般的阶段级测试计划模板, 或者选择候选人喜欢的任何特定类型的测试计划.
第二个书面练习:简单GUI的测试用例
Next, 通过给应试者一个图形用户界面(GUI)的基本图，直接进入另一个书面练习。. 然后要求他们在固定的时间内写下尽可能多的与GUI相关的测试用例, 大概10-15分钟左右.
这是一种非常常见的测试QA应聘者的方法. 它对于观察真实世界的技术调查技能非常有效, 历史经验, 以及对直觉和演绎逻辑测试相关分析的核心QA任务的熟悉程度. 这也是一种观察相关行为和人格特征的方法.
使用简单明了的GUI设计是很重要的. 您只需要很少的表单字段、命令按钮、复选框和链接. 也许2到5个字段，4到8个相关元素就可以了. 这将提供足够的逻辑材料来生成几十个可能的测试用例.
许多QA面试官使用标准的在线登录表格进行此类练习:
这样的登录屏幕呈现了大量的测试用例. 但是快速搜索一下就会发现很多网站列出了几十个常用登录表单的测试用例. 很多甚至是专门针对QA工程师的面试.
这就是为什么我们建议为这个活动想出一个独特的简单GUI设计, 考虑到许多申请人可能已经提前准备了登录屏幕测试用例测验.
这也适用于我们即将在下面介绍的示例GUI. 因此，如果可以使用您的组织中目前正在使用的简单的专有用户界面(或者可能正在进行设计审查或测试)，那就更好了. 这样它就不仅是独一无二的，而且是高度相关的.
使用特定GUI的简化版本也可能是可行的, 或者是一个接口的特定部分，它可以独立存在，并且在审查测试用例时可以清楚地理解. 例如, 下面这个虚构的图表演示了用于此活动的一个简单的专有接口. 这是一个简单的GUI，表示发票初始化和生成屏幕的标题部分.
注意:使用任何GUI图, 保持独立, simple, 很容易理解. 字段或元素太多, 或者潜在的不清晰或令人困惑的界面设计方面, 可能会使练习复杂化，需要在开始之前进行冗长的解释, 或者将测试用例的潜在数量增加到超出合理范围的倍数. 记住我们前面提到的:只有两个字段和几个按钮, links, 一个非常简单的登录窗口上的复选框已经提供了几十个测试用例.
在候选人开始写出测试用例之前, 允许简短地回顾一下界面的目的和GUI如何使用的高级上下文. 以口头或书面的方式概述该接口的使用，以便:
通过输入客户名称创建新的发票ID号, 发行和到期日期, 和主题/描述, 然后点击“生成发票”按钮.
通过单击“链接到现有发票”按钮，将新发票链接到先前存在的发票，可以自动填充客户名称字段.
在填写此标题部分信息并生成新的发票ID之后, 屏幕自动启用底部的“发票项目/详细信息”部分(未见图)，并允许您开始输入发票项目.
提供足够的信息以涵盖界面的总体目的, 但是不要讨论具体的规则细节, 需求, 或者测试与GUI中的单个元素相关的先决条件. (还要澄清他们不应该为底部的“Invoice Items/Details”部分创建测试用例.)
Then, 就在活动的书面部分开始之前, 鼓励候选人带头询问有关GUI设计元素的任何澄清，这些元素在制定测试用例场景时可能是相关的. 例如, 他们可能会询问精确的软件规则和需求, 包括特定功能的预期行为, 或者与测试用例前提条件相关的流程流.
这是练习的一个重要部分. 在开始写作部分之前，一定要给考生足够的时间. 这将让您观察候选人如何很好地解释接口设计，并在将其应用于测试用例之前有效地调查相关细节.
发票初始化GUI可能会提示如下问题:
字段、命令按钮和超链接的预期选项卡顺序是什么? 当在界面中选择选项卡时，是否应该部分或全部命令按钮和超链接接收焦点?
客户下拉框应该允许还是禁止新客户直接进入该字段? 如果允许这样做，预期的行为是什么. 禁止? 如果不允许，应该弹出警告信息吗, 如果允许，也可以弹出数据输入窗口?
按下“搜寻客户”按钮后会出现什么情况? 是否应该打开一个单独的搜索窗口, 或者在相同的屏幕展开中添加一个额外的部分, 或者客户字段的列表应该简单地下拉以滚动客户名称?
对于发行日期和到期日期值是否有验证规则? E.g.，到期日是否必须落在签发日期之后，或者是否有其他日期验证? 如果是这样，如果这些规则被打破，预期的行为是什么?
主题/描述字段有字符限制吗, and if so, 允许多少个字符? 如果超过字符限制是否有预期的行为?
主题/描述字段是否与unicode兼容?
当用户点击“链接到现有发票”按钮时应该发生什么? 应该显示单独的发票搜索窗口，还是应该展开下拉选择列表?
创建新的发票ID号需要哪些数据字段? 如果单击“生成发票”按钮时缺少一个或多个必需字段，预期的行为是什么?
当点击“关闭并保存”和“取消并退出”命令按钮时，预期的行为是什么, 这些测试场景的相关前提条件是什么? E.g., 如果还没有生成发票ID，点击“关闭并保存”应该怎么做, 以及当已输入部分或全部数据时，“取消并退出”应该做什么?
单击“发票规则”时应该发生什么 & 指南”按钮? 应该弹出帮助窗口吗, 或者在用户的外部浏览器中打开一个参考页面?
注意:这部分的活动是另一个原因，为什么是一个好主意使用独特的, 也许专有, 用户界面，而不是典型的登录页面. 不会有很多关于规则的质询机会, 有意的行为, 测试的条件基本上是通用的登录页面设计我们都非常熟悉. 独一无二的原创, 虽然是简单的, 相反，用户界面设计将为候选人提供足够的空间，以便分析GUI中的各种相关规则, workflows, 条件, etc.
这是另一个观察申请人沟通风格和相关技能的机会. 例如:在分析GUI和任何潜在的测试用例相关问题时，它们是直观的和演绎的吗? 他们的沟通方式是否清晰有效? 他们会一丝不苟地写下问题的答案吗, 或者他们会记住不同的点? 如果用他们的记忆, 当生成相应的测试用例时，他们是否成功地回顾了那些点?
再次强调，要注意应聘者是否倾向于问一些自发的问题. 例如, 在这个练习中, 一个熟练的求职者可能会问他们是否应该使用特定的格式——假设面试官没有提供.
他们可能会问他们是否应该用桌子, and if so, 是否包含或排除测试用例ID号的列, 积极与. 负用例和测试类型分类、前提条件、输入测试数据或测试用例步骤.
如果面试官想要指定格式, 以下是他们可能会让应聘者使用的三种方法:
第一种方法的列表格式将给出候选人在逻辑上推断和推导测试用例的能力的足够清晰的图像.
第二种方法不会花费太多额外的时间, 并且将有助于阐明申请人对测试用例公式和文档的适应程度和专业知识.
但是，如果表的列数超过4列(可能是您的组织实际用于创建测试用例的列数)，请确保给候选人留出额外的时间. 还要注意，预先指定这一点可能有些过头, 偏离练习的要点. 只有最热心的专家才需要这样做.
在申请人的问题和他们的定时测试用例编写之后, 对结果进行口头回顾.
确保为接口准备了一个完整的测试用例列表的完整内部版本, 并且在查看候选版本的测试用例列表时，使用那个主副本作为参考. 让申请人对他们写下来的案例进行开放式的讨论, 以及他们可能用来组织列表的文档样式和布局的任何相关观察.
在面试开始的时候，通过这些动手和互动的书面和口头的QA练习，让应聘者站在现场，会让你对面试有很大的了解. 这两种最初的书面活动都有助于开始阐明候选人倾向于组织测试相关文档的方式. 你也会了解到候选人的性格, 经验, 信心, 沟通方式, 以及他们进行直觉演绎技术调查的能力.
问答环节:彻底和直观的技术调查
在前面两个练习之后，再进行一些传统的面试问答是一个好主意, 选择与他们的个性特征和执行复杂技术调查的技能相关的主题.
从候选人自己的经历中了解他们的观点, 熟练, 以及成功的程度, 注重细节, 以及演绎推理.
以下是一些精选的面试问题, 以及可能的答案, 这样可以很好地开始问答环节, 也有助于更好地了解申请人的技术调查过程.
注意:有经验的求职者会有很多关于技术主题和工作场景的想法和故事可以说明——总是要求举例!
问:你为什么喜欢做软件质量保证工作? 你能举出一两个具体的工作例子来说明你最喜欢这个领域的什么吗?
从这个问题开始，面试官可以了解应聘者对QA环境的看法. 考虑到QA的核心活动是通过测试结果进行演绎技术调查和批评, 这是一个很好的机会来检查候选人的总体态度是否有危险信号.
例如, 如果他们说他们喜欢能够通过QA过程将软件问题转化为积极因素的感觉，并且提供具体的例子, 这些场景的有意义的例子——这将表明一个有技能和团队意识的候选人.
但是如果他们说他们喜欢有机会批评别人的工作，并指出其他工程师设计和开发的错误, 也许表现出屈尊俯就——这绝对是一种适得其反的性格. 即使他们可能擅长发现bug, 最好聘请一个不仅能有效地找到问题，而且能以专业的方式报告问题的人. 否则，你将花费额外的时间来消耗士气，如果不解决直接的冲突.
问:你觉得有什么困难吗, 或者甚至不愉快, 关于质量保证方面的工作? 你能举例说明你过去在工作中遇到过的挑战吗, 以及你是如何处理的?
接着问第一个问题，翻翻稿子. 在这里，你可以让应聘者以开放式的方式表达对QA的任何负面感受和看法. 找出他们认为这个行业有什么困难甚至不愉快的地方. 这也是测试申请人无所畏惧的沟通能力的一种方式, 识别并解决潜在的负面话题, 对可能不愉快的话题保持积极的态度和有利位置.
也许他们会说，有时候架构师和开发人员会对缺陷列表进行彻底的个人处理. 如果他们接着说，与这些合作的工程师接触，就相同的QA分析提供积极的注释和反馈，有助于极大地缓解负面情绪, great! 这表明申请人既善于研究软件，又善于团队合作.
但也许他们会解释说，不断地检查和再检查规范文档给他们带来了难以忍受的头痛，并干扰了他们的个人生活. 如果这就是那条线的终点，那就值得关注了.
或者他们可能会说，他们无法忍受向其他工程师解释测试方法和结果背后的逻辑, 或者讨厌弄清楚何时停止测试过多bug的模块, 或者希望他们能摆脱所有的文书工作. 这样的答案——没有合适的解决方案——也是危险信号.
问:你是如何熟悉一种新的软件产品，并学习你需要知道的一切，以便彻底测试它的? 如果文档是不可用的、有限的、过时的和不准确的，你的方法是什么?
好的答案包括:
Use it! 优秀的软件测试人员是优秀的软件用户. 他们会想要作为一个日常用户直接使用它, 记录相关的观察结果和潜在的问题.
内部和外部咨询. QA工程师经常与架构师和开发人员等其他团队成员一起检查软件, 以及其他测试人员. 除了, 有经验的候选人可能会提到与销售和营销团队成员就产品进行交谈的想法. 通常他们会对系统有一个独特的视角——一旦QA工程师完成了他们最初的探索，这是一个有益的补充.
销售通常关注与性能/容量相关的特定功能和特征, 现实世界的可伸缩性, 具体的可用性要点, 未来的改善计划, 并与市场上其他同类系统进行了有用的产品比较. 此外, 他们推荐的功能在测试时优先考虑，并且可以允许更早的演示可用性.
如果产品已经被客户/最终用户使用, 高级QA工程师也希望调查来自这些渠道的输入和反馈, 包括潜在的公众或市场层面的系统审查, 如果适用的话.
版本和代码审查. 熟练的工程师将希望查看应用程序的先前版本, 如果可用, 以及研究管理相关应用程序逻辑的相关源代码. 他们还可能特别提到，检查SQL/数据层/后端/中间层或系统架构中其他可能不太明显的部分是很重要的.
文档. 工程师将需要审查与设计相关的文档, 规则和要求, coding, 先前的测试周期, 以及历史和当前的路线图. 但如果他们做不到呢?
检查所有现有的文件资源. 无论以前的文档多么稀少或过时/不准确，通常至少 something exists. 也许有一些手工制作的开发前草图，粗略的界面布局或线框图. 或者可能有一小组高级需求或用例的快速而肮脏的列表. 这些可能仍然提供有关实际的有价值的见解, 或者至少是有意的, 一个系统当前和过去的状态和特征.
学习系统并推断相应的参考资料. 即使文件不存在, 软件仍然由逻辑设计规范组成, rules, 以及指导其创建的需求. 因此，使用上面列出的方法e.g., 最终用户模拟产品的使用情况, 版本和代码审查, 以及相关的咨询——一个人可能会尽可能熟悉这个系统, 在这个过程中，尽可能多地推断出规则和要求, 同时要记住，通过减少潜在的不明确或复杂的假设来限制实际的误差幅度.
现在创建它. 一个急切而专业的候选人只会通过写作(或合作)来填补空白。 accurate 文档，同时执行前两个步骤中概述的活动!
问:你认为自己是一个注重细节的人，或者甚至是一个完美主义者吗? 如果是这样，这对你的QA工作有什么影响? 你能从过去的项目中举出一些例子来说明这些或类似的性格特征对你产生的积极和消极影响吗?
有些人认为QA工程师通常有完美主义倾向, 也许他们甚至应该这么做, 至少在某种程度上是这样. However, 这需要理解有一个测试需要停止的点, 过多地纠结于细节和缺陷会变成消极的一面.
直面这个话题，直接询问这个问题潜在的负面影响. 不管他们回答自己是完美主义者还是不是, 或者介于两者之间, 无论如何，如果他们觉得自己是顽强而注重细节的人，他们会继续进行详细阐述. 让这个对话自然地引导到描述如何, when, where, 以及为什么申请人表现出奉献精神和坚持到底, 以及在调查环境中对成功细节的追求.
他们是否将这些特征与执行复杂的演绎过程的主题直接联系起来? 他们用什么样的例子来说明反映这些品质的现实世界的情况呢?
重要的是，他们要解决他们历史上关于这个问题的任何负面角度. However, 如果他们的反应变成抱怨他们晚上很难入睡，因为他们沉迷于一个或两个测试用例，他们可能在许多已经完全定义的场景中错过了, 这是令人担忧的.
If, 另一方面, 他们在不断的追求中表达了这一点, 随之而来的冲击, 详细规格, rules, 测试用例, 测试结果, 后续的分析, 文件, etc., 他们能够在保持整体项目级图片的视线之间取得健康的平衡, 并且自信地知道什么时候工作已经充分完成, 这表明申请人是忠诚的, 甚至可能是某种完美主义者, 但也知道如何最好地管理它.
与此领域相关的一个很好的在职例子是，应聘者指出QA过程和文档是故意设计来帮助解决这些陷阱的:这就是测试计划和策略的具体原因 [should] 包含测试项目的完整和详细信息, 要包含/排除的特性, 方法, 通过/失败标准, 悬架的标准, 测试任务, etc. 这也是为什么QA工作的每一步都应该提前计划并在此过程中进行有效监控的原因. 这一结构将为QA创造一个无压力、愉快且有回报的环境. 这是因为即使对于完美主义者来说，它也会对所需的细节数量进行精确的限制.
如果候选人公开承认他们有强迫症的问题，这是由真正完美主义的人格特征引起的, 但他们已经学会了如何利用这一点，而不是让它压倒他们——他们的简历上有记录来支持这一说法——他们很可能是一名理想的软件测试人员.
问:这是什么? 错误猜测 ? 您能给出一些测试用例和缺陷类型的例子吗?
错误猜测指的是一种方法，它根据先前项目中类似应用程序的测试结果推断出其他模糊的测试用例. 这种技术由经验丰富的工程师使用，结合他们的经验和直觉.
前开发人员有时对某些应用领域的错误猜测非常精通，因为这些类型的错误通常与编码和SQL/数据层的幕后技术方面以及与系统架构和设计概念相关的其他技术有关:
在处理数据记录的系统中，由于输入数据字段和/或按错误顺序单击与数据相关的命令按钮而导致的数据错误.g. 当该记录没有新的数据时，点击“更新记录”按钮, 或者部分数据不足, 已注册.
前导空格相关的错误, 尾随的空格, 或者在编辑/存储文本的系统中完全空白.
在处理附件的系统中出现“空附件”或“附件限制超出”错误.
在执行计算的系统中，除零和数字溢出错误.
分配资源的系统中的资源分配和资源回收错误.
在使用参数化SQL api的系统中出现无效/缺少SQL参数错误.
问:请描述一下你是如何发现和定义潜在的边缘情况和边缘情况的. 什么时候停下来比较好? 什么时候忽略已经确定的病例是一个好主意. 寻找一个变通的方法或者执行完整的决议? 你能从过去的项目中给出一些例子，或者假设的插图吗?
边缘案例和边缘案例是QA中与密集演绎和直觉逻辑相关的基本概念, 每个QA工程师都应该熟悉它们. 这些是当系统使用和/或运行在或超出正常操作边界或条件时. 条件可能是 technical 在本质上，例如当超出系统规范时，或者它们可能是 logical ，例如当实际操作超出典型/预期的流程流时. 通常，错误本身很少或周期性地发生.
一个技术示例可能是在SQL表中插入新记录时超过了行大小限制, 并定义当这种情况发生时系统应该做什么.
这是一个逻辑边缘情况的例子, 考虑一个生产线系统，其中偶尔, 产出水平提高. 在回应, 系统标记需要额外的零件订单, 然后下订单, 但是输出级别标志被认为是错误的, 因此取消请求会在这些订单上注册, and then the flag is again thought to be correct; meanwhile, 订单的状态随后为待处理/未知. 同样，重要的是要定义系统应该如何管理这样的场景.
边缘情况通常涉及一个极端情况，如上面的两个例子. 边缘情况是指多个边缘情况同时发生. 假设在达到上述SQL行插入限制的示例中，同时存在SQL表索引和锁定边缘情况问题. 或者假设零件订单边缘情况与涉及不正确零件库存水平的边缘情况相吻合. 这些场景是否会使系统处于中断状态?
根据系统和程序工作流的技术和逻辑限制和边界，可以很好地理解和通常考虑一些这样的情况. 但是总是会有意想不到的情况，这些情况在软件设计中并不明显, 需求, 过程流单独存在.
However, 要注意应聘者对这个问题的回答是否过于倾向于“期待意料之外的事情”.“虽然这种情绪很重要, 高级申请者知道一个有效的方法比这更具体一点.e.，重要的是:
使用软件规范、规则和设计元素(如GUI布局、流程流等).).
调查系统限制和技术特点.
注意其他更明显、更容易定义的测试和用例.
运用大量纯粹的想象思维.
问很多很多实际的和假设的问题，关于系统的所有可能的使用方式，以及受外部因素影响的方式.
考虑其他工程师可能很少(如果有的话)考虑的情况和事件是至关重要的, 包括我们上面定义的极端情况.
这是测试人员努力破坏应用程序的地方. 这也是一个好的候选人知道该走多远的地方, 这些边缘/边缘情况可能无法完全解决，而是可以绕过甚至不去管它. 这完全取决于所涉及的风险的严重性.
例如, 在金融/银行和安全敏感系统工作时, 显然，必须排除所有可能影响货币交易和安全问题的潜在边缘和边缘用例，并解决每一个可能的技术和逻辑使用和测试用例, 不管这种情况多么罕见或不可能发生. However, 测试存储消费者调查数据的系统时, 通过简单地添加如下的快速错误消息，可以消除罕见且不太可能出现的数据输入极端情况, “出问题了。, 请再次输入该名称和地址.”
较强的QA应聘者会努力关注隐藏的假设和模糊的系统特征，而其他人可能会认为这是理所当然的, 或者一开始就没有意识到. 他们也可能试着想象自己是终端用户，他们可能:
对技术或软件工程知之甚少或一无所知
不了解系统的各种规则和预期用法
以各种方式误解系统
这些方法更普遍地应用于QA测试头脑风暴, 同时也可以帮助他们想象出软件设计师可能从未设想过的用例.
其他QA工程师面试问题的想法
当面试官希望深入了解应聘者的行为特征和逻辑能力时，我们在这里提供了一些建议:
你在工作之外是否从事与QA相关的活动, 比如博客阅读或写作, 或参加IT或QA论坛和组织?
是什么意思? 测试效果 and 测试效率 ，你能提供过去或假设的例子吗?
测试有效性一般是指发现的有效的和可解决的缺陷的相对数量, 而测试效率意味着衡量在测试过程中所花费的时间和资源. 根据候选人的具体经验，对这个问题的回答可能是 简单总结一下 或者发展成一篇关于 测试度量工具和分析 . 这里的要点是通过正式评估QA工作来探索申请人的理解和经验.
在QA中，测试和质量哪个更重要?
重要的是要记住，最终目标是质量, 测试是实现这一目标的关键手段.
你如何区分优先级vs. 带有缺陷报告的严重性? 您能否给出过去或假设的严重程度高但优先级低的缺陷的例子, 反之亦然?
一个 基本和简单的问题 , 但这仍然是一个合乎逻辑的练习, 这样就可以观察到申请人在回答问题时的敏捷性.
您是否遇到过很难为其生成测试用例的系统或GUI? 如果是，为什么?你是如何完成这个循环的? 相反, 您是否见过一个非常容易编写测试用例的系统或GUI, and why? 详细说明您所发现的一个或两个最困难的缺陷, 你是如何找到他们的, 以及为什么它们很难被发现.
这个话题很有价值，可以让你更深入地了解候选人的逻辑思维, intuitive, 而演绎心理过程的功能，以及进一步说明相关技能.
深入考察候选人的调查能力, 是时候换一种方式，更广泛地审视他们的简历了.
评估类别#2:技术专长、专业经验和职业目标
第二个要涵盖的主要领域是技术技能和熟练程度, 包括扎实的专业经验的展示. 这既包括一般的技术和软件开发主题，也包括特定于qa的方法和工具.
因此，如果你能了解应聘者对某些问题的理解程度，这是很有帮助的 核心开发和QA术语. 正如本指南开头所提到的, QA领域的许多关键术语和相关概念一直处于争论中. 这样更好! 这可以让面试官深入了解候选人对术语背后的概念和动态的特定观点.
回顾与特定平台相关的技能绝对是值得的, 技术, 方法, 和工具 在组织的IT项目中使用. However, 即使候选人在这里缺乏经验, 一个可靠的QA工程师几乎肯定能够学习和适应新的工具和技术——你之前的经验主要是额外的.
面试官也想了解应聘者的能力 期望与抱负 当谈到职业目标时. 如果有的话，他们更愿意在QA团队中扮演(或避免)什么角色，为什么? 他们希望在贵公司获得什么样的就业机会? 他们希望自己的事业在不久的将来以及未来的道路上如何发展和进步? 为了实现他们的目标，他们计划做什么?
技术熟练程度、概念和术语
让我们继续进行更深入的问答环节, 涵盖与技术人才有关的各个领域. 探索申请人的知识, 理解, 熟练掌握通用软件开发和QA概念, 方法, and terms.
注意:说到术语， 国际软件测试资格委员会(ISTQB) publishes 一个有用的和全面的资源 列出了数百个术语和相应的IEEE/ISO章节、交叉引用和同义词.
找出他们在与QA团队和流程密切互动的领域中是否具有潜在的跨职能技能. 这些可能包括之前作为软件架构师或开发人员的工作, 单证员, 项目经理, or DevOps engineer; or, 也许在非it领域有更相关的经验, 比如在制造质量控制方面.
另外，一定要包括关于脚本的问题 SQL / data-tier-related问题, 考虑到编码和后端技术是整个软件和测试项目中常见且重要的元素.
以下是一些问题，可以根据应聘者的个人资料和目前的面试流程来定制:
问:请解释软件开发生命周期(SDLC)中的各个阶段，并对您熟悉的不同开发过程模型做一个简短的总结, 比如瀑布, Agile, 以及敏捷的子类型，比如Scrum.
了解申请人对…的理解和熟悉程度 SDLC和开发过程模型 . QA反映了软件生产过程中的SDLC, 通常在人生的每一步都扮演着重要的角色. QA不仅有助于确保产品无缺陷, 但同时也有助于优化开发过程.
问:描述一下软件测试生命周期(STLC)阶段，以及这些阶段是如何与SDLC相互关联的. QA应该在开发工作的哪个阶段开始参与项目, 在做决定时应该考虑哪些因素?
STLC之前是否在第一个书面面试部分被提及, 这将帮助您更详细地了解STLC阶段和申请人的理解 这些是如何与SDLC相互连接的 .
一般, QA应该尽早加入游戏, 大多数情况下，这意味着从SDLC开始. 例如, 开发周期处于概念阶段, complex, 原始的消费者软件产品肯定会从完全集成测试周期和预先开发中受益.
However, 对于较小的内部项目，在开发的最初阶段可能不太需要QA投入，内部用户人员直接向内部开发人员解释详细的规范，这些开发人员在日常设计和编码应用程序将使用的架构方面非常熟练.
问:您有编写测试策略文档的经验吗, 您能概括一下测试策略文档可能包含的内容吗? 你认为一个有效的测试策略的例子是什么?
测试策略文件概述了为了实现测试相关目标而要使用的总体测试标准和方法. 它们可以应用于较高的组织级别，或者更具体的阶段和测试计划级别. 各种潜在剖面 可能包括在内.
确定 什么样的测试策略可能是最佳的 对于一个项目或阶段取决于复杂的因素和考虑. 这个问题的答案没有对错之分.
小测验:核心QA术语和概念
这些问题较短，但仍然值得一问. 就几个核心QA术语和概念向应试者提问:
讨论:测试类型
测试类型的主题是QA的一个关键方面, 而且是宽泛的, complex, 很难组织. There are 超过一百个可识别的术语 用于不同类型的测试. 这就是为什么许多指南只是简单地询问一些类型或测试类型相关的问题，但我们认为这个主题值得更多的关注.
测试类型反映了必须采用的许多真实世界的方法，以覆盖重叠的因素, 比如项目/应用类型, bug types, 当前的STLC阶段, 谁来做测试. 在组织测试类型时，可以采用以下一些有用的方法:
高级分类:
共同特征:
在开发和QA生命周期的哪个阶段可以使用给定的测试类型?
哪些测试类型可以用于不同的项目概要文件, 例如web应用程序或移动应用程序?
哪些测试类型可能相关 手动测试vs自动测试 ?
哪些测试类型可能由不同角色的人执行.g.，开发人员，测试人员，最终用户，项目经理，内部销售人员等.?
要求应试者以这种开放式的方式复习常见的和主要的考试类型以及基本的相应特征，这是观察他们对考试的熟悉程度和技能的一个很好的方法, 他们对这些核心测试类型的知识和专业知识, 还有一个额外的好处:他们的沟通能力，在飞行中组织和列出它们.
针对更具体的测试类型或相关的动态问题提出量身定制的问题也很有价值——无论是作为上述自由形式问题的替代方案还是补充. 最重要的三个细节是:
What is 回归测试 , 这种类型的测试有哪些优点和缺点, 回归测试有哪些不同的子类?
什么是冒烟测试，什么时候自动化这种测试类型是一个好主意? 比较与对比 烟雾测试和健康测试 .
使用什么类型的测试 测试基于web的应用程序 , 你会对基于web的应用程序进行哪些特定的测试, 以及运行它们的有用工具是什么?
与测试类型相关的术语可能与其他术语交叉引用，或者以不同的方式同义. 重要的是，候选人在这两个方面都涵盖了测试类型的完整横截面, 以及你们公司特别强调的.
问:在SDLC过程模型中，您对哪一种更有经验?您更喜欢哪一种, 或者不喜欢, 与质量保证部门和STLC一起工作? Why?
这将让你了解应聘者的洞察力和经验，了解SDLC过程模型(如Scrum或瀑布)如何影响和相互关联QA工作和STLC. QA工程师通常应该能够适应不同的开发方法和理念. However, 与之前关于SDLC的问题相关联, STLC, 测试策略, 测试类型, 了解他们是否有意见和见解，哪些方法可能是更好的选择取决于项目, 发展, 和QA相关因素, and why. 鼓励候选人解释他们对这个话题的任何显著偏好.
Again, 这里没有错误答案, 但是有机会看看申请人是否知道他们在说什么, 也能专业地为自己的观点辩护, 用事实.
问:你对特定的自动化脚本语言有什么经验和熟练程度? 您喜欢编写基于代码的脚本吗?为什么? 当谈到学习新的编码和脚本语言时，你认为自己是一个快速学习的人吗?
一定要明确地覆盖 自动化脚本 和编码能力，包括任何 特定语言 与组织的项目相关.
数据技术是许多系统架构的一个组成部分, 对系统的稳定性起着关键作用, 可伸缩性, 表演。, 功能, 和可维护性. 因此, 后端测试是许多测试周期的重要组成部分, 要么通过GUI间接地实现，要么直接在数据层上实现.
一些测试周期可能不涉及与数据相关的技能, 其他人可能有高级的SQL技能, 但大多数项目都需要对后端数据和SQL技术有一定程度的理解和熟悉.
因此, 大多数申请人不需要是数据相关领域的专家, 但理想情况下, 他们至少应该熟悉 SQL语言 的基础知识 关系数据库管理系统(RDBMS)的原理和模式 (包括 存储过程 )，以及的概念 SQL vs. NoSQL数据库 . 探讨申请人在以下方面的潜在知识是有用和相关的:
数据错误和优化测试问题，如 数据完整性 and 参照完整性(RI) , 主要侵犯 , deadlocks , 数据损坏 , 数据丢失和数据泄露 , and 连接问题 以及关系数据库规范化(这是关于RDBMS性能的核心问题), 稳定性和可扩展性)
数据模式和编码概念，如 表、字段、记录(行)、索引、外键(fk) , 约束 , and SQL数据类型 , and 存储过程、触发器、函数、视图和FK级联更新/删除
先进的概念 商业智能(BI) , 提取变换与加载(ETL) , 数据仓库和数据集市 , OLAP和CUBE ，以及专有的SQL语言，如 PL / SQL (Oracle) , t - sql(微软) , and NoSQL数据库的UnQL变体
了解候选人在过去的QA项目中有哪些与测试和使用rdbms相关的经验, SQL, 以及NoSQL数据技术.
问:当完成测试执行时，您通常如何决定何时停止测试? 描述一个很难知道何时应该结束测试的情况, and why, 这个问题是如何解决的.
测试计划旨在定义基准和标准，以便知道何时应该停止测试. 但应用程序, 项目和过程是复杂的, 要确定确切的时间并不总是一件容易的事 测试已成功完成 .
鼓励申请人概述作出此类决定的标准, 描述一个具有挑战性的问题以及他们是如何解决这个问题的.
几个典型考虑因素的总结包括:
预算、截止日期和利益相关者的共识
测试覆盖率和测试用例通过率很高/高于基准
代码/功能/需求的覆盖率是令人满意的
缺陷发现/密度低/低于基准
高优先级和关键的缺陷和测试用例得到了满意的解决
更多的问题
There’s 还有很多问题 这可能会被问到未来的候选人，比如:
在这一点上，面试官应该对候选人的技能水平有一个很好的了解. 他们的具体经历呢?
简历审查
到这里为止, 应聘者职业经历的各个方面都已经被讨论过了.
现在是时候浏览应聘者的简历了，把他们完整的职业经历与之前的活动和问答环节联系起来, 将他们写好的简历与目前所学到的内容进行比较.
可能还有更具体的领域, 行业领域, skills, 以及候选人的履历, 以及与个性和行为特征相关的潜在标记，这将有助于更多地了解他们的专业和个性特征.
Next, 在简历审查之后，重点检查他们有使用经验的工具, 以及每一项的熟练程度. 在面试过程中了解应聘者的观点和意见.
QA活动是高度以工具为导向的, 如果不依赖于工具, 有数百种产品可用于行业内的所有功能和方面. 因此, 我们就不一一列举了, 但是很容易找到细节, 基于工具的资源分类列表.
正如前面提到的，对于候选人来说，了解每个特定的工具并不重要. 更确切地说，这是对候选人整体形象的一个额外部分的参考. 它可能会更清楚地说明申请人通常执行哪些能力, 或者他们更喜欢哪一种, 取决于他们最精通的工具类型或他们可能表达热情的工具类型. 这也将提供关于潜在培训需求的见解, 或者没有, 对于团队的新成员.
Who knows, 一个潜在的雇员可能已经精通某个特定的工具，而你的组织正在考虑改用这个工具, 并为决策过程提供额外的见解, 或者甚至能够带头对部门进行培训——这将是一个很好的胜利!
职业道路抱负和偏好，以及贵组织的项目
QA工程师在他们的职业生涯中经常扮演许多不同类型的角色. 技术平台, 系统架构, and coding languages may change from one project to the next; tools, 开发方法, and team structures will vary across their employment path with each organization; they might collaborate with test user groups in the morning, 与开发主管和DevOps工程师协调工作, 下午和管理层一起讨论最后期限和可交付成果.
QA候选人有时也会改变职业类型, 从软件开发或项目管理转到QA, or vice versa; or, 也许从IT转到非IT学科, 然后回到IT. And, 尽管对任何事物保持开放，并随时适应新的和不同的前景，这无疑是行业的基石特征, 无论是技术上的还是其他方面的, QA申请人可能有一般或特定的工作环境偏好和职业道路目标，这可能是很重要的.
So, 了解他们可能在寻找什么, 或者不去找, 关于他们当前和未来的工作环境和职业发展愿望, and why.
回答以下潜在的问题, 根据面试到目前为止对申请人的历史和专业知识的了解:
有没有哪种类型的软件/QA项目配置文件是你更喜欢使用的, 或者你想要避免的, 比如较大的vs. 更小的系统，更大的vs. 更小的团队规模，web架构vs. 移动或桌面，或其他相关项目的特点? Why?
在QA中有什么你更喜欢的角色和活动吗, 或者不喜欢, 比如制定计划和战略, 团队领导与管理, 跨职能的合作, 或者不同类型的测试, analyses, 和指标? Why?
你近期的职业目标和抱负是什么, 以及中长期, 你打算做些什么来成功地实现它们?
你觉得你能给我们的组织带来什么，能给我们的QA和开发项目带来什么?
你对我们公司有什么期望, 你对我们公司的理念有什么问题吗, 方法, 和项目?
Then, 对这些问题进行后续讨论，讨论组织中手头项目的性质.
评估类别#3:沟通、协调、记录和报告
面试官现在应该对候选人的专业QA履历有了一个近乎完整的了解. 第三个方面，一个优秀的候选人应该表现出卓越的表现和能力是沟通和协调, 包括书面文件和报告.
毫无疑问，良好的沟通技巧是任何团队成员在组织中担任任何职位或角色的理想品质, 前两节已经提供了充分的机会来评估这一领域. 也就是说，还有一些其他方面值得检查.
翻译摘要对应试者来说是很重要的, 将难以解释的想法转化为可理解的语言交流, 以及清晰的书面文本. Also, 他们应该自信, positive, 能够有效地与跨职能部门进行协调和互动, e.g.:
与团队领导和经理一起计划和组织高层次的流程和协议
报告在其他团队的设计和开发工作中发现的bug和错误
与测试用户和组协作
QA工程师不可避免地要解释和捍卫bug背后复杂抽象的逻辑和推理, 表演。, 可用性报告.
有时组织中的其他成员会不同意对测试结果的解释, 或者是测试结果本身, 候选人应该能够以积极和清晰的态度解决这些问题. 测试人员还需要冷静而自信地处理有关bug的缺陷逃逸率，这些bug即使在最严格的测试过程中也会一直溜到生产过程中.
候选人必须以一种高度合作的方式参与这一切.
考虑到IT努力的最终目标是确保为组织产品的最终用户提供积极和无错误的体验, 沟通, 文档和报告是QA工程师角色中的关键元素. 他们必须通过清晰地传达准确的解释以及与QA发现相关的相关概念和动态来有效地支持用户. 这包括当最终用户是内部管理人员和人员时, 例如管理公司流程并在维护健康组织中发挥关键作用的内部应用程序.
在这个评估类别中有三个小节需要审查:
一般的沟通风格和方法，包括与QA团队成员的互动.
跨职能的协调和协作.
文档和报告技能，包括投资组合演示.
沟通和QA团队协作风格和方法
进入面试过程的最后一部分，对应聘者如何看待自己是一个沟通者进行开放式的回顾和讨论, 包括他们在不同互动情境中的自信程度.
要求他们将自己的沟通风格和方法与他们喜欢与团队QA工程师合作的方式联系起来. 与其他QA人员进行积极有效的互动和协调也同样重要，因为他们将与其他QA人员进行更频繁的接触, 发展也是如此, 组织中的管理和其他非qa角色. 在QA团队中存在分歧和不同观点的可能性与跨部门合作者一样多.
这部分不需要有特定的结构, 面试的前几部分应该通过以下这些话题和问题来帮助建立一个自然的进展:
他们认为自己的优点是什么, 还有弱点, 关于他们的一般沟通方式, 以及这与QA团队成员之间的互动有何直接或间接关系?
应聘者认为自己内向吗, 性格外向的, /都没有, 还是取决于具体情况? 如果他们处于压力之下，他们的工作沟通方式会发生怎样的变化, 比如截止日期或其他压力?
什么时候以及为什么他们会感到更自信, 或者更担心, 让他人参与到与潜在分歧相关的话题中?
在工作中，当存在某种程度的分歧时，他们倾向于如何处理和处理沟通? 他们能否举出过去QA团队成员或其他同事的例子?
应聘者会说，过去的同事会如何描述他们在积极话题和潜在消极问题或分歧上的自信程度和沟通风格?
他们更喜欢在QA团队成员或其他同事身上看到什么样的态度和沟通风格, and why?
确保在可能的时间和地点询问与他们的评论和答案相关的真实例子.
跨职能协调和报告
Next, 接下来谈谈候选人在与软件开发人员和架构师一起工作时的观点和经验, 项目经理, DevOps 工程师，以及与QA定期合作的其他部门的人员. 还要了解他们可能与测试用户和测试组有什么样的联系和交互.
这些交互通常更加形式化，并且是间歇性的, 并与过程的关键领域相关，例如计划和战略制定, 审查和报告流程和生产力, 并与其他部门解释和总结测试结果和方法. 我们建议从以下问题中选择:
考虑到QA的基本角色不仅仅是对组织的软件产品进行评价, 而且还要对相关的开发过程进行审查并提供反馈, 策略, etc., 在与程序员和其他部门合作的过程中，你是否尝试过为项目注入积极元素?
你能否举例说明你与领导密切合作时的积极或消极经历, managers, 以及其他部门的团队成员? 发生了什么，你是如何处理这些情况的，它们最终是如何解决的?
当你必须为自己的失误或疏忽而影响到其他部门时，你会如何处理这种情况, 例如，您负责执行的测试过程中漏掉了一个潜在的重要缺陷, 然后在产品发布中结束, 可能需要付出努力, resources, 甚至可能对客户产生影响, 为了补救? 你能从过去的项目中想出一个这样的例子吗?
对于其他人不同意或质疑的测试方法或测试结果，您如何处理和处理来自非qa人员的阻力? 你能描述一下以前项目中的具体例子吗?
你是如何处理这样一种情况的:你对某一点的反馈有强烈的感觉，但你还没有向开发人员或其他部门传达, 但你相信他们可能会不同意你的发现, 和/或消极反应?
您与测试用户和测试用户组打交道的经验是什么, 在这种互动中，有什么特别积极或消极的东西吗, and why?
文档风格、方法和组合示例
文档和报告在QA的每个阶段和过程中都是必不可少的. 每个候选人都应该表现出对该领域技能的熟悉和适应.
面试前, 要求他们带来一到两个过去QA文档和/或报告的作品集样本，这将有助于说明他们基于纸张的熟练程度. NDAs or other factors may prevent this; in that case, 要求他们准备一些他们有经验的QA文档或报告的虚构例子. 其他类型的非qa作品集样本可能取决于申请人的历史, 例如与软件设计和开发相关的内容, 项目管理, DevOps, or data analysis; at minimum, 任何形式的技术写作都应该是有用的. 面试官也可能会提前要求为这个部分提供一种特定的样本.
首先浏览申请人提供的文件，并讨论相关要点. 如果没有可用的演示, 或者继续下面的言语部分, 或者就为什么文档和报告组合不是一种选择进行简短的对话.
Next, 向候选人提出一些问题，以便更好地了解这个领域的具体技能, 例如:
你认为文档和报告在QA领域是重要的还是不重要的, and why?
在你的QA工作经历中，文档和报告扮演了什么角色?
关于文档和报告，您有喜欢或不喜欢的地方吗?为什么?
你最喜欢什么?, 你最不喜欢的是什么, 文档和报告类型(或相关任务), and why?
你能快速总结一下各种各样的吗 可交付成果、工件 ，以及QA部门的报告?
除了QA之外，你有其他类型的文档和报告的经验吗, and if so, 这些与你在QA中的纸质工作有什么关系?
一如既往，鼓励申请人提供有意义的例子.
测试器现在已经过测试
在这篇招聘指南中，我们深入研究了质量保证过程. 这样做的时候, 我们已经清楚地描绘了面试官需要知道的一切，以便做出最好的雇佣决定.
通常很难衡量QA工程师的一些重要软技能和特征. 这包括坚定的自信, 逻辑推理和技术调查的演绎和直觉能力, 以及无畏而积极和团队导向的沟通方式.
但我们的做法是让面试官“免费”回答这些难点,可以说, 在更典型的面试环节. 通过几个简单(但有些密集)的练习和对候选人及其经验的全面回顾, 技术技能组合, 文档的方法, 还有投资组合样本, 面试官可以把潜在的QA评估障碍变成黄金机会.
我们希望这份指南能帮助你对你的候选人获得准确而有价值的见解, 最终, 你不仅可以雇佣优秀的QA/测试工程师, 但也适合你的团队.
