受け入れ基準（Acceptance Criteria）

受け入れ基準とは、ビジネスの観点から見てユーザーストーリーが「完了」したと言える条件を定義したものです。各基準は合格か不合格かを判定できる、明確でテスト可能な記述です。開発が始まる前のリファインメントで合意され、テストシナリオや自動チェックの出発点になります。

具体例

ストーリー： 買い物客として、チェックアウト時に割引コードを適用し、キャンペーン価格で支払いたい。

ルール形式：

• 有効で期限切れでないコードは、注文合計をコードの割引率分だけ減額する。
• 期限切れのコードでは「This code has expired」と表示され、合計は変わらない。
• 1 つの注文に適用できるコードは 1 つだけで、2 つ目を適用すると 1 つ目が置き換えられる。
• コードは大文字・小文字を区別しない（SAVE10 と save10 は同じ扱い）。

期限切れコードに関する同じ基準を Given/When/Then 形式で書くと次のようになります。

Scenario: Expired discount code is rejected
  Given my cart total is $50.00
  And the code "SPRING10" expired yesterday
  When I apply the code "SPRING10"
  Then I see the message "This code has expired"
  And my cart total is still $50.00

受け入れ基準と完了の定義（Definition of Done）の違い

受け入れ基準は 1 つのストーリーに固有のもので、その機能が何をしなければならないかを表します。**完了の定義（Definition of Done）**はすべてのストーリーに共通で、コードレビュー済み、テスト自動化済み、ドキュメント更新済み、ステージング環境へデプロイ済み、といった条件です。ストーリーは両方を満たして初めて完了になります。

良い基準の書き方

• テスト可能であること。 「ページの読み込みが速い」はテストできません。「ステージングのデータセットで 1,000 件の商品を表示する検索結果ページが 2 秒以内に描画される」ならテストできます。
• 実装ではなく振る舞いを書くこと。 どのデータベーステーブルが変わるかではなく、結果を記述します。
• 異常系も含めること。 不正な入力、権限、エラーメッセージも機能の一部です。
• スリーアミーゴスで合意すること。 プロダクト、開発、テストの 3 者で一緒にレビューします。テスターが最も価値を発揮するのは、コードが書かれる前に「もし〜だったらどうなりますか？」と問いかける場面です。