はじめに
以前テストチームに携わってた時に、社内研修で学んだディシジョンテーブルの作り方を、身近で個人的にもイメージしやすいモバイル決済キャンペーンを例にして自分の復習も兼ねて紹介したいと思います。
ディシジョンテーブルとは
ディシジョンテーブル（決定表）は、複数の条件判定と、それに伴う動作を視覚的に表現したものです。
ディシジョンテーブルは日本工業規格（JIS）で定義をされています。JISでは「問題の記述において起こり得るすべての条件と、それに対して実行すべき動作とを組み合わせた表と定義されています。
全体を俯瞰的に表現するための効率的な表現方法で、テスト設計だけでなく、通常の設計書などにも用いられます。(研修資料より)
○Payキャンペーンの概要
- S会社、Y会社スマホユーザー、Yプレミアム会員なら10時～14時は対象のスーパーマーケットで○Pay残高でのお支払いで10%戻ってくる。
- 上記以外の○Payユーザーでも5%戻ってくる。
ディシジョンテーブル記載方法
基本的な構成
ディシジョンテーブルは下記の4つの領域から構成されています。
各記述部と指定部の記載方法
①条件記述部 ... 実行する条件を記載します。（例：S会社スマホユーザーである）
②条件指定部 ... その条件に対する値を指定します。（例：S会社スマホユーザーである Yes／No）
③動作記述部 ... 条件指定部に指定されたケースごとに実行される動作を定義します。（例：○Payで支払う）
④動作指定部 ... テスト設計で使用する場合、想定結果を記述します。（例：○Payで支払った場合の還元率）
ディシジョンテーブルを書くときの留意点
- どういう条件でテストしたのかわかるように書く。
- OR条件指定する場合はひとつづつになるよう条件に指定する。
- 何をどう確認したのかわかるように書く。
- ディシジョンテーブルの縦や横のサイズには制限はありませんが、適切なサイズになるように分割をする。
- 条件指定部がランダムになるとわかりづらいので規則的に書く。
規則的だとケースに漏れがないかの確認しやすいし、ケースをコピペで追加しやすいです。
※Yに色をつけてみました。規則的に並んでいることがわかりますでしょうか？
- テスト設計書はどの書式で書けば適切な表現ができるかを考えて書式を選択。すべてをディシジョンテーブルで表現しなくてもOKです。
上記のやり方だとテストケースが右横に増えていきますが、私が以前経験したテストチームは下の図のように縦にケースを増やす方法でやってました。今までの現場ではテストの消化率や不具合率を集計してたので、縦の方がやりやすかったのではないかと思います。
ディシジョンテーブル作成例
テストケースの設定に漏れはありませんか？
キャンペーンの概要の中に、対象外の場合の還元率についての記載がないことに気づきましたでしょうか？
システム開発の場合、提示されていない仕様を見つけたら要件担当者に仕様を確認する必要がありますが、今回は説明用なので一律1%としました。
それと、14:00って14:00:59までOKなのか？14:00:01はアウトなのか？も気になるところですが、説明用なので割愛します。 
ディシジョンテーブルを書いて整理整頓すると、仕様の曖昧さや、間違いを発見できることも書く利点だと思います。
なるべく最小の時間と労力でエラーを検出したい
作成例ではテスト16ケースでしたが、グレーアウトした4ケースは省略可能です。
なぜかというと、対象のスーパー？と時間帯10:00～14:00？は AND条件 だからです。
No5～12の間で片方がfalseの場合にキャンペーン対象外の確認ができているので、両方falseのケースは省略可能です。処理の詳細を知っていたら、もっと省略できるケースはありそうです。
ケース作成が慣れないうちは、はじめから不要なケースを省略して作成すると漏れが発生する可能性がある為、一旦、全組み合わせを洗い出し、その後に不要なケースを見つけ、何故不要かも理由をメモして省略した方が安全です。
応用問題
○Payキャンペーン概要に、以下の条件も必要であることが判明しました。
ディシジョンテーブルにも追加してください。
-
条件を追加：対象期間 2020年3月4日～3月31日まで
-
回答例
※あくまで回答例でこの書き方だけが正解というわけではありません。No.17～32は省略できるケースですが参考までに全パターン載せました。
さいごに
期間など範囲を条件に指定する場合は本来は境界値テストが必要ですが、それはまたの機会にやりたいと思います。 