0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@rikudonoyamaguchi(Riku O)

JSTQB頻出「決定表テスト」を完全攻略する【図解＋Rubyサンプルつき】

0
Last updated at Posted at 2026-04-25

はじめに

JSTQB Foundation Level のテスト設計技法（Chapter 4.2）の中で、受験者が最も苦手とする技法のひとつが「デシジョンテーブルテスト」 です。

  • 同値分割・境界値分析は感覚で解ける
  • 状態遷移テストはUML図で慣れている
  • でもデシジョンテーブルは表の読み方自体がわからない……

そんな声をよく聞きます。

この記事では「デシジョンテーブルとは何か」から「試験問題の解き方」「実務でのRuby実装例」まで、ゼロから丁寧に解説します。

デシジョンテーブルテストとは？

デシジョンテーブル（Decision Table） は、複数の条件の組み合わせに対してシステムがどう振る舞うかを一覧化した表です。

「条件A・B・Cがそれぞれ真/偽のとき、どのアクションを取るか」を漏れなく整理するための設計ツール

仕様書に「〜の場合かつ〜の場合は〜する」という複合条件が出てきたとき、それを見える化するのがデシジョンテーブルの役割です。

デシジョンテーブルの構造を理解する

デシジョンテーブルは大きく4つのブロックで構成されます。

┌──────────────────────┬──────┬──────┬──────┬──────┐
│                      │ルール1│ルール2│ルール3│ルール4│
├──────────┬───────────┼──────┼──────┼──────┼──────┤
│          │ 条件A      │  Y   │  Y   │  N   │  N   │
│ 条件部    │ 条件B      │  Y   │  N   │  Y   │  N   │
├──────────┼───────────┼──────┼──────┼──────┼──────┤
│          │ アクション1 │  X   │      │  X   │      │
│ 動作部    │ アクション2 │      │  X   │      │  X   │
└──────────┴───────────┴──────┴──────┴──────┴──────┘

Y = 条件が真（True）
N = 条件が偽（False）
X = そのアクションを実行する
（空欄）= 実行しない

ルール数の上限 = 2ⁿ（nは条件の数）

条件が2つなら最大4ルール、3つなら最大8ルール、4つなら最大16ルールです。

具体例：ECサイトの割引ロジック

仕様

・会員登録済みユーザーは10%割引
・購入金額が5,000円以上なら送料無料
・上記両方を満たす場合は追加で5%割引（合計15%割引）
・どちらも満たさない場合は割引なし・送料あり

デシジョンテーブル

┌───────────────────────┬──────┬──────┬──────┬──────┐
│                       │ルール1│ルール2│ルール3│ルール4│
├──────────┬────────────┼──────┼──────┼──────┼──────┤
│          │ 会員である   │  Y   │  Y   │  N   │  N   │
│ 条件部    │ 5,000円以上 │  Y   │  N   │  Y   │  N   │
├──────────┼────────────┼──────┼──────┼──────┼──────┤
│          │ 15%割引    │  X   │      │      │      │
│ 動作部    │ 10%割引    │      │  X   │      │      │
│          │ 送料無料    │  X   │      │  X   │      │
│          │ 割引なし    │      │      │      │  X   │
└──────────┴────────────┴──────┴──────┴──────┴──────┘

この表から、テストケースは 4つ 設計すればすべての組み合わせをカバーできます。

Rubyで実装してみる

上記の仕様をRubyで実装し、テストケースと対応させてみましょう。

# app/services/discount_calculator.rb
class DiscountCalculator
  def initialize(member:, amount:)
    @member = member
    @amount = amount
  end

  def call
    {
      discount_rate:,
      free_shipping: free_shipping?
    }
  end

  private

  def discount_rate
    if @member && @amount >= 5_000
      0.15   # ルール1: 会員 かつ 5,000円以上 → 15%割引
    elsif @member
      0.10   # ルール2: 会員のみ → 10%割引
    else
      0.0    # ルール3・4: 非会員 → 割引なし
    end
  end

  def free_shipping?
    @amount >= 5_000   # ルール1・3: 5,000円以上 → 送料無料
  end
end

デシジョンテーブルに対応したRSpecテスト

