Laurent PY博士是Smartesting®的行政总裁。20世纪90年代Laurent PY开始从事先进测试技术方面的工作，他在软件测试方面拥有丰富的经验。他热衷于＃leanstartup和Agility：关键是尽快测试并验证假设以及提供早期反馈！他曾在好几个会议上发过言。

　　正在缩小的世界中的测试软件
　　当“上市时间”从几个月缩短到几天（甚至几个小时）的时候，提供软件的整个方式会受到影响，测试也同样会受影响。在采用了敏捷方法的项目中，传统功能测试链正被打乱。这对正在做持续部署的团队更具挑战。
　　在敏捷项目中，迭代很短（通常介于1和4周间），带有小改进和持续集成。因此，每次迭代，我们都需要确保这些改进按照他们预期的方式进行，并执行一些回归测试。要达到敏捷性测试这个水平需要大量的自动化。项目将其测试100 ％自动化并不罕见。谷歌每分钟做20+个代码变化，每天运行约50百万次测试！
　　但测试执行只是硬币的一面。现在的问题是，如何以相同的速度和规模去设计和维护这些测试？换句话说，一个有许多小幅增长的迭代的项目如何能够在整个测试过程保持精简？

　　早期测试设计
　　如果一个项目团队必须非常快速地迭代，很难维护和同步三个传统存储库：需求，代码和测试。我们过去用来管理他们的需求消失了！测试变得更加重要，流程（迭代或计划会议期间）中，很早开始了测试设计。测试是“完成”的定义，同时确定需求及验收标准的方式。因此，所有利益相关者关于一个成功实施意味着什么达成了共识。这些验收测试也被用来驱动和聚焦代码编写 - 我应该先执行哪个测试？这些原则是验收测试驱动开发实践的基础。

　　所以验收测试在生产前不再是开发过程的后一步。反之 - 验收试验设计在项目早期开始了。而且，到目前为止，它已被证明能够给质量和生产力带来巨大的好处。

　　业务领域语言设计验收测试的需要
　　为了按需求规定的速度和规模给早期测试设计提供有效支持并同时增强项目利益相关者之间的沟通，测试人员应该可以构建能被开发人员和业务专家理解的资产。自动化，甚至手工测试用例，通常过于复杂或过于详细而被错误理解。
　　还有是要保持与测试用例相关的文件，并且毫无疑问，这将引起矛盾。因此，要定义测试场景，测试人员应该使用一种业务领域语言，它：
　　▪可以被（定义业务术语的）业务专家理解
　　▪便于测试编写和维护（基于语义而不仅仅是文字）
　　▪可被自动转化用于测试执行
　　这样一个业务领域的语言一点好处是：它使开发人员所谓的“重构”成为可能。测试不再是纯文本，它有了语义，只用一个动作可以管理和修改大量测试。这意味着使用利于团队内部交流的业务语言时升级了一百或更多的测试步骤。因此，使用早期测试设计并通过创建一种业务领域语言所写的测试，你可以将整个项目组和验收标准的定义对其，并高速度、大规模地进行迭代。

　　测试的执行也是要么用手动执行要么用自动化被简化了。因为验收测试基于一种业务领域语言，所以测试步骤是同类的且更容易理解和执行。对于那些想要做自动化的人，将业务领域语言转化为将被实现的关键字也很简单。有一些工具支持TADD且为设计测试提供一个特定领域语言（DSL）。