デシジョンテーブルテストというテスト技法ついて、特に簡単化について今回は書こうと思います。

デシジョンテーブルはロジックを表現するための記法

デシジョンテーブルは、テスト技法というより、ロジックを表現するときに使える記法と言った方が正しいかもしれません。1968年に出版された"An introduction to decision logic tables（日本で翻訳版「デシジョンテーブル入門」として1970年に出版）"という本の最初に以下のようなことが書かれています。

これまで長い間、コンピューターで処理すべき問題の論理的構造を表すには、フローチャートや文章による説明が用いられてきた。これは、簡単な一本筋の問題には極めて良い方法である。しかし、いろいろな条件が複雑に入り組んでくると、全ての可能な組み合わせを一つも落とさないようにするのは難しくなる。実際、今日コンピューターユーザーが直面している最も重大な問題の一つはプログラムのドキュメンテーションが適切に行われていないことである、フローチャートや文章を使う方法では、ちょっと複雑な問題にぶつかると「どろ沼」に落ち込んでしまう。フローチャートを書くとき、プログラマーは自分の思う通りにそれを詳細にもまた単純にすることもできる。出来上がったフローチャートはプログラマーの論理的思考能力や分析能力を反映している。したがって、それは必ずしも完全かつ明快なものになるとは限らない。しかしデシジョンテーブルはフローチャートとは違って、プログラマーに完全さと簡潔さを要求するする。デシジョンテーブルを正しく使えば全ての条件の可能な組み合わせを完全に網羅し、一方不要なあるいは余計な判定を削除することができる。（デシジョンテーブル入門 P2より引用）

この本は1968年出版なので、今から50年以上も前、なんと、私が生まれる前に書かれた本なのですが、その頃は「フローチャートよりも簡潔に完全にロジックを表せる記法」としてプログラマー向けに紹介されています。そしてこの文章の最後の部分である...

デシジョンテーブルを正しく使えば全ての条件の可能な組み合わせを完全に網羅し、

ってところから「テストにも有効だ！」となったのだと推測します。

デシジョンテーブルの書き方

これは最近のISTQBのFLシラバスがとても丁寧に書かれてて、そっちをみてもらうのが一番早いと思います。

デシジョンテーブルの具体例

2005年くらいに、私が日経ソフトウエアにテストの連載を執筆したときに使った例題で説明してみます。

デシジョンテーブルのお題

「年齢が6歳以上18歳以下，現住所が埼玉県，学生証の提示ありの場合に，チケット代金を学割金額とする」

この記述には，たくさんの組み合わせ条件のうちの正常になる一つのパターンしか書かれていません。そこで，デシジョン・テーブルを使って全パターンを洗い出します。デシジョン・テーブルとは，図7[拡大表示]のように条件と動作の関係を表形式で表現したものです。このケースでは，年齢や住所の条件をT(真：True)とF(偽：False)で判断することで，8個のパターンがあることがわかります。

図7は以下になりますね。

上記の図にも書いてありますが、本当にこれで良いのか？と考えるところが実践では必要です。これではNGなんです。実践でデシジョンテーブルをちゃんと書くのに必要なのは条件の洗い出しをちゃんとするスキルです。

条件の全体像の把握と同値分割の粒度の設計

デシジョンテーブルを作る際は、条件を洗い出す必要がありますが、その際、条件の全体像の把握（つまり、テスト分析ですね）と同値分割の粒度の設計が必要になります。上記の例だと条件が3つあります。それら3つは実は条件の全体像に対して同値分割しています。

例えば、現住所という条件に対して、

　　埼玉在住＝ {T,F}

と同値分割をしています。現住所を都道府県の単位で分割すると47になりますが、47の場合を全部テストする必要はなく、埼玉県かそれ以外というように同値分割して全体を捉えているわけです。

もう一つ見てみましょう。年齢の条件を例にして考えてみるために、もう一度日経ソフトウエアの引用をします。

ただ，ここでよ～く考えてみてください。図7には落とし穴があります。わかりますか？ それは，年齢が6歳以上18歳以下という条件だけで年齢を判断してしまっている点です。これでは，0歳から6歳の人と，19歳以上の人の金額はFalseということで同じチケット代金ということになってしまいます。それはどう考えてもおかしいですよね。つまり，これは“仕様の確定漏れ”なのです。こういう場合は勝手に判断せず，正しい仕様はどういうことなのかを確認し直すようにしなければなりません。そこで作り直したのが図8[拡大表示]のデシジョン・テーブルです。

