デシジョンテーブルについて

TDD という言葉があるようにテストが最近の開発では必須なぐらいの状況になっていると思いますが、テストってどんなことを考えなければならないでしょうか

ある関数のテスト（単体テスト）とか、結合テストなどの比較的下流においてコーディング後にするテストを思い浮かべる方もいらっしゃると思いますが、コーディング前にアプリやシステムの動作を前もって洗い出せると不要な後戻りを防げますよね

そんな時に使えるソフトウェアテスト手法としてデシジョンテーブルというものがあります

デシジョンテストはソフトウェアテストにおいてソフトウェアの動作の一覧を表にしたものです

デシジョンテーブルの作り方

以下のような、EC サイトの商品の値段設定があるとします

• ある商品を 2 つ以上まとめて買うと 10%OFF します
• 2 つ以上の異なる商品まとめて買うと 5%OFF します
• 料金の OFF が重複した場合は高い値引率の方を優先します

このような場合、デシジョンテーブルはこのようになります

ルール 3 の場合、ある特定の商品を複数個買った場合ですね。この場合はある商品を 2 つ以上まとめて買うと 10%OFF しますに当てはまるため 10%OFF となります

デシジョンテーブルのかなりシンプルなパターンですが、何と無くイメージついたでしょうか

デシジョンテーブルは 条件、 アクション の 2 つの要素から作られます ルールは条件の数の二乗分の数になります

上記の例では条件の数は 2 だったので、22 = 4 でルール 4 まで設定されます

もう一つ増えると 23 = 8 になり、さらにもう一つ増えると 24 = 16 になります

矛盾している条件は削除する

実は先ほどのデシジョンテーブルには矛盾が存在しています

お気づきでしょうか。

ルール 2 の条件とアクションに着目してみましょう

2 種類以上まとめ買いをしていますが、2 つ以上まとめ買いしているわけではないというルールになっていますね

ちょっと待ってください？おかしくないですか？

そもそも、2 種類以上まとめ買いしている時点で 2 つ以上まとめ買いしていることは確定していませんか？

にも関わらず、2 つ以上まとめ買いしているわけではない。というルールになっています

つまりこのようなルールはありえないわけです

結果的に、今回の場合は 1 つ分のルールを削減でき、3 つのルールによるケースが考えられることになります

ここで、もう一度デシジョンテーブルを見直してみましょう

あれ？おかしいですね。

5%割引になることなくないですか？

どうやら、今回の割引ルールには 5%割引というもの自体がおかしいことが発見でき、

コードを書かずして、無駄なルールを減らし、矛盾するケースを減らすことができました

まとめ

• 条件とアクションからソフトウェアの動作の一覧を表示するデシジョンテーブルを学びました
• 動作の一覧を作ったことでルールを整理できました（今回はシンプルでしたが、複雑な条件になるとよりこの有り難みが伝わることでしょう）
• コードを書かずして細かな仕様に気付き、矛盾を前もってなくすことができました

デシジョンテーブルはあくまでもソフトウェア動作の一覧を作ることで複雑なルールを整理することが目的ですが、ソフトウェアテスト以外でも条件とアクションを上げさえすれば複雑なことを単純にすることができるので、ぜひ日常の一部にデシジョンテーブルを挟んでみてください

参考

【この 1 冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践