アジャイル開発におけるテスト手法には、「TDD（テスト駆動開発）」「ATDD（受け入れテスト駆動開発）」「BDD（振る舞い駆動開発）」の3つが代表的です。
これらは似ているようでいて、それぞれが異なる目的とアプローチを持っています。
この記事では、ISTQB Agile Tester Extensionの**Chapter 3.1.1「TDD, BDD, ATDD」**の内容をもとに、
それぞれの考え方や特徴、具体的な例を交えてわかりやすく解説します。
🔹 1. TDD（Test-Driven Development：テスト駆動開発）
● 概要
TDDは、「テストを先に書く」開発手法です。
通常の開発では、まずコードを書いてからテストを行いますが、TDDではこの順序を逆にします。
つまり、テストケースを先に設計し、そのテストをパスするためのコードを書くという流れです。
● TDDのプロセス
-
失敗するテストを書く
-
テストを実行して、失敗を確認する（まだコードがないため当然失敗します）
-
テストを通すための最小限のコードを書く
-
テストを再実行して、成功することを確認する
-
コードをリファクタリングする（構造を改善）
-
このサイクルを繰り返す
● 特徴
-
小さな単位（ユニット）でのテストが中心
-
バグの早期発見が可能
-
コードの品質が自然と上がる
-
設計がシンプルで無駄のないものになる
● 具体例
例えば、「2つの数値を足す関数」を作りたい場合、まず次のようなテストを書くところから始めます。
def test_addition():
assert add(2, 3) == 5
最初は add() 関数が存在しないのでテストは失敗します。
次に、最小限のコードを書いてテストを通します。
def add(a, b):
return a + b
テストが成功すればOK。
この小さな成功の積み重ねがTDDの基本サイクルです。
🔹 2. ATDD（Acceptance Test-Driven Development：受け入れテスト駆動開発）
● 概要
ATDDは、ユーザーストーリーに基づく受け入れ基準（Acceptance Criteria）をテストとして作るアプローチです。
TDDが開発者中心であるのに対し、ATDDは**開発者・テスター・ビジネス担当者（顧客代表）**が協働して受け入れ条件を定義する点が特徴です。
● プロセス
-
プロダクトオーナーがユーザーストーリーを提示
-
チーム全体で「何が受け入れ条件か」を議論
-
その条件をテストケース化
-
コード開発後、受け入れテストを自動化して検証
● 特徴
-
チーム全体の認識合わせができる
-
要求の曖昧さを減らす
-
受け入れ条件を自動テストとして活用できる
-
CI/CD（継続的インテグレーション）環境で容易に実行可能
● 具体例
ユーザーストーリー：「ユーザーが正しいパスワードを入力するとログインできる」
受け入れ条件：
-
正しいメールアドレスとパスワード → ログイン成功
-
間違ったパスワード → エラーメッセージ表示
この受け入れ基準をもとに、自動化された受け入れテストを作成します。
このテストが通るように開発を進めるのがATDDの考え方です。
🔹 3. BDD（Behavior-Driven Development：振る舞い駆動開発）
● 概要
BDDは、システムの“振る舞い”を基準にテストを設計する手法です。
TDDを拡張し、「ユーザー視点での振る舞い」をわかりやすく記述します。
● 特徴
-
「Given-When-Then」形式で仕様を表現
-
ビジネス関係者にも理解しやすい自然言語形式
-
自動テストツール（Cucumberなど）で利用可能
● Given-When-Then形式とは
-
Given（前提）：初期状態や前提条件
-
When（操作）：ユーザーの行動やイベント
-
Then（結果）：期待される結果
● 具体例
シナリオ: 正しい資格情報でログインできる
Given ユーザーがログインページにいる
When 正しいユーザー名とパスワードを入力する
Then ダッシュボードが表示される
このように、BDDではテストケースを「人間が読める仕様書」として記述します。
これにより、開発者・テスター・ビジネス担当者の共通言語が生まれます。
🔹 4. TDD・ATDD・BDDの違いまとめ
|
項目 |
TDD |
ATDD |
BDD |
|---|---|---|---|
|
主な目的 |
コード品質の向上 |
要求の受け入れ確認 |
振る舞いの明確化 |
|
主な関係者 |
開発者 |
開発者・テスター・顧客 |
開発者・テスター・顧客 |
|
テスト作成タイミング |
コーディング前 |
ユーザーストーリー作成時 |
振る舞い設計時 |
|
記述形式 |
コードベース（単体テスト） |
受け入れ基準 |
Given-When-Then形式 |
|
使用例 |
ユニットテスト |
受け入れテスト |
Cucumberによる仕様テスト |
🔹 5. まとめ：アジャイルテストでの活用ポイント
アジャイル開発では、継続的なフィードバックと協働が重要です。
TDD、ATDD、BDDはいずれも「早期にテストを設計する」という共通理念を持っています。
-
TDD → コード品質を担保するために先にテストを書く
-
ATDD → ビジネス要件の理解と一致を確実にする
-
BDD → チーム全員が共通理解を持てる仕様を形成する
これらをうまく使い分けることで、アジャイルチームは無駄な手戻りを減らし、品質を維持しながらスピードを上げることができます。
🧩 参考：試験対策のヒント（ISTQB Agile Tester）
ISTQB Agile Tester試験では、次のような質問が出ることがあります。
例題：
以下のうち、BDD（振る舞い駆動開発）の特徴として正しいものはどれですか？
選択肢：
A. テストをコードの前に書く手法である
B. 受け入れ基準をチーム全体で作成する手法である
C. ユーザーの行動に基づいて「Given-When-Then」形式で記述する
D. リリース後にテストを実施する手法である
正解：C
解説：
BDDは「振る舞い（Behavior）」をテストの出発点とし、ユーザーの操作とシステムの反応を明確に表現するため、「Given（前提）」「When（操作）」「Then（結果）」の形式で記述します。
✅ まとめ
-
TDD：テストを先に書く開発手法（主に開発者向け）
-
ATDD：受け入れ基準をもとにテストを設計（チーム全体向け）
-
BDD：振る舞いを自然言語で記述し共通理解を得る（ユーザー視点）
これら3つを理解することで、アジャイル開発の品質保証活動をより効果的に行うことができます。
コメント