見出し画像

補遺・デシジョンテーブルとデシジョンテーブルテスト (T3:Pt2:Ch01)

mottie (nob_mottie)

「デシジョンテーブルとデシジョンテーブルテスト (T3:Pt2:Ch01)」の付記、寄り道的話題など。


付記：標準と“多様な表記”

多様な“デシジョンテーブル”

本編では“JIS式デシジョンテーブル”を下敷きにして書き方などを説明しましたが、筆者は「“JIS式”でなければダメ」とは思っていません。根幹部分の理解が変わらず、誰もが同じように読み書き解釈できるなら、組織や個人の「ローカル式」で構わないと思っています（筆者も"T"/"F"式の表記が好みですし。まぁ「Y/N以外の二値表現も可」とされていますが）。

実際、開発の現場やテストの現場で、「名前は同じデシジョンテーブルだけど、細部とかいろいろ異なっているバリエーション(変異形)」を見ることがあります。独自に考えた表にデシジョンテーブルと名前をつけているのを見たこともあります。
それは歴史を振り返っても言えることのようです。

標準化の歩みと“多様な表記”

参考文献に挙げている辰巳敬三氏のブログによれば：

デシジョンテーブルは1958年頃にGE(General Electric)社やSutherland社で考案されました。

『デシジョンテーブルテストの歴史』

とあります。
JIS X 0125:1986の解説を見ると、それから20年弱を経て、ISO化が始まったようです。

  • 1975年: 標準化作業開始

  • 1984年: DIS(国際規格草案)承認　→ISO 5806制定

  • 同年: JIS原案作成開始

  • 1985年: JIS原案承認

JIS化の過程ではこんな記述があります。

日本国内での決定表の記述法は多様で様々の意見があった

JIS X 0125:1986

ダイアグラムに限らず、あるアイデアが流通・浸透の過程で組織や個人の考え方や好みに合わせて“カスタマイズ”されていくのはよくあることだと思いますが、デシジョンテーブルも、誕生から30年足らずで（少なくとも日本の地では）多様な表記法が生まれていたらしいことが窺えます。

そういう「歴史」も踏まえて、実際の運用では、組織や個人の考え方、傾向、好みなどに合わせた表記や読み書き解釈のルールに従うのでよいと思っています。

（ただし、勉強するなら、記述・解釈の方法が定まっている「標準デシジョンテーブル」参照するのがよいでしょう。少なくとも「標準化された読み方・書き方」を知っておくのは悪いことではありません）

寄り道：デシジョンツリー

デシジョンツリーとデシジョンテーブル

『ソフトウェア構造化技法』で、デシジョンテーブルと同等の記述力/表現力を持つデシジョンツリー というダイアグラムも紹介されています。こちらを(も)知っているという人は多いのではないでしょうか。
（同書では両者を「17. デシジョンツリーとデシジョンテーブル」というひとつの章で扱っており、デシジョンツリーを先に紹介しています）

デシジョンツリーでは、ツリーのノードごとに条件を評価し、値によって枝分かれするツリーを構築します。末端のノード(葉)には、最終的に起こり得る結果(動作、出力、etc.)を書きます。

Fig.01 デシジョンツリーの例

記述力/表現力はデシジョンテーブルと同等なんですが、異なる点もあり、ツリーのルートから枝を辿っていくために条件の評価順序が定まっています（JIS X 0125の「行順序方式」(箇条6.1)に相当するが、JISではもうひとつ評価方式が挙げられ、「いずれの方式を用いるかは、規定しない」としている）。
また、条件の数、条件の取る値の数が多いと、ツリーが大きく長くなり、見通しが悪くなります（デシジョンテーブルでも、表が大きくなりますが）。書くのも大変です。
前掲書では次のように評価しています。

条件の数が少ない場合、デシジョン・ツリーの方が読みやすい。
条件や行動の数がかなりのものになると、デシジョン・ツリーは大きくなりすぎて扱えなくなる。
(p.229）

『ソフトウェア構造化技法―ダイアグラム法による』

“デシジョンツリーテスト”はないのか？

ごめんなさい、ISTQBやISO/IEC/IEEE 29119で取り上げられていないだけで、あるのかも知れません。が、2023年時点まで“国際標準”に採用されるほどにメジャーではないのは確か、と言っていいでしょう。
本稿を書いていてふと疑問に思っただけで、筆者としても答はないのですが、ひとつには（やはり）ツリーを描く手間がかかる、それならデシジョンテーブルで表す方が書きやすいし編集もしやすい（条件を付加する、動作を付加するなど）、というダイアグラムの性質が影響しているのかなと思います。ツリー/グラフを使う別のテスト技法である原因結果グラフにしても、クラシフィケーションツリーにしても、作成を支援するツールなしに手書きで使うのは骨が折れます。
デシジョンツリーを使ってテストを設計することが全くないとは思いませんし、技法として使っているという人もいるかも知れません。使用例があれば、それを参考にする人も現れて、広まっていくかも知れません。
（【補足】原因結果グラフはISO/IEC/IEEE 29119-4に記載が、クラシフィケーションツリーはISTQB-ALTA、ISO/IEC/IEEE 29119-4に記載があります）

参考文献

  • JIS X 0125:1986 決定表 / 日本工業標準調査会(審議) / 日本規格協会

    • 日本工業標準調査会は、2019年に日本産業標準調査会と改称

  • ソフトウェア構造化技法―ダイアグラム法による / J.マーチン, C.マックルーア (訳：国友 義久, 渡辺 純一) / 近代科学社

  • デシジョンテーブルテストの歴史 / 辰巳敬三 / http://a-lifelong-tester.cocolog-nifty.com/blog/2011/10/post-398b.html

(2023-08-02 R001)

この記事が気に入ったらサポートをしてみませんか？