デシジョンテーブルについて
こんにちは、Yumihikiです。今回はテスト技法のひとつである「デシジョンテーブル」について解説します。
デシジョンテーブルとは、一言でいうと複雑な仕様を整理するためのテスト技法の1つです。表形式で因子・水準と対応する結果を表現したものです。
例えば、あるECサイトを運営しているとします。
その際、購入するユーザーと条件に対し、次のプログラム仕様書があった場合を想定します。
学生は平日・土日問わず、常時10%オフとする。
社会人は休日は5%オフとする。
上記を表すと次のようなデシジョンテーブルになります。
ざっくりとそれぞれの英語・記号を解説しておくと次のような意味合いになります。
Y:Yes
N:No
X:Execute（実行した場合に求まる結果を指す）
-：無関係・非該当
ここでいうと、学生・社会人・平日と書いてある青背景部分が条件部分で割引なし・5%オフ・10%オフと書いてある黄色背景部分が結果の部分になります。
デシジョンテーブルを利用することで、複数の条件の組み合わせの結果がどのように影響するのかが分かりやすくなります。
先ほどの画像の例だと比較的シンプルな条件なので、先の例の仕様書をもう少し複雑にしてみましょう。
学生は平日・土日問わず、常時10%オフとする。
社会人は土日は5%オフとする。
また、学生・社会人以外のユーザーは平日は10%オフ、休日は割引はなしである。
ただし、購入時間が平日8時〜17時の場合、学生は10%オフから20%オフになり社会人も5%オフになる。
その他ユーザーは購入時間による割引は行わないものとする。
新たにユーザーの区分が学生・社会人以外が増え、購入時間の概念が増えました。ぱっと見だと、どの区分がどういう条件で割引になるのかよく分かりません。
これをデシジョンテーブルに置き換えると次のようになります。
どうでしょうか。文章だけより、組み合わせと出力結果が分かりやすくなったのでは無いでしょうか？ 実際のプログラム・ビジネスロジックは複雑だったりすることが多いのでデシジョンテーブルを利用することで仕様を整理することができるというメリットがあります。
また、自分が実際に利用してみて良いなと思ったのは仕様の漏れや矛盾に気が付くことができるということです。今回の例で挙げている仕様でも当初「その他ユーザー」は時間の割引はどうするの？ 割引の条件が重なるとどうなるの？ ということに気が付くことができました。
デメリットを挙げると、関係の無い因子・水準を挙げてしまうとテストケース数が膨大になってしまいます。今回のケースだと12パターンのみですが、例えばこのケースに1つ新たに性別などの条件が加わっただけで24パターンにテストケースが増えることになります。
そのため、関係の無い因子・水準があれば分割する必要があります。
というわけで今回はデシジョンテーブルについてまとめてみました。
エンジニアとして働く中で、テストは開発のある意味基礎的なところだなと思ったので、引き続きテストについて学んだことをまとめていこうと思います。
