デシジョンテーブルテスト

デシジョンテーブルテスト（Decision Table Testing）とは、条件の組み合わせと対応するアクション（システムの振る舞い）を表形式で整理し、テストケースを導出するブラックボックステスト技法です。JSTQB AL TA シラバスv3.1.1（3.2.3節）に定義されています。複数の条件が絡み合うビジネスルールの検証に特に有効です。

デシジョンテーブルの構成

デシジョンテーブルは以下の4要素で構成されます。

基本構造の例

T = True（真）、F = False（偽）、✓ = 実行、- = 非実行

制限指定デシジョンテーブルと拡張指定デシジョンテーブル

制限指定デシジョンテーブル（Limited-Entry Decision Table）

各条件の値を True / False（またはYes / No）の二値のみ で表現するテーブル。

• 条件が n 個の場合、最大 2ⁿ 通りのルールが存在する
• シンプルで読みやすいが、多値条件には向かない

拡張指定デシジョンテーブル（Extended-Entry Decision Table）

各条件に 複数の値（列挙値・範囲など） を許容するテーブル。

• 例：優先度 = 高 / 中 / 低、金額 = 1万円未満 / 1〜10万円 / 10万円超
• 多値条件を自然に表現でき、テーブルをコンパクトに保てる

テーブルの簡単化（Minimization）

条件数が多い場合、全組み合わせの列数が膨大になります。以下の手法でテーブルを簡単化できます。

ドントケアエントリ（Don't Care Entry）

アクションの結果に影響しない条件は 「-」（ドントケア） として表記し、複数のルールを1列にまとめます。

上記例では、条件Aが Trueであれば条件Bに関わらずアクションXが実行されるため、2ルールを1ルールにまとめられます。

不可能ルールの除外

現実に発生しえない条件の組み合わせは、テーブルから除外します。

• 例：「ゲストユーザー」かつ「管理者権限あり」という組み合わせは存在しない

テスト設計の手順

1. テスト対象のビジネスルール・仕様を分析し、条件とアクションを洗い出す
2. デシジョンテーブルの種別（制限指定 or 拡張指定）を選択する
3. 全条件の組み合わせを列挙し、各ルールに対応するアクションを埋める
4. ドントケア を適用してテーブルを簡単化する
5. 不可能ルール を除外する
6. 各ルール（列）を1つのテストケースとして実装し、期待結果を記述する

カバレッジ基準

シラバスでは 全ルールカバレッジ が基本的な達成基準として推奨されています。

検出できる欠陥の種類

• 条件の組み合わせに対するアクションの誤り（例：特定の条件組み合わせで誤った処理が実行される）
• 特定ルールの未実装（例：条件が全てFalseの場合の処理が定義されていない）
• 複数の条件が絡むビジネスルールの矛盾（例：同じ条件組み合わせに対して矛盾したアクションが定義されている）
• ドントケアの誤適用（本来影響する条件を無視している）

適用場面

デシジョンテーブルテストは以下のような場面で特に効果的です。

• 複数の条件が組み合わさって異なる結果をもたらすビジネスロジック
• 保険・金融・税計算など複雑なルールが存在するシステム
• 条件の組み合わせが要件として明示的に定義されている仕様書・ユーザーストーリー
• 状態に依存しない入力→出力の対応が中心の機能

注意点

• 条件数が増えると組み合わせが指数的に増大する（n 条件で最大 2ⁿ ルール）。ドントケアや拡張指定テーブルを活用して管理可能な規模に保つ
• デシジョンテーブルは状態遷移のない静的な対応関係に適している。状態依存の振る舞いには状態遷移テストを併用する
• 仕様書に記載のないルール（暗黙の前提条件）の抜け漏れに注意する

他のテスト技法との関係