Ray Oei：我试图围绕一个故事、期望的产品或者任何看上去重要的东西发现尽可能多的问题。创建一个我们正在构建产品的模型，和思维图有助于我组织测试。提出问题。如果可能的话调查研究。我发现当我听到程序员讨论事情的时候，我经常想起一些需要测试的内容。我会遍历代码。当有人告诉我，我不需要因为一些不明原因检查代码时，那么我肯定会看一眼代码。那是一个“计划”吗?如果你认为计划是开始测试前对某个时期的设想，那么它不是的。但是我又有测试的想法，并且我在努力尝试执行这些想法。而且说实话，事情的发展并不总是跟我预料的一样。有时在我有时间组织它们之前，我的一些想法已经过时了。我认为我的主要指导计划一个问题：“现在或者未来，这重要吗?”。
　　InfoQ：有没有一些您想推荐的具体的敏捷测试实践?
　　Eddy Bruin：有一大堆的敏捷测试实践：结对编程、实例化需求(ATDD/BDD)、TDD、大量的启发式测试等等。对我而言总是非常的一个实践是在所有测试活动中进行沟通。当规划测试、汇报测试和解决bug，甚至是当展示我们实际意图构建的产品和应该给公司带来什么产品时，我总是努力尽可能地透明化。为此我常用的策略是拥有尽可能多的信息辐射体。墙上的活动挂图、白板和便利贴越多，开始沟通越容易。
　　Ray Oei：不是具体的敏捷测试实践。我认为关键是沟通：交谈与倾听。或者更好的是：提出问题，并花时间倾听和理解。了解相关的领域和业务，和使用的技术。了解你共事的成员。同样发现你自己在那的角色和行为。我们倾向着眼于别人，认为他们应该/可以/必须完成的更好——但是你自己呢?
　　展示你正在做什么，已经做了什么。甚至如果需要，展示你犯错的地方。这有助于建立信任。这方面并不是航天器学，没那么复杂。虽然，作为技术人员，我认为航天器学比人文科学更加容易。