Acceptance Criteria

接受/驗收條件

2022/04/03 (增加連結)
2022/10/16 (內容微調)

接受/驗收條件

從TDD的觀點來看，在開發前就確認系統要如何測試，一方面可以利用測試案例來說明系統需求，另一方面，開發者也可以透過測試案例來確認是否了解使用者的需求。這也是越來越多團隊利用接受條件來說明系統需求，好處是可以進一步將接受條件當作測試案例(Test Case)，也可以讓接受條件成為自動測試的測試案例。

規則導向(rule-oriented)的寫法

會有哪些資料會被輸入、使用者輸入之後期望看到什麼、任何其他潛在的商業邏輯? 有什麼可能的邊際條件出錯需要處理?

  • 名稱: 依類別尋找產品

    • 角色: 身為 購買者

    • 需求: 我想要可以 依類別瀏覽產品資訊

    • 價值: 因此我可以 從產品類別中找到我想要的產品

  • 接受條件:

    • 購買者可以看到所有類別

    • 購買者可以看到所有類別中的產品 (產品名稱、價格)

      • 若超過十個產品每頁十個產品


  • 名稱: 填寫學系學習方法

    • 角色: 身為 大學校系代表

    • 需求: 我想要可以 提供三到五項學系學習方法並提供圖片、圖說搭配文字、圖片版權

    • 價值: 因此我可以 讓高中生可以了解學系的學系學習方法

  • 接受條件:

    • 我可以輸入三個學習方法 而且不能少於三個學習方法

    • 我可以輸入五個學習方法 而且不能多於五個學習方法

    • 每個學習方法的輸入內容不得輸入超過100字

    • 圖片只能上傳jpeg檔案 (副檔名為.jpg, .jepg, .JPG, .JEPG)

    • 圖說搭配文字不得輸入超過12字

    • 圖片版權來源不得輸入超過30字

但是，這樣的寫法不太容易直接轉為測試案例。

情境導向(Scenario-oriented)的寫法

其中一個常被BDD/Specification by Example使用的方法是利用情境(Scenario)、前提(Given)、當(When)、然後(Then)來寫接受條件 (詳參: INTRODUCING BDD (by Dan North))

這裡的接受條件是未來可以轉換成測試案例，所以，Given通常是測試的準備動作，When則是測試所執行的動作，Then則是驗證動作是否成功。

  • 名稱: 客戶領取現金

    • 角色: 身為客戶

    • 需求: 我想要 可以從自動提款機領取現金

    • 價值: 因此我可以隨時都可以領到現金

  • 接受條件:

    • 情境1: 帳戶有足夠餘額

      • 前提: 帳戶有足夠餘額

        • 而且 提款卡是有效的

        • 而且 吐鈔機中有足夠的現金

      • 當 客戶要提款

      • 然後 確定帳戶餘額被正確扣除

        • 而且 確定吐鈔機中給了正確的現金

        • 而且 確定提款卡是被退回

    • 情境2: 帳戶沒有足夠餘額或超過提款金額上限

      • 前提: 帳戶沒有足夠餘額或超過提款金額上限

        • 而且 提款卡是有效的

      • 當 客戶要提款

      • 然後 確定顯示無法提款的錯誤訊息

        • 而且 確定吐鈔機並沒有給現金

        • 而且 確定提款卡是被退回

另一種寫法是納入了範例的資料內容，這樣的寫法更容易轉為測試案例 (詳參: WHAT’S IN A STORY? (by Dan North))

  • 名稱: 客戶領取現金

    • 角色: 身為客戶

    • 需求: 我想要 可以從自動提款機領取現金

    • 價值: 因此我可以隨時都可以領到現金

  • 接受條件:

    • 情境1: 帳戶有足夠餘額

      • 前提: 帳戶的餘額是 \$100

        • 而且 提款卡是有效的

        • 而且 吐鈔機中有足夠的現金

      • 當 客戶要提 \$20

      • 然後 確定帳戶餘額為 \$80

        • 而且 確定吐鈔機中給了 \$20

        • 而且 確定提款卡是被退回

    • 情境2: 帳戶沒有足夠餘額

      • 前提: 帳戶的餘額是 \$10

        • 而且 提款卡是有效的

      • 當 客戶要提 \$20

      • 然後 確定顯示「餘額不足」訊息

        • 而且 帳戶的餘額還是 \$10

        • 而且 確定提款卡是被退回

  • Declarative vs Imperative Gherkin Scenarios for Cucumber (2013)

# Imperative example in the Cucumber book Wynne & Hellesøy (2012)

Scenario: Redirect user to originally requested page after logging in

Given a User "dave" exists with password "secret"

And I am not logged in

When I navigate to the home page

Then I am redirected to the login form

When I fill in "Username" with "dave"

And I fill in "Password" with "secret"

And I press "Login"

Then I should be on the home page


# Declarative example from Aslak Hellesøy: The training wheels came off

Scenario: Redirect user to originally requested page after logging in

Given I am an unauthenticated guest

And I have a valid user account

And I attempt to access restricted content

When I log in

Then I have access to the restricted content

與測試整合

要讓需求可以跟測試整合，可以透過一些工具 (如:Cucumber 或 FitNesse)，將這些內容轉譯為可在測試工具中執行的測試個案。Cucumber所使用的語法是Gherkin，例如:

Scenario Outline: eating

Given there are <start> cucumbers

When I eat <eat> cucumbers

Then I should have <left> cucumbers


Examples:

| start | eat | left |

| 12 | 5 | 7 |

| 20 | 5 | 15 |

利用Cucumber可以去執行對應的測試，並回報哪些功能及情境已經通過測試。詳見: BDD

參考資料