ソフトウェア開発では、「どうすればユーザーが満足する高品質な製品を作れるか？」が常に課題です。
その中で注目されるのが、**Acceptance Test Driven Development（受け入れテスト駆動開発：ATDD）**です。
この記事では、ISTQB Foundation Level 4.0のシラバスに基づき、ATDDの概要・流れ・具体例をわかりやすく紹介します。
🔹 ATDDとは？
ATDDとは、「Acceptance Test Driven Development（受け入れテスト駆動開発）」の略です。
これは、テストを先に作り、その後に開発を行う“テストファースト”アプローチの一種です。
Agile開発で使われるテストアプローチには、主に以下の3種類があります：
|
略語 |
名称 |
概要 |
|---|---|---|
|
TDD |
Test Driven Development |
単体テストを先に書き、最小限のコードを実装してテストを通す |
|
BDD |
Behavior Driven Development |
システムの「ふるまい（Behavior）」を自然言語で定義し、開発とテストを一体化 |
|
ATDD |
Acceptance Test Driven Development |
「受け入れ基準（Acceptance Criteria）」に基づいてテストを先に書く |
🔹 ATDDの特徴
1. テストファーストの開発手法
ATDDでは、ユーザーストーリーを実装する前に、受け入れテストケースを先に作成します。
これにより、「このストーリーが完成したとみなすための条件（=受け入れ基準）」が明確になります。
開発者はそのテストを基準にコードを書き、テストがパスすることを目標にします。
つまり、テストが合格すれば開発完了というわかりやすい指標ができるのです。
2. チーム全体でのコラボレーション
ATDDの大きな特徴は、複数の視点を取り入れることです。
テストケースは、以下のメンバーが協力して作成します：
-
ビジネス担当者（PO・BA）：ユーザーの期待を反映
-
開発者（Developer）：実装の観点から妥当性を確認
-
テスター（Tester）：品質保証と網羅性を確保
この「3 Amigos（スリーアミーゴス）」による共同作業により、要件のあいまいさや矛盾を早期に発見できます。
3. 手動テストでも自動テストでもOK
ATDDでは、作成された受け入れテストは手動でも自動でも実行可能です。
重要なのは「テストが開発の指針になること」であり、どちらの方法でも構いません。
🔹 ATDDの基本プロセス
ATDDは次の4つのステップで進みます。
Step 1：仕様ワークショップ（Specification Workshop）
チーム全員でユーザーストーリーを確認し、**受け入れ基準（Acceptance Criteria）**を明確にします。
不明点や矛盾点があれば、この段階で話し合い修正します。
🧩 例：
ユーザーストーリー：「ユーザーは正しいIDとパスワードでログインできる」
Acceptance Criteria（受け入れ基準）：
-
正しい認証情報でログイン成功
-
誤ったパスワードでエラーメッセージを表示
-
ログイン後にユーザー名が表示される
Step 2：テストケースの作成
次に、受け入れ基準に基づいてテストケースを作成します。
最初は**ポジティブテスト（正常系）から始め、その後ネガティブテスト（異常系）**を追加します。
🧩 例：
|
テストタイプ |
入力 |
期待結果 |
|---|---|---|
|
正常系 |
正しいID・パスワード |
ログイン成功 |
|
異常系 |
間違ったパスワード |
「認証に失敗しました」エラー表示 |
|
非機能 |
同時ログイン10件 |
システムが遅延なく処理できる |
Step 3：テストを基に開発
作成したテストケースをもとに、開発者が機能を実装します。
**「テストをパスさせるためのコードを書く」**という流れです。
テストを実行 → 失敗 → コード修正 → 再テスト → パス
この繰り返しによって、確実に要件を満たした機能が出来上がります。
Step 4：自動化・レビュー
最終的に、受け入れテストは**実行可能な要件（Executable Requirements）**として扱われます。
開発後も継続的インテグレーション（CI）環境で自動実行できるようにし、品質を維持します。
また、テストケースは自然言語で分かりやすく書くことが推奨されます。
これは、開発者だけでなく、ビジネス担当者も理解できるようにするためです。
🔹 ATDDとBDD・TDDの違いまとめ
|
比較項目 |
TDD |
BDD |
ATDD |
|---|---|---|---|
|
主な目的 |
コード品質 |
振る舞いの明確化 |
受け入れ条件の明確化 |
|
テスト作成者 |
開発者 |
開発者＋テスター |
PO＋開発者＋テスター |
|
テストレベル |
単体テスト |
機能テスト |
受け入れテスト |
|
言語表現 |
コードベース |
自然言語（Given-When-Then） |
自然言語＋受け入れ基準 |
|
協働範囲 |
技術チーム中心 |
技術＋ビジネス間 |
全チーム |
🔹 ATDDを導入するメリット
-
要件のあいまいさを減らす
→ チーム全体で同じ理解を共有できる
-
欠陥の早期発見
→ 実装前に不明点を解消できる
-
再テストの自動化が容易
→ CI/CDパイプラインに統合できる
-
品質とスピードの両立
→ ムダな修正や誤解を防げる
🔹 まとめ：ATDDは「共通理解をコード化する」仕組み
ATDDは、単なるテスト技法ではありません。
それは「チーム全員で共通のゴールを定義し、そのゴールを自動的に確認できる仕組み」です。
受け入れテストを先に作ることで、
開発の方向性が明確になり、誤解や手戻りが大幅に減ります。
特にAgileやDevOpsの現場では、ATDDを導入することで「チーム全体で品質を作る文化」を実現できます。
✅ まとめポイント
-
ATDD = 受け入れ基準に基づいてテストを先に書く手法
-
チーム全体（PO・開発者・テスター）で共同作業
-
ポジティブ → ネガティブ → 非機能テストの順で設計
-
テストが開発の指針となる（テストファースト）
-
最終的に受け入れテストが「実行可能な要件」として扱われる
コメント