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

StackOverflow https://stackoverflow.com/questions/1338588

  •  20-09-2019
  •  | 
  •  

题

我们即将进行一些面试，正在招聘质量保证职位。开发人员参与的目的是了解此人是否能够与开发团队良好合作。

最有哪些 重要的 开发人员应该问 QA 人员的问题？我正在寻找实际问题，而不是空洞的开放性问题，你的想法是什么？

有帮助吗？

解决方案

不幸的是，有时，一些模糊的开放式问题才能让你更好地了解一个人。

任何 技术的 根据您提出的问题（这些问题在很大程度上取决于您的开发方法，因此我无法真正帮助您，它们应该是量身定制的），您应该始终确定潜在候选人将如何在团队环境中工作。

您需要确定：

  • 这个人会在团队中工作得很好。
  • 该人将负责与开发人员合作修复错误，而不仅仅是“这是一个错误，去修复它，然后回复我”。
  • 个人的自我意识不会妨碍团队的工作（例如为错误的分类或严重性而争论）。我发现这通常是开发人员对“他们的”代码采取防御措施时遇到的问题。

我发现面试中最好的方法是呈现场景并询问候选人的想法，例如：

  • 现在是周五下午 4 点，开发人员 Bob 同意返工修复一个高严重性错误。我们需要一名测试人员来验证修复结果，而您是唯一可用的测试人员，但您已经安排了晚餐。你会提出什么建议？

仅根据该问题的答案，您就可以评估候选人是否：

  • 没用（“对不起，我不能错过晚餐”）。
  • 认为外部限制（“有没有 真的 没有其他可用的测试人员？”，“我可以在周六早上验证它吗？”，“鲍勃可以在周末的其他时间工作吗？”）。
  • 适应性强（“我可以推迟一次晚餐”）。

等等。

我无法强调沟通技巧对于开发人员/测试人员关系的重要性。让测试人员生成一份粗略的错误报告（他们想要的任何错误）并讨论其充分性（确切的步骤、预期行为、实际行为……）。

其他提示

除了本线程中更深入的答案之外，还有一个经常被忽视的简单问题：

您能像普通用户或无经验的用户一样行事吗？

现在，这看起来很愚蠢，但它提供了非常好的见解。如果候选人说“是”，坦率地说，他们就不是他们看上去的那样。任何在信息技术领域从事开发（特别是）、分析或测试工作的人员都无法做到这一点；只是因为我们已经远远超出了没有经验的用户的水平。您应该寻找的答案是：

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

或者它的衍生物。这显示了一些重要信息。

  1. 他们很现实
  2. 他们可以跳出框框思考
  3. 他们愿意执行质量检查中规定的正确方法

至少这是我发现的。

希望这能以某种方式有所帮助。

我的建议是考虑一些开放式的问题，如下所示：

如果我走到你身边说：“你能测试我做的新事情吗？”您的前几个问题是什么？

以下是我提出这个问题时的一些想法：

  1. 是否提及规格或要求？如果没有，这对测试有何影响？
  2. 他们想让我和他们配对以便他们知道我做了什么吗？
  3. 他们想知道我做了什么吗？
  4. 他们有时间这样做并询问我认为这可能需要多长时间吗？
  5. 您期望进行什么样的测试：综合、烟雾测试、走廊可用性？
  6. 将使用什么类型的工具来完成此操作？

在录制错误时，您认为开发人员在修复它之前应该拥有什么？

这种问题的类型取决于他们的背景，这可能会成为他们回答的一个因素，需要注意的一些事项包括：

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

我提到其中大部分是因为这就是我在询问他们最初有哪些参数时所想的，当给出一个模糊的问题或请求时，应该有更多的细节，但哪些细节重要是问题。我还会注意到给出答案时需要停顿多长时间，我认为 15-30 秒就可以了，如果少一点，我认为这是一个预期的问题，如果需要超过这个时间，那么应该有请求花几分钟时间考虑一下，因为重点是，当这种情况出现时，双方的期望是什么？

