ソフトウェアの品質を学びまくる

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

わたしの好きなデシジョンテーブル表現方法を説明するにもほどがある

これは、ソフトウェアテストの小ネタ Advent Calendar 2024、10日目の記事として出す。
出すが・・今回まだその時と場所の指定まではしていない。どうかそのことを諸君らも思い出していただきたい。つまり・・我々がその気になれば、記事の公開は5日・10日前ということも可能だろう・・ということ・・!

qiita.com

テスト設計においてもよく利用されるデシジョンテーブル
その記述方式は大きく分けて2つ、「制限指定」「拡張指定」があります。

この記事では、『ソフトウェアテスト技法練習帳』の問題を借りてこの2つの記法を紹介したうえで、わたし自身が気に入っている記法について説明したいと思います。

なおデシジョンテーブルは、JIS X 0125:1986 で規格化されています。ただ正直そこまで厳密な定義に興味がないため、じっくり読んではおりません。よって「制限指定」「拡張指定」の説明はかもしれません! 先に逃げを打っておきます。

これはエグゼクティブサマリーです。

エグゼクティブサマリー

フッターにWACATE2024冬と書いてあるのは、WACATE2024冬の発表資料作成中に生まれ出てきたスライドだからです。
たぶんこの話は寄り道になり過ぎるので、Twitterとこの記事で放流してしてしまいます。WACATEで会うみなさん、その旨ご了承ください。

今回使う仕様

『練習帳』の問題2.5では、「カレンダーの日付を色分けする」という動作について、デシジョンテーブルを書きます。その仕様は、ざっくり以下のようなものです。

祝日は赤
日曜日は赤
祝日でない土曜日は青
祝日でない平日は黒

これをどう条件として切り分けるかは好みがあるかと思いますが、『練習帳』における解答にしたがって、「祝日かどうか」「何曜日か」を組み合わせることにします。

デシジョンテーブルの記述方式

1. 制限指定

先にデシジョンテーブルをお見せすると、こうなります。

制限指定

この後の話のために用語を説明しておきましょう。

デシジョンテーブルの4つのエリア

デシジョンテーブルの左上が「条件記述部」
一番上の行には「祝日」とだけ書いてありますが、もう少し丁寧に書くなら「祝日である」という命題です。

右上が「条件指定部」。「祝日である」という命題に対し、真偽値を書いています。

左下は「動作記述部」
こちらも一番上の行は「赤である」という命題と捉え、右下の「動作指定部」に「X」が書かれていれば「真である」を意味します。

このように制限指定では、左側つまり記述部が、2値の命題になっている点が特徴です。

デシジョンテーブルは横長の表になりがちですが、制限指定であれば指定部が1文字で済むので、表がコンパクトになります。一方で、記述部は真偽値を取る命題に「開く」必要があるため、縦長になりがちです。

そして一番の問題は、「祝日」という命題と、「土曜日」「日曜日」「平日」という命題が、別のパラメターの値であることがわかりづらいという点です。
この表をパッと見た人は、なぜ「祝日」が「TTTFFF」で並び、「土曜日」「日曜日」「平日」に順番に「T」が現れるのか、わからないでしょう。可レビュー性が低いです。

2. 拡張指定

デシジョンテーブルはこのような形になります。

拡張指定

特徴は、指定部に真偽値ではなく、具体的な「値」が入っていることです。これによって、パラメターは「祝日」と「曜日」の2つであり、それぞれ「祝日」「非祝日」、「土曜日」「日曜日」「平日」という値を取るのだということが、制限指定よりはわかりやすくなります。

また、個々の列(ルール)をチェックするとき、たとえば#1を上から順に見ていくと、「祝日で土曜日なら赤」ということが一目でわかるのも嬉しい。これは制限指定にはなかった長所です。ただ個人的には、#1~#6で正しく値を割り当てられているかがイマイチわかりづらいなと感じます。

スペースの使い方としては制限指定と真逆になり、縦はコンパクトになりやすく、横が広がりやすい。

3. わたしの好きな形式

こんな形式です。

鈴木の好きな形式

別にわたしオリジナルというつもりは全然ないのですが、明示的な名前がついていないような気がします。
ともあれ、特徴は2点あります。

(1)記述部には、パラメターと値を、列を分けて書く。

ある意味、制限指定と拡張指定のハイブリッドと言えるかもしれません。
こうすることで嬉しいのは、条件と動作それぞれにどのようなパラメターがあり、各パラメターがどのような値を取るかが明らかである点です。
よって、以下の観点でのレビューが楽になります。

  • 条件部のパラメターは十分か、他に動作に影響するパラメターはないか
  • 動作部で確認すべき項目は十分か
  • 条件部のパラメターと動作部の項目は、適切に同値分割されているか

これらは、どう丸つけするか、テーブルを圧縮するかといった話以前の、「そもそも検討していることが正しいか」の確認であり、きわめて重要です。
また同じ理由で、パラメターや値を追加する際にもその変化が見てとりやすいでしょう。拡張性に優れているともいえます。

(2)指定部は、該当する箇所だけにマークする。

これはある意味冗長であり、スペースの無駄遣い。縦に伸びやすい制限指定の特徴を引き継いでいます。
しかしそのおかげで、丸付けのパターンがとても明瞭であることも見て取れると思います。これは制限指定にも拡張指定にもない長所と言えます。

ただし1点、重大な欠点があります。この形式をスプレッドシートで表現しようとすると、パラメター列で「セル結合」に走りがちだということです。
セル結合の弊害は計り知れません。セル結合だけはしないでください。

結論

自分の好きな形式で書いてください