在面试中与候选人进行配对测试

#1 楼

是的，会的。我喜欢成对地执行探索性测试的团队，我认为共同编写章程，创建思维导图和确定启发式方法要比单独做起来容易。它将使您更加聪明，您将更快地执行和分析结果。

我想在采访中找到以下问题的答案：


您的团队喜欢与他/她一起工作吗？
他们可以设计好的测试用例吗？
他们可以以自由格式产生可重复的结果吗？

看看别人会如何进行配对测试非常有价值。它是关于沟通和测试设计的。此外，您还会注意到某人是否是快速学习者。他们可以领导会议并在与其他人一起工作时获得一些结果吗？他们在会议期间如何回应重要反馈。

探索性测试会议具有时间限制，因此非常适合进行第二次面试。您可以在一个45分钟的时间范围内执行该操作，并与测试人员同事合作。然后，与招聘经理一起审查结果。例如，给应聘者一个空间来解释他们下次会做些什么。我接受了大约1.5个小时的采访，这是可以接受的。

或者，我将在一个简单的应用程序上进行自动化测试的配对编程。就像我总是会为开发人员进行成对编程面试一样。

#2 楼

好点子。一些可能会有所帮助的事情：


代替配对测试，只需说明基本上下文并让应聘者弄清楚即可。一个很大的好处是您会感觉到：


这个人问几个问题？
什么类型的问题？是否相关？
该测试仪的独立性和自信程度如何？


量化结果不是硬科学，而是：


可能会发现一些（严重或严重）缺陷。他发现了多少？
通过定期面试，如果我们不考虑针对开发人员的技术测试，通常会遵循自己的直觉（这种性格适合我们的团队吗？他会表现出正确的态度吗？ ）。如果您确实看到并听到有人进行测试，那么您还有很多事情要做：现在，简历和谈话是否符合预期的技能将变得很清楚！



另外，如果这个人要进行自动化测试，我列出了一些您可以在此处提出的问题。

#3 楼

对于手动测试人员，我已经做了类似的事情。我整理了一个包含3页的MVC快速站点，并在每页中放入了“问题”（总计11个问题）。我明确表示，我并不是在寻找受访者来查找所有问题。我只是想看看他们如何做。


他们打开了DevTools吗？
他们是否彻底测试了输入？
他们是否注意到了非功能性问题？ ？

我与每个候选人共坐了30分钟，并试图尽可能友好和乐于助人。这是一个压力很大的情况，这也是我一直在寻找应聘者要处理的事情。

最后我只做了一次，因为这非常耗时，而且我开始只填补更多的Sr我团队中的职位。

#4 楼

非常有趣的话题，尽管这个问题已经在两年前提出，但它仍然是当前话题！因此，我想分享我们的经验/想法。

我们作为业务部门的准备工作：


我们使用了Web应用程序
在开始解释产品之前，我们鼓励
申请人“大声”说出他所有的步骤，以便我们可以在测试过程中跟着他
我们还准备在墙上显示屏幕，如果用户想使用移动设备进行测试（例如，如果有一个用户这样做，您可以在面试后问他为什么还要使用移动设备，有时用户会说明移动浏览器测试和“正常”浏览器应用程序之间的区别，因此这意味着用户也会以某种方式考虑“更广泛”测试方式）
我们还提供了一个董事会，供候选人做笔记。其中一名候选人写了某种端到端测试（一些简短说明），很有趣的是看到候选人的工作方式

我们从配对探索性测试中学到了什么？


