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