![見出し画像](https://assets.st-note.com/production/uploads/images/112765528/rectangle_large_type_2_8aa5f7262f07dfd73cbb1e3b990b577e.jpeg?width=1200)
補遺・デシジョンテーブルとデシジョンテーブルテスト (T3:Pt2:Ch01)
「デシジョンテーブルとデシジョンテーブルテスト (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化の過程ではこんな記述があります。
日本国内での決定表の記述法は多様で様々の意見があった
ダイアグラムに限らず、あるアイデアが流通・浸透の過程で組織や個人の考え方や好みに合わせて“カスタマイズ”されていくのはよくあることだと思いますが、デシジョンテーブルも、誕生から30年足らずで(少なくとも日本の地では)多様な表記法が生まれていたらしいことが窺えます。
そういう「歴史」も踏まえて、実際の運用では、組織や個人の考え方、傾向、好みなどに合わせた表記や読み書き解釈のルールに従うのでよいと思っています。
(ただし、勉強するなら、記述・解釈の方法が定まっている「標準デシジョンテーブル」参照するのがよいでしょう。少なくとも「標準化された読み方・書き方」を知っておくのは悪いことではありません)
寄り道:デシジョンツリー
デシジョンツリーとデシジョンテーブル
『ソフトウェア構造化技法』で、デシジョンテーブルと同等の記述力/表現力を持つデシジョンツリー というダイアグラムも紹介されています。こちらを(も)知っているという人は多いのではないでしょうか。
(同書では両者を「17. デシジョンツリーとデシジョンテーブル」というひとつの章で扱っており、デシジョンツリーを先に紹介しています)
デシジョンツリーでは、ツリーのノードごとに条件を評価し、値によって枝分かれするツリーを構築します。末端のノード(葉)には、最終的に起こり得る結果(動作、出力、etc.)を書きます。
![](https://assets.st-note.com/img/1691145294419-1ZQ9Wyl7jA.jpg)
記述力/表現力はデシジョンテーブルと同等なんですが、異なる点もあり、ツリーのルートから枝を辿っていくために条件の評価順序が定まっています(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)
この記事が気に入ったらサポートをしてみませんか?