アジャイル開発におけるテストは、従来型の「テストレベル」や「テストタイプ」だけでなく、ビジネス視点と技術視点の両側面から考える必要があります。
そこで登場するのが、「テスト・クアドラント（Test Quadrants）」という考え方です。
この記事では、ISTQB Agile Tester Extension（アジャイルテスター拡張版）のシラバス「3.1.3 Test Quadrants, Test Levels and Testing Types」で登場する内容を、図解イメージと具体例を交えながらわかりやすく解説します。
🔶 テスト・ピラミッド（復習）
前回のトピック「テストピラミッド」では、次のような考え方を学びました。
-
下層（単体テスト）：自動化テストが中心で数が多い
-
上層（UIやシステムテスト）：手動テストや総合的な確認が中心
このピラミッドの発展型として、今回紹介する「テストクアドラント」は、テストの目的と性質を整理するための4象限モデルです。
🧭 テスト・クアドラント（Test Quadrants）とは？
テストクアドラントは、テストを以下の2軸で分類します。
|
観点 |
内容 |
|---|---|
|
縦軸：目的 |
ビジネス（顧客・プロダクト視点） vs 技術（開発者・品質特性視点） |
|
横軸：性質 |
サポートする（仕様を確認する） vs 批判する（欠陥や問題を見つける） |
その結果、次のように4つのクアドラントに分かれます。
🟩 クアドラント1（Q1）：単体レベルテスト（技術・支援）
目的：開発者視点の技術的品質を支える
-
対象：コード単位の機能やロジック
-
実施者：主に開発者
-
方法：ユニットテスト、TDD（テスト駆動開発）など
-
実施タイミング：継続的インテグレーション（CI）の一環として自動化されることが多い
💡具体例
たとえば、関数 calculateTax() の計算結果を確認するためのJUnitテストなど。
→ 「入力が100のとき税額が10％なら、出力は110である」など。
🟨 クアドラント2（Q2）：機能・ストーリーレベルテスト（ビジネス・支援）
目的：ユーザーストーリーの受け入れ条件を満たしているか確認する
-
対象：ユーザー機能全体（ビジネス要件）
-
実施者：テスター、PO（プロダクトオーナー）、開発者が共同で実施
-
方法：受け入れテスト、シナリオテスト、プロトタイプやシミュレーション
-
実施タイミング：各スプリント内（Definition of Doneを確認）
💡具体例
ユーザーストーリー：「ユーザーはカートに商品を追加できる」
→ 受け入れ条件：「合計金額が正しく更新される」「商品が削除できる」など。
→ これらを自動化（BDD/Gherkin形式など）して確認することも多い。
🟦 クアドラント3（Q3）：システム／ユーザー受け入れテスト（ビジネス・批判）
目的：ビジネス価値やユーザー体験の確認
-
対象：完成したシステム全体（業務フロー、UX）
-
実施者：テスター、顧客、ユーザー代表など
-
方法：アルファテスト、ベータテスト、ユーザビリティテスト
-
特徴：現実に近い環境でのユーザー目線の検証
💡具体例
顧客が実際にアプリを触って、「使いにくい点」「理解しづらい動線」などをフィードバック。
→ ここで出た改善点は次のスプリントのバックログに反映。
🟥 クアドラント4（Q4）：システム／運用受け入れテスト（技術・批判）
目的：システムが実運用で問題なく動作するかを検証
-
対象：非機能要件（性能、セキュリティ、可用性、保守性など）
-
実施者：テスター、運用チーム、技術担当者
-
方法：負荷テスト、ストレステスト、セキュリティテスト、回帰テストなど
-
実施タイミング：デプロイ前やステージング環境で実施
💡具体例
-
パフォーマンステスト：1000ユーザー同時アクセス時のレスポンス時間
-
セキュリティテスト：SQLインジェクション攻撃の防御確認
-
耐久テスト：長時間稼働によるメモリリークの検出
🧩 クアドラントのまとめ表
|
クアドラント |
テストレベル |
観点 |
主な目的 |
実施者 |
例 |
|---|---|---|---|---|---|
|
Q1 |
単体 |
技術 |
コード品質の保証 |
開発者 |
ユニットテスト、自動化テスト |
|
Q2 |
機能／ストーリー |
ビジネス |
要件通りに動作しているか |
開発者・PO・テスター |
受け入れテスト、シナリオテスト |
|
Q3 |
システム／UAT |
ビジネス |
ユーザー満足度の検証 |
テスター・顧客 |
アルファ／ベータテスト |
|
Q4 |
システム／運用 |
技術 |
非機能要件の確認 |
テスター・運用担当 |
負荷テスト、セキュリティテスト |
💬 ポイントまとめ
-
Q1・Q2 → 「プロダクトを支援するテスト」
（仕様通りに作れているかを確認）
-
Q3・Q4 → 「プロダクトを批判するテスト」
（本当に価値があるか、実環境で耐えられるかを検証）
-
アジャイルでは「全員でテストする（Whole Team Approach）」が基本。
クアドラントはテスターだけでなく、チーム全体の共通理解ツールとして活用されます。
🧠 試験対策ポイント（ISTQB Agile Tester）
-
Q1〜Q4の目的と特徴を正しく分類できるかが問われやすい
-
「ビジネス／技術」「支援／批判」の2軸をしっかり覚える
-
Q2が「Definition of Done（完了の定義）」と最も関係が深い点にも注意
✅ まとめ
アジャイル開発では、「どのテストを誰がどの目的で行うか」をチーム全員で共有することが重要です。
テストクアドラントは、テスト活動を整理し、バランスの取れた品質保証を実現するための有効なフレームワークです。
コメント