テスト設計技法とは、テストケースを効率よく設計するための体系的な方法です。すべての入力値や条件をテストすることは現実的ではないため、バグを見つけやすい代表的なパターンを選び出してテストします。
代表的な技法には以下があります。
- 同値分割
- 境界値分析
- デシジョンテーブル
- 状態遷移テスト
テストの目的や対象システムの特性に応じて使い分けることが重要です。
📌 この記事はこんな方におすすめ
- テスト設計技法の全体像を把握したいQAエンジニア・開発者
- どの技法をどの場面で使えばいいか整理したい方
- JSTQB・テスト資格の学習に役立てたい方
- 自動テストのテストケース設計をより体系的にしたい方
✅ この記事を読むと得られること
- 7つのテスト設計技法の特徴・用途・使い分けがわかる
- 場面に応じて最適な技法を選べるようになる
- 各技法の詳細解説記事へのリンクで深堀りできる
👤 この記事を書いた人
QAエンジニア・テスト自動化エンジニアとして15年以上の実務経験を持つ Yoshi が執筆。テスト設計技法は実際のプロジェクトで毎日使う知識です。実装コードはGitHubで公開中：github.com/YOSHITSUGU728/automated-testing-portfolio
「テストケースが多すぎて管理できない」「どこをテストすれば十分かわからない」——こうした悩みを解決するのがテスト設計技法です。この記事ではQAエンジニアが実務で使う7つの主要な技法を、比較早見表・各技法の詳細・使い分けの目安まで一気通貫で解説します。
📌 結論
- テスト設計技法は「何をテストするか」ではなく「どう効率よくバグを見つけるか」のアプローチ
- 7つの技法はそれぞれ得意な場面が異なり、組み合わせて使うのが実務の基本
- まず同値分割・境界値分析を習得し、システムの特性に応じて他の技法を加えるのが最短ルート
テスト設計技法7選 比較早見表
| 技法名 | 得意な場面 | 難易度 | 自動化との相性 | よく使う場面 |
|---|---|---|---|---|
| ① 同値分割 | 入力値の範囲・種類の検証 | ⭐ 初級 | ◎ parametrize | 入力バリデーション |
| ② 境界値分析 | 範囲の端・Off-by-oneエラー | ⭐ 初級 | ◎ parametrize | 数値範囲チェック |
| ③ デシジョンテーブル | 複数条件の組み合わせ | ⭐⭐ 中級 | ○ parametrize | 権限管理・業務ロジック |
| ④ 状態遷移テスト | 状態を持つシステム・フロー | ⭐⭐ 中級 | ◎ E2Eテスト | ログイン / EC カート |
| ⑤ ユースケーステスト | ユーザー操作フロー全体 | ⭐⭐ 中級 | ◎ E2Eテスト | 購入フロー・会員登録 |
| ⑥ ペアワイズテスト | 多数の組み合わせの効率化 | ⭐⭐⭐ 上級 | ○ parametrize | OS / ブラウザ組み合わせ |
| ⑦ エラー推測 | 経験則・バグパターンの活用 | ⭐⭐⭐ 上級 | △ 経験依存 | NULL / 特殊文字 / 境界補完 |
① 同値分割（Equivalence Partitioning）とは
目的
- 同じ動作をする入力値をグループ化してテスト数を削減する
- 有効・無効の両方のクラスを網羅する
- 「代表値1つで十分」という考え方でテストを効率化する
入力値を「同じ動作をするグループ（同値クラス）」に分割し、各グループから代表値を1つだけ選んでテストする技法です。年齢・文字数・数値範囲など「範囲条件」があるフィールドに特に有効です。
✅ 向いているケース
| ⚠️ 向いていないケース
|
② 境界値分析（Boundary Value Analysis）とは
目的
- 同値クラスの境界（端）の値を重点的にテストする
- Off-by-oneエラー（
>=と>の混同など）を発見する - 同値分割と組み合わせて使い、バグ検出率を高める
バグは境界付近で最も多く発生することが統計的に示されています。各同値クラスの境界値・境界値−1・境界値+1 の3点をテストする「3点法」が基本です。
✅ 向いているケース
| ⚠️ 向いていないケース
|
parametrize を使うと境界値テーブルをそのままコードに変換できます。設計表→コードの流れが最短です。③ デシジョンテーブルテストとは
目的
- 複数の条件の組み合わせを漏れなく整理する
- 条件の爆発（2条件×2値=4パターンなど）を視覚的に管理する
- 業務ルールや権限管理など複雑なロジックの検証に使う
複数の条件が絡み合うシステムでは、条件の組み合わせが漏れなくテストできているか確認するのが難しくなります。デシジョンテーブルは「条件」と「アクション（期待結果）」を表形式で整理することで、組み合わせの網羅性を担保します。
デシジョンテーブルの例（ログイン処理）
| 条件 / アクション | ケース1 | ケース2 | ケース3 | ケース4 |
|---|---|---|---|---|
| IDが正しい | ✅ Yes | ✅ Yes | ❌ No | ❌ No |
| パスワードが正しい | ✅ Yes | ❌ No | ✅ Yes | ❌ No |
| → ログイン成功 | ✅ | ❌ | ❌ | ❌ |
✅ 向いているケース
| ⚠️ 向いていないケース
|
④ 状態遷移テストとは（State Transition Testing）
目的
- システムの「状態」と「遷移条件」を整理してテストケースを設計する
- 状態の遷移が正しく行われるか・無効な遷移が正しく拒否されるかを確認する
- ECカート・ログインフロー・注文状態など状態を持つシステムに有効
システムは「ログアウト中」→「ログイン中」→「カート追加済み」のように状態を持ちます。状態遷移テストはこの状態の流れを図や表で整理し、「すべての正常遷移」と「無効な遷移」の両方をテストします。
状態遷移の例（ECサイトの注文状態）
| 現在の状態 | イベント（操作） | 次の状態 | 確認ポイント |
|---|---|---|---|
| カート未追加 | 商品を追加 | カート追加済み | カートバッジが表示されるか |
| カート追加済み | 購入を確定 | 注文確定 | 確認メールが送られるか |
| 注文確定 | キャンセル申請 | キャンセル済み | 在庫が戻るか |
| キャンセル済み | 再度キャンセル（無効） | キャンセル済み（変化なし） | エラーまたは無視されるか |
✅ 向いているケース
| ⚠️ 向いていないケース
|
⑤ ユースケーステストとは（Use Case Testing）
目的
- ユーザーの一連の操作フロー（ユースケース）をテストシナリオに変換する
- 基本フロー（正常系）と代替フロー（異常系・例外系）を網羅する
- E2Eテストのシナリオ設計に直結する技法
ユースケーステストは「ユーザーがゴールを達成するまでの操作の流れ」をテストケースとして設計します。「商品を購入する」というユースケースなら、ログイン→商品選択→カート追加→決済→完了確認という一連のフローをテストします。
✅ 向いているケース
| ⚠️ 向いていないケース
|
⑥ ペアワイズテストとは（Pairwise Testing）
目的
- 多数のパラメータの組み合わせを最小のテスト数で網羅する
- 「任意の2つのパラメータの組み合わせが少なくとも1回テストされる」ことを保証する
- 全組み合わせテストと比べてテスト数を大幅に削減できる
パラメータが3個×3値=27通り、4個×3値=81通りと爆発する組み合わせテストを、ペアワイズ法を使うことで9〜12件程度に削減できます。研究によると、ほとんどのバグは2つのパラメータの相互作用から発生するという知見に基づいています。
✅ 向いているケース
| ⚠️ 向いていないケース
|
allpairspy（Python）などのツールで自動生成できます。生成したパラメータセットをpytestの parametrize に渡すとそのまま自動テストになります。⑦ エラー推測とは（Error Guessing）
目的
- 過去の経験・バグのパターンをもとに「バグが出そうな値」を直感的にテストする
- 他の技法では見つけにくい「経験的に危ない」ケースを補完する
- QAエンジニアの勘と知識を体系的に活かす
エラー推測はテスト技法の中で唯一「経験と直感」に基づく技法です。「0や負の数は危ない」「NULL・空文字は落とし穴」「SQLインジェクション文字列」「非常に長い文字列」など、過去の経験から「バグが出やすい値」を積極的にテストします。
よく使われるエラー推測の値
| カテゴリ | 具体的な値の例 |
|---|---|
| 数値系 | 0、-1、最大値+1、小数、整数オーバーフロー値 |
| 文字列系 | 空文字、スペースのみ、非常に長い文字列（1000文字以上）、全角・半角混在 |
| 特殊文字系 | シングルクォート、セミコロン（SQLインジェクション）、<script>（XSS） |
| NULL・未入力系 | NULL値、undefined、空配列、未選択状態 |
✅ 向いているケース
| ⚠️ 向いていないケース
|
技法の導入順序と使い分け
7つの技法をどの順番で学び、どう使い分けるかをまとめます。
| ステップ | 技法 | 使う場面 |
|---|---|---|
| STEP 1 | 同値分割 → 境界値分析 | 入力値の検証・フォームバリデーション（最初に習得） |
| STEP 2 | デシジョンテーブル | 業務ロジック・権限管理の条件組み合わせ |
| STEP 3 | 状態遷移テスト → ユースケーステスト | E2Eテスト・フロー全体の検証 |
| STEP 4 | ペアワイズテスト | 多パラメータの組み合わせ最適化 |
| 常に併用 | エラー推測 | 他の技法を補完する経験的なテスト追加 |
📖 関連記事
FAQ：テスト設計技法についてよくある質問
Q. テスト設計技法はすべて覚える必要がありますか？
いいえ。まず同値分割と境界値分析を理解するだけで実務の多くのケースに対応できます。この2つをマスターしてから、テスト対象の複雑さに応じてデシジョンテーブル・状態遷移テストを加えていくのが現実的な習得順序です。
Q. 自動テストでもテスト設計技法は必要ですか？
必要です。むしろ自動テストと相性が良い技法が多いです。pytestの @pytest.mark.parametrize は同値分割・境界値分析と非常に相性が良く、設計した表をそのままコードに変換できます。テスト設計なしに自動テストだけ増やしても、重要な箇所を見逃したまま「テストがある」という安心感だけが生まれてしまいます。
Q. JSTQBで重要な技法はどれですか？
JSTQB（Foundation Level）では同値分割・境界値分析・デシジョンテーブル・状態遷移テストが特に重要です。この4つは試験の頻出テーマであり、実務でも最も使用頻度が高い技法です。まずこの4つを優先して学習することをおすすめします。
Q. 複数の技法を組み合わせて使ってもいいですか？
むしろ組み合わせるのが実務の標準です。例えば「同値分割でグループを定義 → 境界値分析で境界をテスト → エラー推測で経験的に危ない値を追加」という流れが典型的です。1つの技法だけで完結させようとするより、目的に応じて複数を組み合わせるほうが網羅性と効率のバランスが取れます。
📋 この記事のまとめ
- 同値分割・境界値分析：入力値検証の基本。まず最初に習得すべき2技法
- デシジョンテーブル：複数条件の組み合わせを漏れなく整理する技法
- 状態遷移テスト：状態を持つシステムのフロー検証に最適
- ユースケーステスト：E2Eテストのシナリオ設計に直結する技法
- ペアワイズテスト：多パラメータの組み合わせ爆発を効率的に解消
- エラー推測：経験則で他の技法を補完する最後の仕上げ
テスト設計技法は「全部を常に使う」ものではなく、「テスト対象の特性に応じて最適な技法を選ぶ」ものです。まずは同値分割・境界値分析をマスターし、システムの複雑さに応じてデシジョンテーブル・状態遷移テストを加えていくのが実務での最短ルートです。
