【ISTQB /JSTQB Agile Tester 解説】3.3.1 受け入れ基準・十分なテスト網羅性・その他の情報（前編）

アジャイル開発では、「受け入れ基準（Acceptance Criteria）」を正しく定義することが、テストの品質を左右します。

今回はISTQB Agile Tester Extensionの第3章「アジャイルプロジェクトにおけるテスト技法」より、3.3.1「受け入れ基準・十分な網羅性・その他の情報」の前半部分を解説します。

✅ 1. 受け入れ基準（Acceptance Criteria）とは？

受け入れ基準とは、ユーザーストーリーや要件が「完了」と見なされるための条件を明確にするものです。

たとえば、「ログイン機能の実装」であれば、以下のような基準が設定されます。

つまり、何をもって“できた”とするのかをチーム全体で共通認識するための基準です。

受け入れ基準には、以下のような項目を含めることで、曖昧さを減らし、テストの抜け漏れを防ぐことができます。

項目	内容	例
機能的振る舞い（Functional Behavior）	どんな機能を持つのかを定義	「ユーザーがボタンを押すと商品がカートに追加される」
品質特性（Quality Characteristics）	非機能的側面（性能・セキュリティ・使いやすさなど）	「3秒以内にページが表示される」「暗号化通信が使われている」
シナリオ・ユースケース	実際の利用シナリオを想定	「会員登録後にメール確認→初回ログイン」など
ビジネスルール	制約や条件	「会員ランクにより割引率が変わる」
外部インターフェース	外部システムとの連携条件	「決済APIと通信成功後に注文完了メールを送る」
データ定義	どんなデータを使うか	「顧客IDは一意で英数字8桁」など

これらを明確にすることで、テストケース作成時にも抜け漏れなく品質を保証できます。

アジャイル開発では、「各テストレベルで何をもって完了とするか」をチームで合意しておく必要があります。

これを Definition of Done（DoD） と呼びます。

単体テストでは、コードレベルでの品質を保証します。

以下のような条件を満たすことが理想です。

例:

ログイン関数に対して、正常系・異常系・例外処理をすべてテストし、100%分岐網羅できているかを確認します。

モジュール間の連携やデータのやり取りを確認する段階です。

例:

「ログインAPI → 認証サーバ → セッション管理DB」間でのデータ連携が正しく行われるか確認。

ここでは、システム全体がユーザー視点で正しく動作するかを確認します。

例:

「新規登録 → ログイン → 商品購入 → 決済完了」までの一連の流れを、本番と同じ構成でテストする。

受け入れ基準とDefinition of Doneは、チーム全員の共通理解を形成するための要です。

それを明確にすることで、品質のばらつきを防ぎ、開発のスピードと安定性の両立が可能になります。

この章は後編（Part 2）に続きます。次回は「テスト網羅性の評価とその他の情報」について解説します。

例:

Given ユーザーが正しい資格情報を入力したとき
When ログインボタンをクリックすると
Then ホーム画面が表示される