【JSTQB試験対策】ブラックボックステスト技法③「デシジョンテーブルテスト」について、分かりやすく解説
デシジョンテーブルテストとは
JSTQB Foundation Level試験を目指して学習中の皆さん、こんにちは。前回は「境界値分析」について解説しましたが、今回は複数の条件の組み合わせを整理する際に役立つ「デシジョンテーブルテスト」について詳しく解説していきます。
システムの振る舞いは、1つの条件だけで決まるとは限りません。「会員かどうか」「購入金額が基準以上か」「クーポンを持っているか」など、複数の条件の組み合わせによって処理結果が変わることがあります。このような複雑なルールを表形式で整理し、テストケースへ落とし込むための技法がデシジョンテーブルテストです。
デシジョンテーブルテストの定義
デシジョンテーブルテストとは、複数の条件の組み合わせと、それぞれの組み合わせで実行される動作や結果を表形式で整理し、各ルールからテストケースを設計するブラックボックステスト技法です。
文章だけで書かれた複雑な仕様は、条件の組み合わせを見落としたり、同じ条件に対して異なる結果が定義されていることに気づきにくかったりします。デシジョンテーブルを作成すると、条件と結果の関係を一覧で確認できるため、テストケースの抜け漏れを防ぐだけでなく、仕様の不足や矛盾を見つけることにもつながります。
デシジョンテーブルの基本構造
条件・ルール・アクション
デシジョンテーブルは、主に「条件」「ルール」「アクション」の3つの要素で構成されます。
- 条件：システムの判断に影響する入力や前提
- ルール：条件を組み合わせた1つのパターン。通常は表の1列で表す
- アクション：その条件の組み合わせで実行される処理や期待結果
一般的なデシジョンテーブルでは、条件とアクションを行に並べ、条件の組み合わせであるルールを列に並べます。各列を確認することで、「どの条件がそろったときに、どのアクションが実行されるのか」を明確にできます。
デシジョンテーブルで使用する主な記号
| 記号 | 意味 |
|---|---|
| T | 条件を満たす（True） |
| F | 条件を満たさない（False） |
| ― | その条件の値が結果に影響しない（どちらでもよい） |
| N/A | そのルールでは実現できない条件の組み合わせ |
| X | そのアクションを実行する |
なお、実務ではTとFだけでなく、「一般会員／プレミアム会員」のような区分や、数値の範囲などを条件として記載する場合もあります。仕様に合わせて、判断しやすい値で表を作成しましょう。
■重要なポイント
デシジョンテーブルでは、1つの列が1つのルールを表します。原則として、実行可能な各ルールから少なくとも1つのテストケースを作成します。
デシジョンテーブルテストの実践手順
実際にデシジョンテーブルからテストケースを作成する手順を見ていきましょう。
ステップ1：仕様とビジネスルールを確認する
まず、テスト対象の仕様を読み取り、どのような条件によって処理結果が変わるのかを確認します。「もしAかつBなら」「Cの場合を除く」といった表現に注目しましょう。
ステップ2：条件とアクションを洗い出す
判断に影響する条件と、システムが実行するアクションや期待結果を整理します。条件を曖昧なまま表へ入れると組み合わせを正しく作れないため、TとFを明確に判断できる表現にすることが大切です。
ステップ3：条件の組み合わせをルールとして並べる
条件が取り得る値を組み合わせ、ルールを列として並べます。すべての条件がTまたはFの2通りであれば、条件が2個の場合は最大4通り、3個の場合は最大8通りの組み合わせが考えられます。
ステップ4：各ルールのアクションを決める
仕様に基づき、それぞれのルールで実行されるアクションにXを付けます。この段階で結果を決められない列があれば、仕様が不足している可能性があります。また、実現できない組み合わせや、結果に影響しない条件がある場合も整理します。
ステップ5：ルールからテストケースを作成する
実行可能な各ルールを少なくとも1回ずつ確認できるように、具体的な入力値と期待結果を設定します。「―」が記載された条件についても、実際のテストではTまたはFに相当する具体的な値を選ぶ必要があります。
具体例で理解するデシジョンテーブルテスト
例：ログイン機能のテスト
次のようなログイン機能をテストする場合を考えてみましょう。
仕様：
- アカウントがロックされている場合は、IDとパスワードの内容にかかわらずログインを許可せず、アカウントロックのメッセージを表示する
- アカウントがロックされておらず、IDとパスワードがどちらも正しい場合はログインを許可する
- アカウントがロックされておらず、IDまたはパスワードに誤りがある場合は、認証エラーを表示する
この仕様をデシジョンテーブルに整理すると、以下のようになります。
R1ではアカウントがロックされているため、IDとパスワードが正しいかどうかは結果に影響しません。そのため、該当する条件を「―」で表しています。
また、R3ではIDが誤っている時点で認証エラーになるため、パスワードの正誤は結果に影響しません。このように、結果を変えない条件を「―」でまとめることで、同じ結果となる複数の組み合わせを1つのルールとして整理できます。
テストケースへの落とし込み
| テストケース | アカウント状態 | ID | パスワード | 期待結果 |
|---|---|---|---|---|
| TC1（R1） | ロック中 | 任意 | 任意 | アカウントロックを表示 |
| TC2（R2） | ロックなし | 正しい | 正しい | ログイン成功 |
| TC3（R3） | ロックなし | 誤り | 正しい値を選択 | 認証エラーを表示 |
| TC4（R4） | ロックなし | 正しい | 誤り | 認証エラーを表示 |
4つのルールをそれぞれ1つのテストケースで確認することで、条件の組み合わせによるログイン判定を体系的にテストできます。
デシジョンテーブルカバレッジ
デシジョンテーブルテストでは、実行可能なルールをどれだけテストしたかによってカバレッジを測定します。
デシジョンテーブルカバレッジ（％）
＝ テストした実行可能なルール数 ÷ 実行可能なルールの総数 × 100
今回の例では、実行可能なルールはR1〜R4の4つです。4つすべてをテストすれば、カバレッジは「4÷4×100＝100％」となります。
100％のデシジョンテーブルカバレッジを達成するには、実行可能なすべてのルールを少なくとも1回ずつテストします。
デシジョンテーブルテストのメリット
デシジョンテーブルテストを活用することで、以下のようなメリットが得られます。
1. 条件の組み合わせを体系的に確認できる
条件を表形式で整理するため、思いついたパターンだけをテストする場合に比べ、見落としやすい組み合わせも確認しやすくなります。
2. 複雑なビジネスルールを可視化できる
割引判定、料金計算、アクセス制御など、複数の条件が関係する仕様を一覧化できます。開発者・テスト担当者・業務担当者の間で認識を合わせる際にも役立ちます。
3. 仕様の抜けや矛盾を発見しやすい
期待結果を決められない組み合わせや、同じ条件に異なる結果が割り当てられている箇所を発見しやすくなります。テスト設計を通じて、仕様そのものの品質向上にもつながります。
4. テストの根拠が明確になる
どのルールからテストケースを作成したかが分かるため、テストの網羅範囲を説明しやすくなります。仕様変更時に影響を受けるルールを特定しやすい点もメリットです。
デシジョンテーブルテストの注意点
デシジョンテーブルテストは非常に有用な技法ですが、以下の点に注意が必要です。
⚠️ 条件が増えるとルール数が急増する
TとFの2通りを取る条件がn個ある場合、完全な組み合わせは最大で2のn乗になります。条件が多いと表やテストケースが大きくなるため、実現不可能なルールを除外したり、結果に影響しない条件を「―」でまとめたりする必要があります。
⚠️ 条件とアクションの洗い出しが不十分だと漏れが残る
デシジョンテーブルに記載されていない条件はテスト対象として認識されにくくなります。仕様書だけで判断できない場合は、設計者や業務担当者へ確認し、判断に影響する条件を漏れなく整理しましょう。
⚠️ 「―」にも具体的なテストデータが必要
「―」は、その条件が結果に影響しないことを示す記号です。しかし、実際にテストを実行する際には具体的な値が必要になります。どの値を選択したのかをテストケースへ明記し、必要に応じて別の値でも確認しましょう。
JSTQB試験での出題ポイント
JSTQB Foundation Level試験では、デシジョンテーブルを読み取り、条件に合うルールやテストケースを判断できることが重要です。以下のポイントを押さえておきましょう。
- 📌 表の構造：条件とアクションが行、ルールが列に配置されることを理解する
- 📌 記号の意味：T、F、X、「―」、N/Aを正しく読み取る
- 📌 テストケースの導出：指定されたルールを満たす入力値と期待結果を選ぶ
- 📌 カバレッジの計算：テストしたルール数を実行可能なルールの総数で割る
- 📌 仕様の問題点：ルールの欠落、重複、矛盾、実現不可能な組み合わせを見分ける
まとめ
デシジョンテーブルテストは、複数の条件の組み合わせによって結果が変わる仕様をテストする際に効果的な技法です。以下のポイントを再確認しましょう。
- デシジョンテーブルテストは、条件の組み合わせとアクションを表形式で整理するブラックボックステスト技法
- 1つの列が1つのルールを表し、各ルールからテストケースを作成する
- 「―」は条件の値が結果に影響しないことを示す
- 実行可能なすべてのルールをテストすると、デシジョンテーブルカバレッジは100％になる
- 条件の組み合わせの漏れだけでなく、仕様の不足や矛盾を発見する際にも役立つ
複数の条件が関係する仕様を文章だけで理解しようとすると、思わぬ組み合わせを見落としてしまうことがあります。デシジョンテーブルを活用し、条件と期待結果を見える形に整理することで、効率的かつ根拠の明確なテストケースを設計できるようになります。実務でもJSTQB試験でも、表の各ルールから具体的なテストケースを導けるようにしておきましょう。
次回は、システムの状態とイベントによる変化を整理する「状態遷移テスト」について詳しく解説していきます。
JSTQB(日本ソフトウェアテスト技術者資格)は、ソフトウェアテストの専門的な知識と技術を認定するための資格です。この資格は、ソフトウェアテストのプロフェッショナルとして必要なスキルを証明するものとして、業界で広く認知されています。
JSTQBは、国際的な基準であるISTQB（International Software Testing Qualifications Board）に基づいており、日本国内のソフトウェアテスト分野における実務能力を向上させるための指針となっています。
株式会社NSITでは、ソフトウェアテストに従事するエンジニアの約9割が、JSTQBの資格を取得しております。