个人测试方式：该人如何测试Web应用程序？ （通过大声说出来，我们也可以跟随他并了解他的程序和想法），有时我们随后在测试案例中添加该人的想法：-)
候选人的交流：该人要问几个问题在开始测试之前会问什么？ （在测试人员的日常生活中，您还会向产品负责人，开发人员，需求经理等提出问题。因此，在这里我们还可以弄清楚这个人的沟通能力）
另一个不错的想法是：在测试应用程序时，有时我们还可以找出做错了什么或缺少哪些新要求。因此，我们记下了很好的要求，并在以后与产品负责人进行了讨论。有时，在面试中进行配对测试时，您可以创造出好主意
Bugs：同时，检测缺陷确实不是主要任务，因为我们在生产前环境中进行了测试。
候选人的测试方法：最后，我们很高兴看到候选人正在接近。这也帮助我们获得了有关候选人是否适合我们团队的反馈（最好是您应该邀请我们的一名测试经理/测试人员进行探索性配对测试）
熟悉工具：还有一名候选人正在开放免费开发人员-tool（自动写入日志），您还可以看到，这些候选对象也正在使用工具并对其很熟悉

#5 楼

我不会拒绝已发现问题的数量作为相关度量。毕竟，您正在寻找将在您的应用程序中发现缺陷的工程师。

对我而言，任何面试都应着重于两种人的技能：硬性和软性。我倾向于考虑两种类型的面试：一方面，一个人向您展示了他们将如何测试特定组件（这是您选择代表代表申请进行面试的责任）；另一​​方面，这个人则向您展示了他们如何进行面试。将他们的想法传达给队友。

由于您无法（使用任何客观标准来衡量）一个人的软技能，因此只能依靠：


发现的问题数量。
速度（如果您具有找到的问题的目标值）
需要进行任何论坛探索的问题数量
进行这种探索所花费的时间
找到成功解决方案的上一问题的数量
进行这样的探索所花费的时间
讨论所花的时间使合作伙伴确信该问题实际上是一个缺陷。
讨论所花的时间最终被认为不是-a -bug

但是，如果这是您要在面试中采用的唯一方法，则应注意面试申请的“质量”，因为它可能无法涵盖所有​​代表性案例可以在真实的项目生活中相遇。

#6 楼

这是一个非常有趣的话题，我进行了几次类似的访谈，这是基于访谈的反馈：


您可以评估候选人在给定范围内发现错误的能力时间线。
您可以评估候选人首先关注功能或非功能性问题的能力。
您可以判断候选人的测试方法
候选人的沟通方式，他们如何沟通错误到开发团队。
应聘者的兴趣是，应聘者如何与应用进行交互，以及他如何询问有关产品的问题，他们是否能够开箱即用地思考

但是，这些不仅是要点，还可以根据职位要求根据其他条件评估候选人。

#7 楼

我认为这比问“五年后您在哪里看到自己？”之类的问题要好得多。等：）

让我分享一些我认为很重要的观点：


关于被测试的应用程序。我个人选择一个我知道的，然后选择一个至少可以发现一些错误的地方。那是因为我希望看到候选人报告问题，或者至少也要谈论（可能）问题。
会议应该有一个特定的时间段，根据您的情况，我会尽量30至60分钟。
在开始和/或向候选人介绍之前，我会让他们分享他们对此类探索性会议的想法以及他们如何做到的。您可以从他们的答案中找出他们是否知道如何组织此类探索性会议。
在会议期间，让他们交谈。这很重要，因为您可以看到他们如何沟通，如何进行探索，如何讨论问题，如何提出要求。测试人员应该能够很好地沟通，这是一种找出答案的方法。
我对量化结果有些怀疑。为什么需要这样做？是因为HR要求您这样做吗？就像无法完全量化探索性测试一样，而您也不希望这样，我也不一定要使面试的质量可量化。如果您确实需要量化某些东西，那么错误数量就不应该了。我宁愿创建一个清单，列出测试人员想知道的重要事物/技能（在探索性会议和面试中可以找到答案），并计算对每个候选人进行的检查次数。或者，您可以使用定义明确的技能水平来创建自己的音阶。您可能会问人力资源部，该怎么做，我想他们在这方面有一定经验。

总而言之，我认为看到候选人在工作中会带来有关他们如何适应的宝贵信息。您的团队/公司。这样的会议只是一个简短的窥探。