この記事は何か?
本記事ではアジャイル開発で実践される駆動開発の3つのアプローチ（TDD、BDD、ATDD）について、それぞれの基本的な概要をQAエンジニア目線で解説します。
目次
- 1. アジャイル開発における位置づけ
- 2. テスト駆動開発（Test-Driven Development：TDD）
- 3. 振る舞い駆動開発（Behavior-Driven Development：BDD）
- 4. 受け入れテスト駆動開発（Acceptance Test-Driven Development：ATDD）
- 5. 3つの手法の比較
- 6. TDD・BDD・ATDDでカバーできない領域
1. アジャイル開発における位置づけ
ウォーターフォール開発が「設計→実装→テスト」と段階的に進むのに対し、アジャイルでは小さな単位で設計・実装・テストを反復的に行います。
テスト駆動開発（Test-Driven Development：TDD）、振る舞い駆動開発（Behavior-Driven Development：BDD）、受け入れテスト駆動開発（Acceptance Test-Driven Development：ATDD）の3つの手法は、異なる粒度でテストファーストを実践するための具体的な手法です。
2. テスト駆動開発（Test-Driven Development：TDD）
主にユニットレベルでコードを書く前にテストを書く開発手法です。
TDDは主に開発者によって実践され、Red-Green-Refactorと呼ばれるサイクルで実践します。
- 失敗する単体テストを書く（Red）
- テストが通る最小限のコードを書く（Green）
- コードをリファクタリングする（Refactor）
3. 振る舞い駆動開発（Behavior-Driven Development：BDD）
ユーザー視点での機能の振る舞いをステークホルダー全員が理解できる形で記述し、それを基に開発を進める手法です。
スプリント初期から開発者、QA、プロダクトオーナーが協働してシナリオを作成します。
- Discovery:関係者全員でユースケースを洗い出し、具体的なシナリオを作成する
- Formulation:Given-When-Then形式で振る舞いを記述する
（例:Given ユーザーがログインしている When 商品をカートに追加する Then カート内に商品が表示される） - 自動化:振る舞いを自動テストとして実装する
BDDにおいてQAエンジニアはスプリント計画時のふるまいの定義、シナリオ作成、自動化実装などに関与します。
4. 受け入れテスト駆動開発（Acceptance Test-Driven Development：ATDD）
開発前に顧客と合意した受け入れ基準を定義し、開発を進める手法です。
スプリント初期から開発者、QA、プロダクトオーナーが協働して受け入れ基準を具体的なテストケースとして作成します。
- 受け入れ基準の定義:ユーザーストーリーごとに受け入れ条件を明確化する
- テストケースの作成:受け入れ基準を具体的なテストケースに落とし込む
- 自動化:テストケースを自動テストとして実装する
ATDDにおいてQAエンジニアは受け入れ基準の定義、テストケース作成、自動化実装などに関与します。
5. 3つの手法の比較
| 観点 | TDD | BDD | ATDD |
|---|---|---|---|
| 主なスコープ | 関数やクラス | 機能の振る舞い | 受け入れ基準の充足 |
| 主な実施者 | 開発者 | プロダクトオーナー・開発者・QA | プロダクトオーナー・開発者・QA |
| 記述 | プログラミング言語 | 自然言語に近い記法 | 自然言語 |
これらの手法は組み合わせて使用できます。
TDDで単体テスト、BDDで機能テスト、ATDDで受け入れテストと、異なる粒度でテストファーストを実践できます。
6. TDD・BDD・ATDDでカバーできない領域
アジャイルQAの基本方針は「自動化できるものは自動化し、人間にしかできないテストに注力する」です。
主に人間の判断が必要なテストは別途実施が必要です。
- 探索的テスト: 仕様化されていない問題の発見、想定外のパターンの検証など
- 非機能要件の一部: ユーザビリティテスト、アクセシビリティテストなど主に人間の判断が必要なテスト