在Agile Testing Days 2015上，Marnix van den Ent做了一个报告，在报告中他解释了测试员如何标志并且质疑（测试）过程。他将测试员们看成一个丑角这个观点：“一个团队和团队进度的仆人，像意大利的丑角一样，测试员在那里帮助大家理解发生了什么”。
　　小编有幸采访了Van den Ent：测试如何被看作提出问题、测试员能做什么来发展询问的艺术、以及一个敏捷测试员如何标志并质疑过程与实践、测试员可以适应并使用的XP实践和测试员如何在追溯会议中作贡献。
　　小编：你提到测试员用测试对产品提出质疑；他们天生富有问问题的能力。你可以给一些测试可以被看作问问题的例子吗？
　　Van den Ent：在测试象限中，Brian Marick将支持团队的测试与批判产品的测试区分开来。个人可以看出问封闭和开放问题的不同。
　　并且，探索性测试是一个极好的例子，在这种测试中我们通过对被测系统提出开放性问题。在有些测试中我们不知道系统的回应——但是我们可以确定真实的回应是不是全部正确。系统行为是什么？一个测试可以让这个问题变得有形，例如一个具体的场景：当一个用户用合法的用户名和不合法的密码登录了三或四次系统，但是在这三到四次登录中间关掉会话很长一段时间，系统会做出什么反应？
　　小编：测试员可以做些什么来发展提问题的艺术，并帮助敏捷开发团队交付更好的产品？
　　Van den Ent：这种帮助可能会发生在两个层面上。第一，当看待“我们如何测试产品”时，我们有几个方法来实现。帮助我们弄清楚测试是关于什么的方法是学习（老派的）结构化测试，其中测试活动和测试职责是针对单独的功能、单独的阶段和单独的任务等。这种拆开的方法帮助我们弄清楚在测试中我们要处理什么。并且它以某种方式声明了我们可以或应该怎样做测试。在语境驱动的测试学校，人们比其他测试学科的学校更多地研究怎么测试。这是“质疑产品的艺术”被培养出来的地方。
　　接下来，当我们着眼于其他层面来帮助团队交付软件：我们怎么样能帮助或改善他们工作的方式？这也许是Scrum管理者与敏捷开发指导擅长的领域。既然这样说，很容易推断出这种假定：责任都降临在了这些角色中而不是其他的人中。当我们做之前提到的测试时，你会面临那些团队在开发过程中做决定的后果。所以，作为一个测试员可以看出这些决定的弊端。那时，一个人学会看这些决定并对自己和他帮助改善开发过程的团队提问题。这种问题应该针对一个相对广阔的范围，因此很难阻止它进入一个固定的模式。你甚至不能说封闭性问题不好，因为在某些情况下你也许需要驱使它。
　　小编：你可以详细阐述一下敏捷测试员如何标志并对团队和团队周围的组织中用到的过程和实践提出问题吗？
　　Van den Ent：像我之前说到的，当做测试的时候，个人可以观察局势。例如，如果重要的用户故事（应该早被开发的用户故事）的后一轮测试只可以在第二个冲刺的一半做，你将有预感过程不会像那样乐观。假定用户故事不会像可以问做了什么决定一样大；例如，团队有没有在同时做几个故事上达成统一意见；为什么？
　　一个不同的情况是一个（外部操作的）产品负责人相信他和团队成员的电话交流足够好，所以他只在一个冲刺中与团队见一次面。在这种情况下，结果表明，产品负责人与管理人员的意见一致阻止了这种情况——然后，也许强烈的个人说服力终究会帮助我们改变这样的情况。
　　小编：你有一些测试员可以在敏捷开发中适应并使用的XP实践例子吗？
　　Van den Ent：我个人发现了极限编程是一个很好的资源，测试员可以从中学到“新的”对他们团队有用的实践。在极限编程中，一个实践是共享代码所有权。测试也是这样。有很多这样的团队，其中测试员都有自己的技巧并且他们完全信任自己这样做。这不是很好。团队中的测试员应该意识到共享想法、“设计”测试用例的方法以及帮助提高测试质量和效率的测试。配对和广泛的审查是一个可以令他们做到这点的方法。
　　XP还有“简单”这个价值。在很多的情况中，测试员很简单能前进。但是也有很多情况中，被测试的行为取决于很多参数、值和它们的组合！使这样的测试保持简单才是与团队成员和关键用户交流你的测试的关键。
　　小编：你可以解释一下，在你看来，是什么使追溯会议在敏捷开发中如此重要？测试员怎么对追溯会议做贡献？
　　Van den Ent：首先，我要感谢你问出这个问题！学习是敏捷开发的工作方式中一个关键的方面。没有学习没有敏捷。追溯会议是反映并提升团队工作的标准方式。你经常会听到说追溯会议像强制性的仪式一样无聊。但是那样的话，你没有在学习。保持开放性的思维和持续提出问题，以便提升团队的过程，这样能帮助整个团队学习。测试员天生富有问问题的能力。测试员应该学习不仅仅只对产品提出问题，也应该向团队和过程“提出”问题。