ここでは文字数の都合で、「どう考えてもおかしい」の一言で終わらせていますが（笑）、割引でない場合＝通常料金、となるだろうと推測した際に、19歳以上が通常料金なのは納得いきますが、0歳の赤ちゃんに通常料金をもらうようにしている映画館というのが、私たちの経験から考えてありえないと思うわけです。もっと言うと老人も通常料金なのかな？って考えるのがよいです。こういうふうに経験から判断できる場合は、経験をフル活用します。ただ、経験からわからない場合もあります。例えば、法人税申告書の計算での同値分割とか、経験ではなかなかわかりませんので、疑問を投げかけるのがよいです。どっちにしろ、仕様が曖昧になっているところはどんどん明確にしていくのが良いデシジョンテーブルを作るコツです。どんどん明確にしたい、知りたいという好奇心をもつことがテストエンジニアとして、よいテストケースを作れる素養になるのだと思います。

デシジョンテーブルの簡単化(collapse decision table)

いよいよ、本題です。前述したデシジョンテーブル入門の引用で以下の記述があります。

一方不要なあるいは余計な判定を削除することができる。

これがここで話したい簡単化のことになります。

デシジョンテーブルは、次の列を削除することで縮小することができます。

● 不可能な条件の組み合わせを含む列
●可能ではあるが現実的ではない条件の組み合わせを含む列
● 結果に影響しない条件の組み合わせをテストする列

　デシジョンテーブルを縮小させることを、「デシジョンテーブルの簡単化(collapse decision table)」と呼びます。実践の場では、簡単化を使いこなさないとデシジョンテーブルがすぐに膨大な表になりますので必須の技術といえるでしょう。

デシジョンテーブルの列に不可能な条件の組み合わせを含む列、および可能ではあるが現実的ではない条件の組み合わせを含む列がある場合、該当する列を削除します。

不可能な条件の組み合わせがでてしまうケースとしては、洗い出した条件が「or」でしか組み合わさることがありえない場合です。日経ソフトウエアの題材で説明します。

年齢＝{0歳以上5歳以下,6歳以上18歳, 19歳以上}

というように一つの条件に対して3つの値がとりうることができると書いていますが、この条件は以下のように記すこともできます。

年齢_0歳以上5歳以下＝{T,F}
年齢_6歳以上18歳以下＝{T,F}
年齢_19歳以上＝{T,F}

このままデシジョンテーブルを書くと以下のようになることがあります。

年齢が5歳以下でかつ7歳から18歳の間でかつ19歳以上である人っていうのは存在しえません。なので、このデシジョンテーブルのTC1とTC2は、不可能な条件の組み合わせです。

可能であるが現実的でないものとしては、以下のようなものになります。

5歳以下の子供が学生証を持つということは、日本では現実的ではありません。ただし、組み合わせとしては可能ですし、日本ではない国では学生証を持っていて、日本に遊びにきてた人が自分の国の学生証を見せてくる可能性も否定できません。この場合は、念のためちゃんとチーム内で認識を合わせた上で削除するのが正しいです。

また、結果に影響しない条件の組み合わせをテストする列の場合ですが、結果に影響しない条件の部分は、条件の選択肢のどちらでもよいわけです。そんな場合は、その列に入れる選択肢ではなく、「－」または「N/A」で表すようにします。結果的に同じ条結果的に同じ条件の組み合わせとなる列が複数現れます。この場合、1列だけ残して、他の同じ条件の組み合わせとなった列を削除します。これも日経ソフトウエアの題材で説明します。

例えば、上記のNo2,3,4の場合で、結果の判定に影響していないところを「-」にしてみると以下のようになります

No2とNo3、No3とNo4は、同じF(False)の条件で結果が通常金額になるわけです。この場合、両方から見て一つはテストケースとしてなくても構わないとなります。

結果を導く条件が複数ある列はテストに不向き

ここで、「だったらNo3だけテストすれば効率的じゃないか？」と思うこともあるかもしれません。ただし、それはテスト技法的に御法度です。なぜなら、No3でテストしてしまった場合、結果は通常料金になったとしてもそれが埼玉在住ではないからそう判定されたのか、学生証を持っていないからそう判定されたかまでわかりません。どちらかで判定されていることはテストしたことになりますが、どちらかはテストしていないままになってしまうのです。なので、結果を導くキーになる条件は独立させて確認しないといけないというテストとして重要なルールがあります。なのでNo2とNo4が適切だと言えるわけです。

最後に

ということでデシジョンテーブルの簡単化だけでなく、全般的に説明をしてしまいました。簡単化はデシジョンテーブルテストの際にテスト数を現実的にするために必須の技術です。ただし、テスト技術者としては、できるかぎり、一度全体像を書いてから縮小するのが良いと思っています。簡単化する際に想定だけで考えて実は必要な組み合わせを漏らしてしまう可能性もあるからです。

時間があれば演習問題を何問か作ってnoteで公開するのもありかなと思ってきたので、時間を見つけてやってみるかもしれません。期待するよーという方は「👍イイね」してください！

補足

辰巳さんがデシジョンテーブルの歴史についてまとめてくれているご本人のブログを紹介してくれたので貼り付けておきます。是非ご一読を！