デシジョンテーブルの圧縮でバグの見逃しが発生するとはどういうことか？

圧縮したデシジョンテーブルを使ってテストを行なうことの危険性については以前に説明しました。その時あげた例はあまり一般的ではなかったので、今回はより一般的に起きやすい例をあげてみることにします。今回取り上げる例はある博覧会の入場料を決定する仕様です。

ある博覧会の入場料を決定する仕様は次のように定められています。

１．平日以外は２０００円
２．平日は１６００円
３．１８歳未満は１４００円
４．優待券を持参している人は１８００円
５．優待券を持参している１８歳未満は１２００円
６．複数の条件に一致する場合は安い料金を適用する

この博覧会の入場料を決定するデシジョンテーブルを作成することにします。

仕様から料金ごとのルールは次の通りとなります。

(1) ２０００円
　平日でなくかつ１８歳以上でかつ優待券を持参していない。
(2) １８００円
　平日でなくかつ１８歳以上でかつ優待券を持参している。
(3) １６００円
　平日でかつ１８歳以上。
(4) １４００円
　１８歳未満でかつ優待券を持参していない。
(5) １２００円
　１８歳未満でかつ優待券を持参している。

このルールをもとにして直接次のデシジョンテーブルが作成できます。

このデシジョンテーブルは結果に影響を与えない部分にはDon't Careを意味する「－」が記入されています。作成したデシジョンテーブルは圧縮されているので、これを圧縮していないデシジョンテーブルに変更します。やり方は「－」の部分にYesとNoを割り当て表を拡張します。そうすると次の圧縮されていないデシジョンテーブルが得られます。

デシジョンテーブルの作成方法として教科書的なやり方は、最初にすべての組み合わせを作成し（今回の場合は２の３乗で８通り）、各組合せごとに結果を記入し、最後に結果に影響を与えない複数の組み合わせを1つにまとめて圧縮する方法というです。こうした方法では表を圧縮する際に間違いが起こりやすこと、また条件が多いと組み合わせが膨大となってしまうという欠点があり、お勧めできません。

これで圧縮したデシジョンテーブルと圧縮していないデシジョンテーブルの２つが得られました。

ここでこの仕様をソフトウェアとして実装する場合を考えてみましょう。この仕様の実装方法は１つとは限りません。少なくとも４種類はあります。ここではこの仕様の実装例として次の３つのフローチャートを示します。

これらのソフトウェアのうち、最初のソフトウェアが判定文が最も少なく「合理的」なソフトウェアであるといえます。ですがプログラマが必ず「合理的なプログラミング」を行なうという保証はまったくありません。今回は、圧縮したデシジョンテーブルの条件が、１８歳未満、平日、優待券という順番に並んでいるので、このデシジョンテーブルをもとにプログラミングする人のほとんどは最初のフローチャートのプログラミングをするだろうということは言えます。しかし、デシジョンテーブルを作らずにプログラミングに取り掛かる人のほうがはるかに多いと思います。そういう人の中で、２番目や３番目のソフトウェアでプログラミングする人が出る可能性は否定できません。

これらのソフトウェアを表１の圧縮したデシジョンテーブルでテストすると、最初のソフトウェアではテスト漏れは起こりません。５つのルールでソフトウェアのすべてのルートを網羅しているからです。しかし、真ん中と最後のソフトウェアではテスト漏れが起きます。圧縮したデシジョンテーブルではルールが５つしかないのに、真ん中のソフトウェアでは６つ、最後のソフトウェアでは７つのルートがあり、網羅されないルートが出てくるからです。一方、圧縮していないデシジョンテーブルではどのソフトウェアでもテスト漏れは起きず、すべてのルートが網羅されます。

デシジョンテーブルを使ってテストを行なう場合、ブラックボックステストにおけるテスト対象のソフトウェアがどのように実装されているかを事前に把握することはできません。したがってデシジョンテーブルを圧縮してテストを行なうということは、常にテスト漏れの危険がつきまとうということを肝に銘じておく必要があります。

テスト技法を解説した書籍やネット上の解説では、そのほとんどがデシジョンテーブルを圧縮することが当然のように書かれています。デシジョンテーブルを圧縮することがいかに危険なことであるか。このことは強調してもしすぎるということはありません。

ごく一部の書籍やネット上の解説ですが、デシジョンテーブルの圧縮では「処理順が重要なので開発側との協力が必要」などと書かれているものがあります。おそらく言いたいのは「デシジョンテーブルを圧縮する場合は、テスト対象のソフトウェアのプログラム構造に合わせてテスト漏れが起きないような形で圧縮しなければならない」ということだろうと思われます。そもそもデシジョンテーブルテストはブラックボックスのテスト技法だったはずです。それなのにこれでは圧縮したデシジョンテーブルでのテストは制御パステストと同様なホワイトボックスのテスト技法ということになります。