 |
Laurent PY博士是Smartesting®的行政總裁。20世紀90年代Laurent PY開始從事先進測試技術方面的工作，他在軟件測試方面擁有豐富的經驗。他熱衷于＃leanstartup和Agility：關鍵是盡快測試并驗證假設以及提供早期反饋！他曾在好幾個會議上發過言。 |
正在縮小的世界中的測試軟件
當“上市時間”從幾個月縮短到幾天（甚至幾個小時）的時候，提供軟件的整個方式會受到影響，測試也同樣會受影響。在采用了敏捷方法的項目中，傳統功能測試鏈正被打亂。這對正在做持續部署的團隊更具挑戰。
在敏捷項目中，迭代很短（通常介于1和4周間），帶有小改進和持續集成。因此，每次迭代，我們都需要確保這些改進按照他們預期的方式進行，并執行一些回歸測試。要達到敏捷性測試這個水平需要大量的自動化。項目將其測試100 ％自動化并不罕見。谷歌每分鐘做20+個代碼變化，每天運行約50百萬次測試！
但測試執行只是硬幣的一面。現在的問題是，如何以相同的速度和規模去設計和維護這些測試？換句話說，一個有許多小幅增長的迭代的項目如何能夠在整個測試過程保持精簡？
早期測試設計
如果一個項目團隊必須非常快速地迭代，很難維護和同步三個傳統存儲庫：需求，代碼和測試。我們過去用來管理他們的需求消失了！測試變得更加重要，流程（迭代或計劃會議期間）中，很早開始了測試設計。測試是“完成”的定義，同時確定需求及驗收標準的方式。因此，所有利益相關者關于一個成功實施意味著什么達成了共識。這些驗收測試也被用來驅動和聚焦代碼編寫 - 我應該先執行哪個測試？這些原則是驗收測試驅動開發實踐的基礎。
所以驗收測試在生產前不再是開發過程的后一步。反之 - 驗收試驗設計在項目早期開始了。而且，到目前為止，它已被證明能夠給質量和生產力帶來巨大的好處。
業務領域語言設計驗收測試的需要
為了按需求規定的速度和規模給早期測試設計提供有效支持并同時增強項目利益相關者之間的溝通，測試人員應該可以構建能被開發人員和業務專家理解的資產。自動化，甚至手工測試用例，通常過于復雜或過于詳細而被錯誤理解。
還有是要保持與測試用例相關的文件，并且毫無疑問，這將引起矛盾。因此，要定義測試場景，測試人員應該使用一種業務領域語言，它：
▪可以被（定義業務術語的）業務專家理解
▪便于測試編寫和維護（基于語義而不僅僅是文字）
▪可被自動轉化用于測試執行
這樣一個業務領域的語言一點好處是：它使開發人員所謂的“重構”成為可能。測試不再是純文本，它有了語義，只用一個動作可以管理和修改大量測試。這意味著使用利于團隊內部交流的業務語言時升級了一百或更多的測試步驟。因此，使用早期測試設計并通過創建一種業務領域語言所寫的測試，你可以將整個項目組和驗收標準的定義對其，并高速度、大規模地進行迭代。
測試的執行也是要么用手動執行要么用自動化被簡化了。因為驗收測試基于一種業務領域語言，所以測試步驟是同類的且更容易理解和執行。對于那些想要做自動化的人，將業務領域語言轉化為將被實現的關鍵字也很簡單。有一些工具支持TADD且為設計測試提供一個特定領域語言（DSL）。
