正在缩小的世界中的测试软件
当“上市 时间 ”从几个月缩短到几天（甚至几个小时）的时候，提供软件的整个方式就会受到影响 ，测试也同样会受影响。在采用了敏捷方法的 项目 中，传统功能测试链正被打乱。这对正在做持续部署的团队更具挑战。
在敏捷项目中，迭代很短（通常介于1和4周间），带有小改进和持续集成。因此，每次迭代，我们都需要确保这些改进按照他们预期的方式进行，并执行一些回归测试。要达到敏捷性测试这个水平需要大量的自动化。项目将其测试100 ％自动化并不罕见。谷歌每分钟做20+个代码变化，每天运行约50百万次测试！
但测试执行只是硬币的一面。现在的问题是， 如何 以相同的速度和规模去设计和维护这些测试？换句话说，一个有许多小幅增长的迭代的项目如何能够在整个测试过程保持精简？
早期测试设计
如果一个项目团队必须非常快速地迭代，就很难维护和同步三个传统存储库：需求，代码和测试。我们过去用来管理他们的需求消失了！测试变得更加重要，流程（迭代或 计划 会议期间）中，很早就开始了测试设计。测试是“完成”的定义，同时确定需求及验收标准的方式。因此，所有利益相关者关于一个成功实施意味着什么达成了共识。这些验收测试也被用来驱动和聚焦代码编写 - 我应该先执行哪个测试？这些原则是验收测试驱动 开发 实践的基础。
所以验收测试在生产前不再是开发过程的最后一步。反之 - 验收试验设计在项目早期就开始了。 而且 ，到目前为止，它已被证明能够给质量和生产力带来巨大的好处。
业务领域语言设计验收测试的需要
为了按需求规定的速度和规模给早期测试设计提供有效支持并同时增强项目利益相关者之间的沟通，测试人员应该可以构建能被开发人员和业务专家理解的资产。自动化，甚至手工测试用例，通常过于复杂或过于详细而被错误理解。
还有就是要保持与测试用例相关的文件，并且毫无疑问，这将引起矛盾。因此，要定义测试场景，测试人员应该使用一种业务领域语言，它：
1、可以被（定义业务术语的）业务专家理解
2、便于测试编写和维护（基于语义而不仅仅是文字）
3、可被自动转化用于测试执行
这样一个业务领域的语言一点好处是：它使开发人员所谓的“重构”成为可能。测试不再是纯文本，它有了语义，只用一个动作就可以管理和修改大量测试。这意味着使用利于团队内部交流的业务语言时升级了一百或更多的测试步骤。因此，使用早期测试设计并通过创建一种业务领域语言所写的测试，你可以将整个项目组和验收标准的定义对其，并高速度、大规模地进行迭代。
测试的执行也是要么用手动执行要么用自动化被简化了。因为验收测试基于一种业务领域语言，所以测试步骤是同类的且更容易理解和执行。对于那些想要做自动化的人，将业务领域语言转化为将被实现的关键字也很简单。有一些 工具 支持TADD且为设计测试提供一个特定领域语言（DSL）。
举例：测试一个阅读应用
在这个例子中，我们将使用Zest平台及其语言来设计测试。我们将同时显示代码和编辑器。该编辑器是一种定义业务理念和场景的图形化方式。
现在，让我们定义一个简单的场景：“买很多书”。首先，该场景将使用一个要么是“行动”要么是“结果”的步骤的传统观念。这是人们通常使用的方式。
编辑器中“买很多书”场景的视图
该场景可以通过引入一个名为“选择书”的动作词进行重构。这个概念定义了一个业务动作/术语，确保了分解。就像一个功能，它提供了一个维护单一点，并且可以有一些参数。
所以，现在，该场景可以调用动作词了。
现在，我们要把一个新场景添加到测试功能“取消购物车”中。首先，我们创建一个动作词来检查购物车中书的数量。这个动作在新方案中将被使用两次。
然后，我们创建“可被取消的一选项”场景：
