开发人员应该问测试人员哪些面试问题?

不幸的是,有时候,那些毛茸茸的开放式问题会给你一个人最好的视角。

无论什么 技术的 您提出的问题(这些问题很大程度上取决于您的开发方法,因此我不能真正帮助您,应该对它们进行定制),您应该始终确定潜在候选人在团队环境中的工作方式。

您需要确定:

• 这个人在团队中工作得很好。
• 这个人将负责与开发部门合作来修复bug,而不仅仅是“这是一个bug,去修复它,然后再返回给我”。
• 这个人的自我不会妨碍团队的工作(例如为错误的分类或严重性而斗争)。我发现这通常是开发人员对“他们的”代码采取防御措施的问题。

我发现面试中最好的方法是呈现情景并询问应聘者他们的想法,例如:

• 现在是周五下午4点,开发人员Bob已经同意回去修复一个高严重性的bug。我们需要一个测试人员来验证修复,而您是唯一可用的,但您有晚餐安排。你会提出什么建议?

只需回答这个问题,你就可以评估候选人是否:

• 没用(“对不起,我不能错过晚餐”)。
• 考虑外部约束(“是否存在 真的? 没有其他检测仪可用吗?”“我能在星期六早上验证它吗?”“鲍勃能在周末另找时间工作吗?”).
• 适应性强(“我可以把晚餐推迟一次”)。

等等。

我也不能强调沟通技巧对开发人员/测试人员关系的重要性。让测试人员生成一个粗略的错误报告(他们想要的任何错误),并讨论它的充分性(确切的步骤、预期的行为、实际的行为…)。

除了这个问题的深层次答案之外,还有一个简单的问题经常被忽视:

你能表现得像一个普通的或没有经验的用户吗?

现在,这看起来很愚蠢,但它提供了很好的洞察力。如果候选人说“是”,坦率地说,他们不是他们看起来的样子。在信息技术领域从事开发(特别是分析或测试)工作的任何人都不能做到这一点;仅仅因为我们远远超过了缺乏经验的用户的水平。你应该寻找的答案是:

不,但是我可以创建能够准确映射到“所谓”正常用户行为的测试用例。

或者是这个的派生词。这显示了一些重要信息。

1. 它们是现实的
2. 他们可以跳出框框思考
3. 他们愿意执行质量保证中规定的适当方法。

这至少是我发现的。

希望这样或那样有帮助。

我的建议是考虑一些开放式的问题,比如:

如果我走到你面前说,“可以 你测试了我做的这件新事情?”什么 你的前几个问题是什么?

我想问一下:

1. 有没有提到规格或要求?如果没有,这对测试有什么影响?
2. 他们想让我和他们配对以便他们知道我做了什么?
3. 他们想知道我做了什么吗?
4. 他们有时间这样做吗?我想这需要多长时间?
5. 您希望进行什么样的测试:综合测试、烟雾测试、走廊可用性测试?
6. 要用什么样的工具来做这个?

在记录错误时,什么是 你相信的最低限度的信息 显影剂应在修复前 是吗?

这是一种问题类型,根据他们所拥有的背景,他们的回答可能会成为一个因素,需要注意的一些事项包括:

• 再现性-你能以一种可预测的方式得到它吗?
• 再现性步骤
• 这是代码、数据、网络还是其他类型的bug?
• 在某种程度上,这个错误有多严重?
• 环境-我需要什么才能让这再次发生?是否有特定的浏览器、操作系统或其他我应该拥有的东西?
• 说明这是一个bug的预期结果和实际结果是什么?
• 软件版本-这是在什么系统版本上找到的?

我之所以提到这些,是因为这正是我想问的问题,在给出一个模糊的问题或要求时,他们最初有哪些参数,应该有更多的细节,但哪些细节才是关键。我也会注意到在给出一个答案的时候停顿了多长时间,我会说15-30秒没问题,任何更少的问题,我会认为这是一个预期的问题,如果需要更多的时间,那么应该有几个分钟的时间来考虑它,因为总的来说,当这种情况出现时,每个SI的期望值是多少判定元件?

另一个想法是提及您使用的软件开发方法,然后询问使用这种方法与QA相关的挑战是什么?例如,如果开发人员使用TDD,这将如何影响QA?如果是更像瀑布的方法呢?你想在这里看到的是,他们能站在自己的脚上思考得有多好,以及关于所用内容的后续问题是什么,如果我说我们使用scrum,那么这对scrum的一般概念的实现有多好的定义,真的。

开发人员可以通过给他一个场景来检查以下内容

态度

测试人员是否具有探索性的态度?给他一个场景,检查他/她问了多少个有效的问题?

技能

在您工作的每个项目中,都需要一些与测试相关的技能。它包括需求研究、测试设计、测试执行等。检查测试人员在理解需求方面有多好。

知识

在您要招募测试人员的领域中,检查测试人员的广度和深度。即使测试人员不在当前字段上工作,也要检查测试人员对该字段了解多少。

接近性

给测试人员一个场景,就像有一个客户问题,开发人员在休假一整周。这个问题需要紧急升级,作为测试人员,它会找到问题的根本原因。在这种情况下,你将如何处理

我们在软件质量人员中寻找的一些关键项目:

• 通信 -候选人能否以清晰简洁的方式写/发电子邮件/讲话,以便团队的其他成员能够理解他们发现的缺陷?
• 问题解决 -这就是那些面试难题的用武之地。对于这些类型的问题,更重要的是了解候选人将如何解决问题,而不是他们将如何接近确定“美国有多少辆蓝色汽车”。
• 责任 -重要的是要了解候选人是否会坚持到底。这一个更难找到真正的答案,因为人们在面试时很热情,可能会同意很多,但并不真正意味着这一点。候选人过去关于他们如何处理问题或问题的故事可能会有所帮助。如果问题对候选人来说更糟,并且他们一直处于领先地位,就可以获得加分。
• 技术专长 -此项目所需的级别将根据测试人员的不同而有所不同:他们是否要编写自动测试?手动测试?自动化测试至少需要一定程度的技术专长,而手动测试则需要较少的技术专长。不管是哪种方式,拥有一个至少熟悉应用程序技术方面的测试人员在处理某个问题时都非常有用。

我认为这真的取决于你要找的测试人员的类型。你是在找人按按钮告诉你它看起来不正确,还是你在找一个能理解技术甚至代码并发现更深层的错误的人?作为访谈循环的开发人员,我可以想象还有传统的QA类型可用。如果是这样,他们会问典型的测试问题。你需要了解他们的技术水平和互动方式。考虑到这一点,尝试以下几种问题:

1. 编程问题。 看看简历。他们知道C?JavaScript?让他们给你编一些代码。他们知道的越多,他们就越能归档错误。
2. 处理问题。 他们了解源代码管理吗?他们用过吗?他们得到了构建的概念吗?他们熟悉单元测试吗?
3. 软件开发问题。 他们知道什么是dll/assembly/jar吗?他们知道记忆是如何工作的吗?他们是否理解用户模式和内核模式(或任何适合您的域的模式)之间的区别?
4. 技术问题。 他们对你的领域了解多少?他们明白是什么推动了微件行业吗?他们知道客户在寻找什么小工具吗?他们使用过小部件吗?
5. 他们在深层次上理解他们的错误吗? 询问他们最喜欢的bug。他们能告诉你多少关于问题的细节?
6. 他们能反抗你吗? 这是当开发人员推它们时会后退的类型或测试人员,还是它们会战斗?问他们一次,他们试图完成一些事情,遇到了反对者。他们的反应如何?