另一个想法是提及您使用的软件开发方法，然后询问使用这种方法与 QA 相关的挑战有哪些？例如，如果开发人员使用 TDD，这会对 QA 产生什么影响？如果这是一种更像瀑布式的方法怎么办？你想在这里看到的是，他们的思考能力如何，以及关于使用什么的后续问题会被问到，如果我说我们使用 Scrum，那么这对通用的实现的定义效果如何？ Scrum 的概念，确实如此。

一个开发者可以通过给他的场景检查哪个应检查以下

<强>姿态

做测试仪拥有一种探测的态度呢？给他一个场景，并检查有多少有效的问题时，他/她问？

<强>技能

相关检测几个技能是必需的，你在工作的每个项目，它包括需求研究，测试设计，测试执行等。检查有多好理解需求的测试。

<强>知识

检查测试的广度和深度在你要去哪里招募测试仪领域。即使测试仪不能在当前外地工作，检查多少测试人员对上述了解该领域。

<强>渐近

给测试人员的场景像有一个客户端的问题，开发商休假整个星期。这个问题亟待升级，并为测试它来给你找到问题的根源。你怎么会在这种情况下接近

我们在软件质量人员中寻找的一些关键要素：

  • 沟通 - 候选人能否以清晰简洁的方式撰写/发送电子邮件/讲话，以便团队的其他成员能够理解他们发现的缺陷
  • 解决问题 - 这就是那些面试难题派上用场的地方。对于这些类型的问题，更重要的是了解候选人将如何解决问题，而不是他们距离确定“美国有多少辆蓝色汽车”有多近。
  • 责任 - 了解候选人是否会坚持下去很重要。这个问题很难找到真正的答案，因为人们在采访中都很热情，可能同意很多，但并不是真心的。候选人过去关于他们如何处理问题的故事可能会有所帮助。如果候选人的问题变得更糟并且他们能够控制住问题，则可以获得奖励分。
  • 技术专长 - 该项目所需的级别会根据测试者的不同而有所不同：他们会编写自动化测试吗？手动测试？自动化测试至少需要一定程度的技术专业知识，而手动测试则需要较少的技术专业知识。不管怎样，拥有一个至少熟悉应用程序技术方面的测试人员在解决问题时会非常有用。

我认为这实际上取决于您正在寻找的测试人员类型。您是否正在寻找一个人来按下按钮并告诉您它看起来不对劲，或者您是否正在寻找一个能够理解技术甚至代码并发现更深层次错误的人？作为面试循环中的开发人员，我想也可以使用传统的 QA 类型。如果是这样，他们会提出典型的测试问题。您需要了解它们的技术水平以及它们如何交互。考虑到这一点，尝试回答以下一些问题：

  1. 编程问题。 看看简历。他们懂 C# 吗？JavaScript？请他们为您编写一些代码。他们知道的越多，就越能更好地报告错误。
  2. 处理问题。 他们了解源代码控制吗？他们用过吗？他们了解构建的概念吗？他们熟悉单元测试吗？
  3. 软件开发问题。 他们了解 dll/程序集/jar 是什么吗？他们知道记忆是如何运作的吗？他们是否理解用户模式和内核模式之间的区别（或适合您的领域的任何模式）？
  4. 技术问题。 他们对您的领域了解程度如何？他们了解小部件行业的动力是什么吗？他们知道客户正在寻找什么小部件吗？他们曾经使用过小部件吗？
  5. 他们是否深入了解自己的错误？ 询问他们最喜欢的错误。他们能告诉您多少有关问题所在的详细信息？
  6. 他们能抵挡得住你吗？ 当开发人员逼迫他们时，这种类型或测试人员会退缩还是会战斗？询问他们是否有一次尝试完成某件事但遭到反对。他们有何反应？
许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top