昨今のソフトウェア開発現場では、プロダクトの迅速なリリースを可能にする「アジャイル開発」が標準的な選択肢となりつつあります。開発手法が変われば、当然ながら品質を担保するためのテストのあり方も変えなくてはなりません。
これからアジャイル開発に携わるITエンジニアにとって、従来の「最後にまとめて検証する」手法とは異なる、アジャイル特有のテストアプローチを理解することは重要です。
本稿では、アジャイルテストの概要やウォーターフォールテストとの違い、実践における主な手法について解説します。
- もくじ
1. アジャイルテストとは
アジャイルテストとは、アジャイル開発のサイクルに合わせて、短期間で継続的にテストを行う考え方や活動のことです。開発の最終段階でまとめてテストを行うのではなく、開発工程の一部として繰り返しテストを実施していきます。
アジャイル開発では、「要件定義→設計→実装→テスト→リリース」といった一連の工程を、機能ごとに短期間のサイクルとして回していくのが特徴です。アジャイルテストは、この各サイクルの中で実施されるテスト全般を指します。
なお、アジャイル開発とは何かについて詳しくは、次の記事を参考にしてください。
2. アジャイルテストとウォーターフォールテストの違い
アジャイル開発とよく対比されるのが、ソフトウェア開発の黎明期から存在する「ウォーターフォール開発」です。ウォーターフォール開発では、「要件定義→設計→実装→テスト→リリース」といった一連の工程を、後戻りしない前提で直線的に進めていきます。
ウォーターフォール開発とアジャイル開発では、テストアプローチにも大きな違いがあります。ここでは、主に「実行タイミング」と「テストケースの扱い」という2つの観点から、違いを見ていきましょう。
2-1. 実行タイミング
ウォーターフォールテストは、要件定義や設計、実装といったテストの前工程が完了した後にまとめて実行されます。開発工程とテスト工程が明確に分かれているのが特徴です。ソフトウェア全体を網羅して検証するため期間が長くなりやすく、1か月を超えるケースも珍しくありません。
一方のアジャイルテストは、機能ごとに区切られたサイクル（イテレーション）の中で個別に実行されます。各機能の実装が完了するたびにテストを行うため、バグの早期発見・修正が可能です。サイクルの期間自体が最大でも1か月程度であるため、1回あたりのテスト期間も数日から1週間前後とコンパクトになります。
2-2. テストケースの扱い
アジャイル・ウォーターフォールを問わず、テストの実施手順や期待値をまとめた「テストケース」は欠かせません。テストケースの扱いにも違いがあります。
ウォーターフォールテストでは、作成したテストケースは基本的に「使い切り型」です。そのプロジェクトでの品質保証がゴールであり、完全な形で再利用されることは多くありません。次回の開発では仕様が大きく異なり、再利用できないケースも多いです。ただし、派生開発やバージョンアップ開発などでは、過去のテストケースが再利用されることもあります。
一方のアジャイルテストは、過去のテスト資産を蓄積していく「積み上げ型」です。機能の追加や改善を繰り返す中で、既存機能が正常に動作し続けているかを確認しなければなりません。そのため、前サイクルのテストケースも都度再実行（回帰テスト）する上に、仕様の変化に合わせて継続的なメンテナンスを行います。
アジャイルテストではサイクルを重ねるごとに、実行すべきテストの量が増え続けます。この増加をそのまま放置すると、やがてテストを実施しきれなくなります。そのため、すべてのテストを常に実行し続けるのではなく、影響範囲や重要度に応じて回帰テストの対象を調整し、増加に歯止めをかける運用が必要です。
他方で、回帰テストの範囲を調整するだけでは、アジャイル開発のスピードに追従しきれない場面も出てくるでしょう。よって、アジャイルテストそのものを効率化することも大切です。限られた期間で精度と効率を両立させるためには、テスト自動化などの工夫が重要なテーマとなります。
3. アジャイルテストの4象限とは
アジャイルテストの全体像を整理する考え方として、「アジャイルテストの4象限」があります。これは、テストを指向や目的に沿って4つに分類したフレームワークです。
アジャイルテストの4象限では、縦軸に指向（ビジネス指向／技術指向）、横軸に目的（チーム支援／プロダクト評価）を置き、4つの領域でテストを定義します。この2軸で整理することで、各テストの役割が明確となります。
ここでは、4象限のそれぞれについて、順番に見ていきましょう。
3-1. 技術指向・チーム支援
第1象限は、開発チームを支援するための、技術的な側面のテストです。主に、プログラマーなどの開発者が行う「単体テスト（コンポーネントテスト）」が該当します。
プログラムのコードが正しく書かれているか、内部品質を保証することが主な目的です。繰り返し実行できるように自動化されることが多く、後述するTDD（テスト駆動開発）などの手法もよく採用されます。
3-2. ビジネス指向・チーム支援
第2象限は、顧客やユーザーの要求どおりに機能が動作するかを確認し、開発チームを正しい方向へ導くためのテストです。主に「機能テスト」や「ストーリーテスト（シナリオテスト）」が該当します。
ユーザーが期待する振る舞いを具体化することで、認識のズレを早期に防ぐ役割を担います。基本的な動作確認は自動化されることもありますが、仕様の解釈や業務ルールに関わる部分は、手動で確認されることも少なくありません。
3-3. ビジネス指向・プロダクト評価
第3象限は、実際にユーザーが使う状況を想定し、プロダクトの価値を評価するためのテストです。主に「探索的テスト」や「ユーザビリティテスト」、「UAT（ユーザー受け入れテスト）」などが該当します。
仕様どおりに動くかだけでなく、「ユーザーにとって使いやすいか」「期待する価値を提供できているか」を批判的に検証します。人間の感覚や直感が重要になるため、手動で行われることが多いです。
3-4. 技術指向・プロダクト評価
第4象限は、ソフトウェアの信頼性やパフォーマンスなど、非機能要件を満たしているかを評価するためのテストです。「負荷テスト」や「セキュリティテスト」、「パフォーマンステスト」などが該当します。
応答速度は十分か、脆弱性（セキュリティ上の弱み）はないかなど、各観点の検証に応じた専用ツールを用いて検証を行います。リリース後のトラブルを防ぐためにも、プロダクト全体の品質を最終的に確認する重要なテストです。
4. アジャイルテストにおける代表的な手法
ここでは、アジャイルテストを実践するうえで、よく採用される代表的な手法を3つご紹介します。
- TDD（テスト駆動開発）
- BDD（ビヘイビア駆動開発）
- 探索的テスト
4-1. TDD（テスト駆動開発）
TDD（Test-Driven Development：テスト駆動開発）は、テストの大枠を先に固めてから開発を進める手法です。まずテストコードを作成し、そのテストに合格するようにプロダクトのコードを書いていきます。
最初にテストコードを用意することで、テストしやすいコードを書く必要に迫られます。結果として、内部品質を意識するようになり、変更に強いコードの実装が可能です。これは、短いスパンで行われるアジャイルテストにおいても大きなメリットとなります。
なお、TDDの詳細については、次の記事を参考にしてください。
4-2. BDD（ビヘイビア駆動開発）
BDD（Behavior-Driven Development：ビヘイビア駆動開発）は、ソフトウェアの振る舞い（ビヘイビア）に焦点を当てて開発を進める手法です。
「もし～という操作をしたら、～という結果になる」といった形で振る舞いを定義し、その内容をもとにテストや実装を進めていきます。テストの大枠を固めてからコードを書く点は、TDDと同様です。
振る舞いは、ITエンジニア以外にも理解しやすい言葉で記述されるため、関係者間の共通認識を持てます。密なコミュニケーションが求められるアジャイル開発において、認識のズレによる手戻りを防ぐ効果が期待できます。
4-3. 探索的テスト
探索的テストは、事前に詳細なテストケースを定義せず、テスターの知識や経験にもとづいて設計と実行を並行してテストを進める手法です。実際にソフトウェアを操作し、その結果も加味しながら、テスターの判断で「次に実行すべきテスト」を探索していきます。
詳細なテストケースの作成を省略できるため、短い期間で成果が求められるアジャイルテストと相性が良い手法です。前述のとおり、第3象限（ビジネス指向・プロダクト評価）のアジャイルテストにおいてよく採用されます。
ただし、テストの成果はテスターの熟練度や、対象ソフトウェアへの経験値に強く依存します。十分な知見がないまま漫然と操作しても、効果的なバグ検出にはつながらない点に注意しましょう。
5. まとめ
アジャイルテストとは、アジャイル開発のサイクルに合わせて、短期間で継続的にテストを行う考え方や活動のことです。ウォーターフォールテストとは、実行タイミングやテストケースの扱いが大きく異なります。
4象限の考え方や代表的な手法を理解することで、アジャイルテストの全体像が把握しやすくなります。アジャイルテストの基本を押さえたうえで、自身のプロジェクトに合った形で取り入れていきましょう。
