上篇文章提到了，系統與程式碼存在的目的，就是為了滿足使用者的需求。
因為我們需要一個方式來定義與管理使用者的需求。本系列TDD的文章，則是以user story為例。而user story除了需要簡單扼要清楚的描述使用者的需求，還要確保團隊中每一個角色（包括使用者）都能理解以外，另一個重點就是user story通常需要acceptance test cases來輔以說明，該user story需要滿足哪一些驗收測試案例，才能稱為完成。
上一篇文章有提到，通常會使用user story card，而驗收測試案例，通常就會寫在user story card的背面。
因此，這一篇文章就要針對acceptance testing來進行說明。
上一篇文章：[Day 20]ATDD - User Requirement
本系列文章專區
因為我們需要一個方式來定義與管理使用者的需求。本系列TDD的文章，則是以user story為例。而user story除了需要簡單扼要清楚的描述使用者的需求，還要確保團隊中每一個角色（包括使用者）都能理解以外，另一個重點就是user story通常需要acceptance test cases來輔以說明，該user story需要滿足哪一些驗收測試案例，才能稱為完成。
上一篇文章有提到，通常會使用user story card，而驗收測試案例，通常就會寫在user story card的背面。
因此，這一篇文章就要針對acceptance testing來進行說明。
上一篇文章：[Day 20]ATDD - User Requirement
本系列文章專區