# spec/services/discount_calculator_spec.rb
RSpec.describe DiscountCalculator do
  # ルール1: 会員 × 5,000円以上
  context "会員かつ5,000円以上（ルール1）" do
    subject { described_class.new(member: true, amount: 5_000).call }
    it { expect(subject[:discount_rate]).to eq 0.15 }
    it { expect(subject[:free_shipping]).to be true }
  end

  # ルール2: 会員 × 5,000円未満
  context "会員かつ5,000円未満（ルール2）" do
    subject { described_class.new(member: true, amount: 4_999).call }
    it { expect(subject[:discount_rate]).to eq 0.10 }
    it { expect(subject[:free_shipping]).to be false }
  end

  # ルール3: 非会員 × 5,000円以上
  context "非会員かつ5,000円以上（ルール3）" do
    subject { described_class.new(member: false, amount: 5_000).call }
    it { expect(subject[:discount_rate]).to eq 0.0 }
    it { expect(subject[:free_shipping]).to be true }
  end

  # ルール4: 非会員 × 5,000円未満
  context "非会員かつ5,000円未満（ルール4）" do
    subject { described_class.new(member: false, amount: 4_999).call }
    it { expect(subject[:discount_rate]).to eq 0.0 }
    it { expect(subject[:free_shipping]).to be false }
  end
end

デシジョンテーブルの4ルール = テストケース4本。これがデシジョンテーブルテストの本質です。条件の組み合わせが明確になるので、テストの抜け漏れが構造的に防げます。

JSTQB試験での出題パターン

パターン① ルール数を問う問題

Q. あるECサイトの配送料計算ロジックをデシジョンテーブルで設計する。判定に使用する条件として以下の3つの独立した項目が存在する時、すべての条件の組み合わせを網羅するのに必要な最小の判定ルール（列）の数として、正しいものはどれか。
- 注文合計金額が5,000円以上か
- 配送先が離島であるか
- プレミアム会員であるか

A. 3
B. 6
C. 8   ← 正解（2³ = 8）
D. 9

公式：ルール数 = 2ⁿ（n = 条件の数） を覚えるだけです。

パターン② デシジョンテーブルの目的を問う問題

Q. デシジョンテーブルテストを使用する最も適切な場面はどれか？

A. 入力値の範囲が広く、境界付近の値を確認したいとき
B. システムの状態遷移を確認したいとき
C. 複数の条件の組み合わせによって異なる動作が仕様に定義されているとき  ← 正解
D. プログラムのすべての命令を実行確認したいとき

「複数条件の組み合わせ」というキーワードが出たらデシジョンテーブルテストを連想してください。

他のブラックボックス技法との使い分け

JSTQB Chapter 4.2 で問われるブラックボックステスト技法を整理しておきましょう。

技法 こんなときに使う キーワード
同値分割 入力が特定の区分に分けられる 有効クラス・無効クラス
境界値分析 区分の境界付近の動作を確認したい 最小値・最大値・境界
デシジョンテーブルテスト 複数条件の組み合わせで動作が変わる AND/OR条件、複合ロジック
状態遷移テスト 入力によってシステムの状態が変化する 状態・遷移・イベント
ユースケーステスト ユーザーの操作シナリオを検証したい シナリオ、アクター

「この仕様にはどの技法が最適か？」という形で出題されるので、この使い分け表は必ず押さえておいてください。

よくある混乱ポイント：デシジョンテーブル vs 状態遷移

どちらも「条件によって動作が変わる」ように見えますが、本質が違います。

デシジョンテーブル：「今この瞬間の複数条件の組み合わせ」で動作が決まる
→ 会員かどうか × 金額 → 割引率（状態を持たない）

状態遷移：「現在の状態 × イベント」で次の状態が決まる
→ ログイン済み状態 × ログアウト操作 → ログアウト状態

デシジョンテーブルのイメージ：
  条件A=Y, 条件B=N → アクションX  （静的な判断）

状態遷移のイメージ：
  状態S1 → イベントE → 状態S2  （時間的な変化）

「どちらが正しい技法か」という設問で迷ったら、時間的な状態変化があるか（→ 状態遷移）、ないか（→ デシジョンテーブル） で判断してください。

まとめ

ポイント 内容
デシジョンテーブルの構造 条件部 + 動作部、ルール数は最大 2ⁿ
使いどき 複数条件の AND/OR が絡む複合ロジック
実務との接続 デシジョンテーブルのルール数 = テストケース数（最小カバレッジ）
他技法との違い 状態変化あり → 状態遷移、条件組み合わせ → デシジョンテーブル

デシジョンテーブルは「表が読めるかどうか」さえ習得すれば、試験でも実務でも確実に点が取れる技法です。苦手意識を持っている人ほど、ここで差がつきます。

問題演習で定着させよう

デシジョンテーブルの問題は、読んだだけでは解けるようになりません。実際に問題を解いて「条件の組み合わせをルールに落とし込む」感覚を身につけることが大切です。

QAドリル では、Chapter 4.2（ブラックボックステスト技法） の問題を章別に絞って演習できます。

デシジョンテーブルテストはもちろん、同値分割・境界値分析・状態遷移テストの問題も収録。各問題には解説がつくので、間違えた理由まで確認できます。

会員登録すると章別の正答率がダッシュボードで可視化されるので、「Chapter 4.2 が弱い」とひと目でわかります。無料なのでぜひ。

関連リンク

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?