ついでに、ディシジョンテーブルの圧縮なり最適化も少し考えてみた。ある意味、簡易版。もとの題材は「デシジョン・テーブルを活用する」。”表を圧縮する”以降の部分。
http://homepage3.nifty.com/kaku-chan/q_and_p/decision_table.html
題材での表をGoogle Spreadにしたものが、以下。
操作などをしやすくするために、行/列を入れ替えたのが以下。
Google Spreadでもフィルタ機能を使うことでフィルタリングできるが、上のようなWeb共有ではできない。(ちょっと残念というか、わかりにくいけど。興味あれば、自分のSpreadやエクセルで試してもらえれば幸い。)
行/列を入れ替えた方が、テストする際のチェックシートと親和性があって分かりやすいと思う。規格と異なるので、文句言う人はいるだろうけど。 あと、入れ替えて、しかもテストケースを右の方に書いているケースもネットで結構目にする。個人的には、テストの視点ではその方が良いと感じる。
基本的なチェックとしては以下の項目だろうか。
・条件指定に、Y/Nがあるなど条件に矛盾するものがない。
これは行列入れ替えだと、各列での縦方向のチェック。
・動作指定部に、Xがないものはない。
こちらも行列入れ替えだと、各列での縦方向のチェック。
あとは、動作が同じものをまとめる事になるが、このためにフィルタリング機能は有益だろう。また条件指定部をソートすることも、漏れがないかのチェックには有益と考える。
「あたため」ボタンと「ふっくらパン」ボタンが排他的なことに気付くかは、その人によるかな~。この辺りとかロジックの矛盾を自動検出するのは、少し面倒だろう。逆に、(高信頼性の機器開発などでは)以前述べたツール類で行う方が不安感はないように思える。ただし、あくまでディシジョンテーブルベースで行う場合。
ちなみに例えばこの表で、”ユーザ指定時間”とあるのは時間の設定が伴う。ソフトウェアテストの感覚では、最小時間や最大時間をテストケースに含めたいだろう。この辺りが、設計寄りのディシジョンテーブルとテスト側でのでディシジョンテーブルを分けた方がよい(事が多い)ケースの代表と考える。設計寄りのテーブルでは、特に最適化を行えば、最小限のテストケースになりやすい。
また、ディシジョンテーブルの規格では、条件と動作については、記述は表に記載されている順番とするとなっている。テストケース6や12は、トースト動作の後にレンジ動作が行われることになる。この辺りが、真理値表と考え方が違うところだし、ディシジョンテーブルの表内での圧縮や最適を機械的に行うネックなのかもしれない。(あるいは、順序が関係することを明示的に示す、他の表記が良さそうに思える原因かもしれない。)
状態遷移表によるアプローチなども実験してみるけど、しばらく先になりそう。