正在縮小的世界中的測試軟件
當“上市時間”從幾個月縮短到幾天（甚至幾個小時）的時候，提供軟件的整個方式就會受到影響，測試也同樣會受影響。在采用了敏捷方法的項目中，傳統功能測試鏈正被打亂。這對正在做持續部署的團隊更具挑戰。
在敏捷項目中，迭代很短（通常介于1和4周間），帶有小改進和持續集成。因此，每次迭代，我們都需要確保這些改進按照他們預期的方式進行，并執行一些回歸測試。要達到敏捷性測試這個水平需要大量的自動化。項目將其測試100 ％自動化并不罕見。谷歌每分鐘做20+個代碼變化，每天運行約50百萬次測試！
但測試執行只是硬幣的一面。現在的問題是，如何以相同的速度和規模去設計和維護這些測試？換句話說，一個有許多小幅增長的迭代的項目如何能夠在整個測試過程保持精簡？
早期測試設計
如果一個項目團隊必須非常快速地迭代，就很難維護和同步三個傳統存儲庫：需求，代碼和測試。我們過去用來管理他們的需求消失了！測試變得更加重要，流程（迭代或計劃會議期間）中，很早就開始了測試設計。測試是“完成”的定義，同時確定需求及驗收標準的方式。因此，所有利益相關者關于一個成功實施意味著什么達成了共識。這些驗收測試也被用來驅動和聚焦代碼編寫 - 我應該先執行哪個測試？這些原則是驗收測試驅動開發實踐的基礎。
所以驗收測試在生產前不再是開發過程的最后一步。反之 - 驗收試驗設計在項目早期就開始了。而且，到目前為止，它已被證明能夠給質量和生產力帶來巨大的好處。
業務領域語言設計驗收測試的需要
為了按需求規定的速度和規模給早期測試設計提供有效支持并同時增強項目利益相關者之間的溝通，測試人員應該可以構建能被開發人員和業務專家理解的資產。自動化，甚至手工測試用例，通常過于復雜或過于詳細而被錯誤理解。
還有就是要保持與測試用例相關的文件，并且毫無疑問，這將引起矛盾。因此，要定義測試場景，測試人員應該使用一種業務領域語言，它：
▪可以被（定義業務術語的）業務專家理解
▪便于測試編寫和維護（基于語義而不僅僅是文字）
▪可被自動轉化用于測試執行
這樣一個業務領域的語言一點好處是：它使開發人員所謂的“重構”成為可能。測試不再是純文本，它有了語義，只用一個動作就可以管理和修改大量測試。這意味著使用利于團隊內部交流的業務語言時升級了一百或更多的測試步驟。因此，使用早期測試設計并通過創建一種業務領域語言所寫的測試，你可以將整個項目組和驗收標準的定義對其，并高速度、大規模地進行迭代。
測試的執行也是要么用手動執行要么用自動化被簡化了。因為驗收測試基于一種業務領域語言，所以測試步驟是同類的且更容易理解和執行。對于那些想要做自動化的人，將業務領域語言轉化為將被實現的關鍵字也很簡單。有一些工具支持TADD且為設計測試提供一個特定領域語言（DSL）。
舉例：測試一個閱讀應用
在這個例子中，我們將使用Zest平臺及其語言來設計測試。我們將同時顯示代碼和編輯器。該編輯器是一種定義業務理念和場景的圖形化方式。
現在，讓我們定義一個簡單的場景：“買很多書”。首先，該場景將使用一個要么是“行動”要么是“結果”的步驟的傳統觀念。這是人們通常使用的方式。
編輯器中“買很多書”場景的視圖 該場景可以通過引入一個名為“選擇書”的動作詞進行重構。這個概念定義了一個業務動作/術語，確保了分解。就像一個功能，它提供了一個維護單一點，并且可以有一些參數。
所以，現在，該場景可以調用動作詞了。 
現在，我們要把一個新場景添加到測試功能“取消購物車”中。首先，我們創建一個動作詞來檢查購物車中書的數量。這個動作在新方案中將被使用兩次。 
然后，我們創建“可被取消的一選項”場景： 
在此，該平臺已經注意到，下面的步驟序列被用在幾個場景中，即：“買很多書”和“可被取消的一選項。” 
因此建議創建一個新的動作詞并在2場景中重構以優化你的維護！當被執行（即行動詞“登錄”創建及場景重構）時， “可取消的一選項”場景就變成了： 
編輯器中“可撤銷的一選項”場景的視圖 這個例子中，我們已經看到了使用一種語言來設計測試的價值。使用動作詞（類似于開發人員的功能）使得設計和維護更加容易，并提供了重構能力。它有助于定義不同項目利益相關者之間的業務術語。
我們也看到了，這種業務術語的定義可以在設計，優化和重構場景時通過一個非常先進的方式實現。 |