見出し画像

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

もづきち(mottie)

デシジョンテーブル(決定表)

デシジョンテーブルとは、次のような表(テーブル)です。例では「洗濯物がたまっているかどうか」と「降水確率」というふたつの条件によって、洗濯するかどうか、洗濯したものをどこに干すかが異なることを、表の形で表しています。

Fig.01 デシジョンテーブルの例

簡単に言うと、

  • 複数の条件が関係し、

  • 個々の条件の取る値の組み合わせによって、

  • 異なる複数の結果（出力、動作、etc.）が導かれる、

そのような仕様に対して、条件(の取る値)の組合せと結果（出力、動作）との関係を表(テーブル)の形で記述するものです。

……なんですが、“あんがい、知られていない”のではないかという思いがあります。ソフトウェア設計者時代の周囲の様子と、テスト技法のトレーニングに参加する人の反応からそう思っているだけですが。
ISTQB のシラバスで取り上げられているので、この名を知っている人は昔に比べれば相当増えたと思われます（主にテスト技術者方面で、かも知れませんが）。が、デシジョンテーブルの書き方・読み方を知っている人、活用している人はどれほどいるでしょうか……？

いいツールでも、どんなものか知らなければないのと同じでしょうし、どんなものか知っていても使い方を知らなければ使おうと思えないでしょう。
本稿では、デシジョンテーブルを{知りたい / 興味がある / 使ってみたいのだけどよく知らなくて……}という人のために、デシジョンテーブルの紹介、書き方とヒント、テストへの適用のヒントなどを綴ります。テスト技術者向けを想定していますが、ソフトウェアテストに限定した内容にはなっていません。

紹介に当たっては、JIS X 0125:1986 『決定表』を用います（いま規格票を見ると、対応国際規格はISO 5806となっています）。デシジョンテーブルを既に知っている人には「知ってる」「直感的にそう理解していた」と思うことも多いかも知れませんが、JISの“お墨付き”が得られるのはメリットがあるかと思います。

JIS式デシジョンテーブルの構成要素と記述・解釈の方法

JIS X 0125:1986（以降、単に「規格票」とも呼びます）で定義されているのは、「単適合決定表(single-hit decision table)」と呼ばれる、「条件の組合せのどのひとつを取っても、規則中に1回だけ取り上げられる」デシジョンテーブルです。なお規格票では「決定表」という語を用いていますが、本稿では「デシジョンテーブル」としています。
以下の文中、「箇条X.Y」などと記した箇所は、規格票の該当箇条を指します。

構成要素

デシジョンテーブルは大きく上下ふたつの部分に分かれ、“上側”を条件部、“下側”を動作部といいます。大きく左右ふたつにも分かれ、“左側”を記述部、“右側”を指定部といいます。(箇条3.1)
（規格票ではテーブル最上部に「表見出し部」がありますが、本稿では割愛します）

Fig.02 デシジョンテーブルの構成要素

  • 条件部　……条件記述部と条件指定部から成る

  • 動作部　……動作記述部と動作指定部から成る

    • （動作部を、FLシラバス日本語版2018V3.1.J02では「アクション」と呼んでいる）

  • 規則　……条件指定部・動作指定部の列。各列(規則)には、各条件の取る値を記入し(条件指定部)、その組み合わせの結果取られる動作(実行される処理、生じる結果、得られる出力、etc.)を記入する(動作指定部)。「これらの条件がすべてこの列の値である場合、この動作を実行する」ことを表す

（本稿で提示するデシジョンテーブルは、規則の上部に番号を振っていますが、これはJISの規定ではありません（「つけてもよい」とは言っている））
（【つぶやき】筆者は「動作部は、行動部、結果部とも呼ばれる」と憶えてしまっていますが、なんでそんな風に憶えたんだろう……(´・ω・｀)）
（【つぶやき】FLシラバス日本語版で「アクション」としているのは、シラバス原文でaction(s)となっているのを受けたものと思われ、これはISO 5806で動作部を"action"と呼んでいるのを受けたものと思われます）

制限指定と拡張指定

条件部、動作部の書き方には 制限指定 と 拡張指定 の2種類があります(箇条2.(14), (15), (16)。また箇条3.2, 箇条3.3)。

  • 制限指定：　条件や動作が、記述部に書かれていることだけで完成している書き方。

    • 条件記述部には、「入力Aの値が10以上」といった、二値(真偽)で表せる条件を書く。条件指定部の各列(規則)には、その条件を満たす場合＝"Y"、満たさない場合＝"N"、を記入する。

    • 動作記述部には、「エラーメッセージE01を出力」といった具体的な動作(出力、結果、etc.)を書く。動作指定部の各列(規則)には、当該動作が引き起こされる場合＝"X"、引き起こされない場合＝"-"、を記入する。

  • 拡張指定：　条件や動作が、記述部に書かれていることだけでは完成しておらず、指定部の記入内容と併せて完成する書き方。

    • 条件記述部には、「入力A」「参加者人数」といった形で書く。条件指定部の各列(規則)には、その条件の取る具体的な値や、値の範囲などを記入する。

    • 動作記述部には、「エラーメッセージを出力」といった形で書く。動作指定部の各列(規則)には、動作記述部を補う具体的な動作や識別子などの語句を記入する。当該動作が引き起こされない場合＝、"-"を記入する(制限指定と同じ)。

制限指定だけからなるデシジョンテーブルを 制限指定表 といい、拡張指定だけからなるデシジョンテーブルを 拡張指定表 といいます。両者が適宜混在したデシジョンテーブルを書くこともでき、これを 混合指定表 といいます。本稿で提示するサンプルはすべて制限指定表です。

条件部の記述と解釈

  • 条件記述部には着目している仕様に関係する条件を書き出す（後述「デシジョンテーブルの書き方」参照）。

  • 条件指定部には、列(規則)にひとつずつ、その条件の取り得る値を書き出す。

  • 条件指定部の列(規則)全体で、各条件の取る値の組み合わせを表すようにする。

    • たとえば、制限指定で、二値の条件A, Bがある場合、 A, B の取り得る値の組合せは 2 * 2 = 4通りなので、指定部は4列になる。この4通りで各条件の値の組合せを漏れなく書き出す

    • 条件指定部の各列(規則)は、各条件の取り得る値の組合せのひとつの場合を表す

  • 条件間の関係は、論理AND(箇条4.1)。すべての条件の取る値が規則を満たした時、当該規則の動作部が実行される

  • 条件の上下は、条件の評価の順序を表すものとは限らない。

    • （注。JIS規格票の原文は次のようになっています。「順番が意味を持たない場合には、読みやすくするために、重要な条件、すなわち、“キー”条件を最初に記述してもよく、その場合の順番は、プログラム作成に当たって選定する順番とは異なってもよい」(箇条4.1)）

  • 表の簡単化は本稿「簡単化」で説明しています。

（【注】Y/Nは「別の二値表現を用いてもよい」とされています）
（【つぶやき】筆者は T(True)/F(False)で表すのが真偽値らしくて好きでした。今でもその方が好きですが、ホワイトボードなどに手書きで書くと、字が下手なせいで "T" と "F" が紛らわしくなる……ので、人に教えるときは JIS準拠にするように改めました）

規格票箇条6では、デシジョンテーブルが満たすべき重要な性質として、完備性(completeness)を挙げています。「条件がとる値の組合せが網羅されており(漏れがなく)、重複がないこと」で、デシジョンテーブルの作成/チェック(レビュー)に当たっては注意すべき事項と言えます(箇条6.1)。

動作部の記述と解釈

  • 動作記述部には、当該仕様として取り得る動作(起こり得る結果、出力)を書き出す。

  • 動作部の上から下に向かって逐次実行するものとして、実行すべき順番に記述する(箇条4.2)。

（【筆者見解による補足】この記述・解釈の方法を忠実に守ると、「同じ動作(結果や出力)だが、条件の組合せによって実行の順序が異なる」ものがあった場合、異なる順序の分すべてを書くことになり、実際規格票では「そのように記述すること」としています。これは頻繁にあることではないかも知れませんが、いざ遭遇した場合はけっこう面倒な作業になります。JISから逸脱していると承知した上で、実行の順序は気にしなくてもよいのではないかと思います）

規則の解釈

  • すべての条件が規則中の条件指定を満たす場合に、当該規則が満たされ、動作指定部の動作が実行される。

  • 規則間の関係は、排他的論理和(XOR)(箇条4.3)。

    • 注：「同時にふたつ以上の規則が適用されることはない」ということです。

  • 規則の順番(列の並び)には意味はなく、評価の順序とは関係がない。

デシジョンテーブルの見方

以上の説明を基に、デシジョンテーブルの例を読んでみましょう。

Fig.03 デシジョンテーブルの例(再掲)

条件「洗濯ものがたまっている」も「降水確率が30%以下である」も二値の条件で、組合せ総数は2の2乗＝4通り。規則は組合せを網羅しています。各規則は：

  • 規則1: 洗濯ものがたまっている＝"N"（＝洗濯ものがたまっていない）で、降水確率が30%以下である＝"N"（＝降水確率が30%超）　⇒洗濯はしない（洗濯ものを干すこともない）

  • 規則2: 洗濯ものがたまっている＝"Y"で、降水確率が30%以下である＝"N"（＝降水確率が30%超）　⇒洗濯をする。洗濯したものを部屋に干す

  • 規則3: 洗濯ものがたまっている＝"N"（＝洗濯ものがたまっていない）で、降水確率が30%以下である＝"Y"　⇒洗濯はしない（洗濯ものを干すこともない）

  • 規則4: 洗濯ものがたまっている＝"Y"で、降水確率が30%以下である＝"Y"　⇒洗濯をする。洗濯したものを外に干す

条件、動作、規則が、基となった仕様に合致しているなら、デシジョンテーブルは完成です。

その他

JIS X 0125:1986のうち以下は本稿では割愛します。

  • 補完規則(ELSE-rule)(箇条2.(5)ほか)

    • うまく使えばテーブルの巨大化を抑えるのに貢献しそうなオプション

    • でもテストをする立場からは、あると考えるのが面倒そう

  • 複数のデシジョンテーブル間の関係と表し方(箇条5)

    • デシジョンテーブルの表現力を増強する、なかなか興味深い仕組み

    • 本稿「条件や条件の取る値の個数が多い時は」で、デシジョンテーブルの分離について紹介しています

規格票の内容全体がそうですが、特に箇条5は、参考文献『ソフトウェア構造化技法』『デシジョンテーブルの歴史』で言及されている、「コンピュータに処理させることを想定」している感が濃く漂っています。

デシジョンテーブルの使いみち

デシジョンテーブルはもともとソフトウェア設計を支援するツールとして開発されました。
他ならぬ筆者が“生き証人”で、筆者がデシジョンテーブルを知ったのはソフトウェア設計者時代、『ソフトウェア構造化技法』という書籍です。いま同書を読むと、次のように言っています（なお、ソフトウェアテストへの言及はありません……）。

……そういうわけで、これはシステム分析やシステム設計のツールとして利用されてきている。特に機能仕様における意思決定論理や、プログラム設計におけるプログラム制御構造を記述するのに使われている。……
デシジョン・テーブル(ツリー)は、プログラム制御論理を書き表せるばかりでなく、プログラム全体を書き表すことも可能である。……
（「17. デシジョン・ツリーとデシジョン・テーブル」）
分析者やプログラマなら誰でもこれに親しむべきである。
（「23. ダイアグラム作成技法の利用ガイド」）

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

また、同様のことは『デシジョンテーブルテストの歴史』でも言及されています。

出自がそういうものですから、「テストケースを設計する時にだけ使う」ものではありませんし、まして「テストケースを設計する時だけしか使えない」ものではありません。仕様の理解・明確化、仕様記述の整理・分析を支援するツールとして、ソフトウェア開発の初期段階、テスト分析の初期段階から利用価値の高いダイアグラムと言えます。
（本稿の主旨から外れて「ソフトウェア設計者ももっとデシジョンテーブルを使……うといいことあるかもよ！？」と言いたいところですが……）

テストベース(仕様書、操作説明書、外部設計書、etc.)の記述に対して……

  • 自分が理解するために（理解を明確化するために）

  • 条件が複雑で一読で判りづらいと感じた箇所を整理するために

  • ある仕様や機能に関連しそうな条件がテストベースに散在している場合、それらをまとめて整理するために、また仕様の記述と照合するために

デシジョンテーブルを書いてみる、という使い方が考えられます。

テスト担当者が仕様の理解や分析のついでにデシジョンテーブルを書くことは、「作成したデシジョンテーブルがテストの詳細な分析やテスト設計の入力として使える」という利点があります。そのためにも、デシジョンテーブルを書く際は以下に注意を払いましょう。

  1. 関係する条件と、その取り得る値を網羅する

  2. 条件の取り得る値の組合せを網羅する（制限指定だと、取り得る値は二値なので、網羅が比較的楽で確実）

  3. 取り得る動作(結果、出力、etc.)を網羅する

規格票の附属書1でも、「表の大きさを縮小する前に、条件指定の全組合せを列挙するのがよい」と言っています。条件の組合せを書き漏らす心配がないからです。

デシジョンテーブルの書き方

(慣れないうちは)制限指定で書く

デシジョンテーブルを習得中であるとか、使い始めて間もないとかならば、まずは制限指定に慣れることをお勧めします。制限指定では、条件は「満たす/満たさない」「成り立つ/成り立たない」の二値を取る形で記述することになり、規則が条件の取る値の組合せを網羅しているかどうか判りやすいからです（条件数をNとすると組合せ総数は2のN乗になる)。
（デシジョンテーブルの読み方書き方が身についてきたら、自ずと拡張指定や後述の簡単化に挑戦するようになるでしょう）

一度に扱う条件の個数を少なく抑える

デシジョンテーブルはその性質上、条件の数が増えるか、条件の取る値の数が多いと、テーブル(規則の数)が爆発的に巨大化します。巨大なデシジョンテーブルは、まず書くのが大変で（作成支援ツールを使う場合はこの限りではありません）、読みづらく、レビューやチェックも困難です。経験上、条件の数は3～4個程度までが、書くのもチェックするのも扱いやすい大きさです。

表の巨大化に対しては、後述の簡単化や、本稿で割愛した補完規則などの“対策”はありますが、いつでも適用できるとは限りませんし、適用すればいいというものでもありません。
条件の個数が多くなるのを避けられない場合は、デシジョンテーブルを分離できないか検討してみるとよいでしょう（「条件や条件の取る値の個数が多い時は」参照）

（【つぶやき】この「一度に扱う対象を小さくする」は、ソフトウェア設計の重要な原則でもあります）
（【つぶやき】トレーニングの教材づくりで6条件の制限指定デシジョンテーブルを書いたことがあります（2の6乗⇒64通り！）。制限指定の場合は全組合せを機械的に導出することができますが、コピペを駆使しても全組合せを書くのは大変でした。まして、各組合せに対する適切な動作をマークするのは……一回で懲りました）
（【つぶやき】とはいえ、『ソフトウェア構造化技法』には実践的な例として巨大なデシジョンテーブル(拡張指定。規則42、動作19……)が掲載されていて、「表として一瞥できる」のもまた重要な性質だと思います）

条件の取り上げ方に気をつける

本節の内容はJISには関係ありません。「そういう考え方もある」程度に捉えてください。
条件の取り上げ方(記載の仕方)に気をつけると、条件部を書きやすくなったり、規則の網羅や解釈がしやすくなったりします。
（なぜこういうことを書くかというと、テスト技法のトレーニングでデシジョンテーブル作成のワークをしてもらうと、これでつまづく人をしばしば見かけるからです）

説明に先立って、本稿独自の用語（しかも本節限定）を導入します。
条件を構成する要素を“条件要素”と呼ぶことにします。条件要素ひとつからなる条件を“単一条件”と呼び、ふたつ以上の条件要素からなる条件を“複合条件”と呼ぶことにします。複合条件は、単一条件がAND/ORで結合されているものです。同一の条件要素でも、AND/ORで結合されている場合は複合条件です。

(1) 「入力値が10以上である」は、入力値を条件要素とする単一条件です。
(2) 「入力Aが0.5未満であるか、入力Bが0.5未満である」は、入力A、入力Bを条件要素とする複合条件です。（入力Aが0.5未満 OR 入力Bが0.5未満」）
(3) 「参加者数が5人以上10人以下である」は、参加者数を条件要素とする複合条件です。（参加者数が5人以上 AND 参加者数が10人以下」）

(例示。引用にあらず)

（なんで独自の用語を導入するかというと、JIS X 0125の「条件」(ISO 5806でも”condition”と呼んでいる)はこの区別をしておらず、混同を避けるためです……）

条件記述部に記載する条件は、以下の方針で考えるとよいでしょう。

  1. 複合条件と考えられるものがあったら、単一条件に分解してみる。

    • 特に、複数の複合条件の中に同じ単一条件や条件要素が何度も現れる場合は、分解して単一条件として表せないか検討する。

  2. 原則として単一条件を記載する。

  3. ただし、複合条件のまま記載してもよい場合がある。

    • 例：ひとつの条件要素が同じ動作を引き起こす同値クラスに属することを表している（「ユーザーの権限が"一般ユーザー"であるか、"ゲスト"である（その場合、閲覧はできるが編集はできない）」など）

    • 例：ひとつの条件要素が連続する値の範囲内にあることを表している（「参加者数が5人以上10人以下」など）

    • （これらも単一条件に分解できますが、条件数が多くなるのも好ましくないので）

テスト技法のトレーニングで例題などによく使われる「閏年判定のロジック」で考えてみましょう。

うるう年/平年は、西暦年に対して以下の条件によって決まります
(1) 4で割り切れない年は、平年
(2) 4で割り切れる年のうち、100で割り切れない年は、うるう年
(3) 4で割り切れる年のうち、100で割り切れるが、400で割り切れない年は、平年
(4) 4で割り切れる年のうち、100で割り切れ、400で割り切れる年は、うるう年

この判定条件、一見そのまま条件部に書き出せそうに見えるかも知れませんが（事実、書き出せはしますが）、そうすると色々大変なことになります。

Fig.04 閏年判定：頑張った(？)例

(2)～(4)は、「ANDで結合された複合条件」です。これらは「4で割り切れる」「100で割り切れる」「400で割り切れる」という単一条件に分解して条件部に書くのがよいです。（どれも条件要素は「年号の値」ですが、それぞれの単一条件は異なる同値クラスを表しています）
閏年判定のロジックは条件指定部の規則として表します。たとえば、(2)は「条件『4で割り切れる』が"Y"で、条件『100で割り切れる』が"N"の列(規則)」に該当します。下の図の規則5, 6です。

Fig.05 閏年判定：単一の条件と、その組合せとしての規則

閏年判定のロジックを表すデシジョンテーブル全体は次のようになります。

Fig.06 閏年判定：単一条件の全組合せ

Fig.04と見比てください。規則を満たすかどうか考えるのも、単一条件に対して考える方が楽です（Fig.04では、「複合条件として満たす/満たさない」を考える必要があり、そこで個々の単一条件に分解した上で単一条件間の関係やその否定（つまり、論理演算）を考えなければなりません）。

簡単化

閏年判定のデシジョンテーブル・全組合せ版、(。´･ω･)？と思うところがいくつか見つかるかと思います。
規則1～4はいずれも「4で割り切れる」が"N"の場合で、「100で割り切れる」「400で割り切れる」の値は"Y"/"N"さまざまですが、結果は同じ「平年である」となっています。つまり、「4で割り切れる」が"N"なら、他の条件の値がどうであれ平年です（判定ロジックがそうですから……）。
規則5, 6も、「400で割り切れる」の値を除けば他の条件と動作部はまったく同じです。つまり、「4で割り切れる」が"Y"で「100で割り切れる」が"N"なら、「400で割り切れる」かどうかを待たずに結果は決まります。

このような場合、簡単化という“テクニック”を使うことができ、テーブルの該当部分を次の図のように書くことができます（規則の番号は、全組合せ版との対照のためにそのままにしてあります）。

Fig.07 閏年判定：簡単化

簡単化の記述と解釈の決まりは次の通りです(箇条3.2、および附属書1・箇条3)。

  • 当該条件に関係なく規則が満たされる場合、当該条件の値以外同一である規則を畳み込むことができる。その際、当該条件の値として、結果に関係しないことを示す記号"-"を記入する（制限指定でも、拡張指定でも）。

  • 「当該条件に関係なく規則が満たされる場合」は次のいずれか。

    • ①当該条件がどの値を取ろうが関係なく規則が満たされる

    • ②当該条件はその規則には関係し得ない（起こり得ない、あり得ない）。こちらの場合であることを強調するために記号"#"を記入してもよい

  • なお、動作部も同一の規則(動作、順序が同じ)でなければ畳み込めない。

②と①の違いはビミョウに感じられるかも知れません。ユーザー入力に関連づいた条件Pがあるとして、①は「この規則ではユーザー入力がどんな値でも（条件Pが満たされても満たされなくても）規則を満たす」場合。②は「この規則はユーザー入力自体がない状況なので条件Pは当てはまらない」場合、といった違いです。

簡単化はテーブルの巨大化を抑制し、テーブルの見通しをよくする作用があるので、条件間の関係を見極めて使えるようにしたい“技”です。

（【補足】閏年判定では、年号が4で割り切れなかったら100でも400でも割り切れる筈がないわけですが、「"Y"という値は取り得ないのなら、"N"と明記して差し支えない/明記するべきでは？」という議論もあります。筆者の考えは、「"N"と記した場合、"Y"の場合の規則が仮定されてしまう(見落としの誤解を与える)ので避けた方がよいだろう」「"Y"になり得ないことを畳み込んでいるのを明示するために、"-"がよい」です）
（【つぶやき】筆者が「簡単化」という用語を知ったのは、デシジョンテーブルを知ってからけっこう経って、JIS X 0125:1986ででした。それまでは、表を畳み込むイメージから「縮約」と言っていました。今でも言います。JISを知り、ISTQB-FLシラバス2018年版でも「簡単化」が取り入れられてからは、説明ないし明記した上で併用しています）

論理ORを表す

前述のとおり、デシジョンテーブルでは、複数の条件は論理ANDの関係にあると解釈されます。
仕様によっては「条件Aが成り立つか、または条件Bが成り立つ場合、……」のように、論理OR(A OR B)の関係にある条件が絡む場合もあります。そのような場合、デシジョンテーブルをどのように記述すればよいでしょうか。
A OR Bは、こういうことを言っています：

  • Aが成り立つならば、Bが成り立っても成り立たなくても(＝Bの如何に関わらず)、全体が成り立つ。

  • Bが成り立つならば、Aが成り立っても成り立たなくても(＝Bの如何に関わらず)、全体が成り立つ。

  • AもBも成り立っていない場合のみ、全体が成り立たない。

これは、次図のような規則として表すことができます：

Fig.08 ORの表現

これに簡単化を適用すると、次図が得られます（規則1, 2は、条件Aが"Y"なので条件Bに関わらず結果が決まる。規則1, 3は、条件Bが"Y"なので条件Aに関わらず結果が決まる。規則1は規則2, 3に「畳み込まれる」）：

Fig.09 ORの表現：簡単化

（【つぶやき】簡単化された表現の方が論理ORの性質をよく表していると思います）
（なお、二値論理(論理演算)の基本については別の文章を書く予定でいます。よかったらそちらもお読みください）

条件や条件の取る値の個数が多い時は

JIS X 0125:1986では、大きい複雑な問題は、複数のデシジョンテーブルを組み合わせて表現することができるとして、数種類の組合せを定義しています(箇条5)。また、附属書箇条2で、以下のように述べています。

ある種の問題においては、条件の個数によって、規則の個数が非常に多くなる場合がある。1枚の紙に書き切れない表は、何らかの論理的境界で分離して複数の表にし、適切な順番関係又は選択関係で構成することが望ましい（本体5.1及び5.2参照）。

JIS X 0125:1986 (強調は引用者による)

本稿では「順番関係(sequence)」によるデシジョンテーブルの分離の例を示します。この例では、本来二値の条件が3つ＝8列のデシジョンテーブルになるものが、条件Aの値から小さなデシジョンテーブル(二値の条件2つ)を呼び出すことでひとつ当たりのテーブルを小さくしています。

Fig.10 デシジョンテーブルの分離

デシジョンテーブルを分離する場合は、分離したテーブルが分離元のテーブルの“部分”であることを明記するのがよいでしょう。

デシジョンテーブルテストへ

仕様の理解（理解したと思ったことの表現）や詳細化、仕様記述の整理・分析のために書いたデシジョンテーブルは、（ソフトウェア設計者にとってはプログラム設計の入力になりますし、）テスト視点で見れば「それを基にテストを考えることができる」ことになります。ISTQBシラバスやISO/IEC/IEEE 29119-4でテスト技法/テスト設計技法として取り上げられているデシジョンテーブルテストです。

『デシジョンテーブルテストの歴史』によれば、1965年にはテスト設計に適用した論文が発表されているそうで、歴史は相当古いようです。
不勉強にして筆者の身の回りでは見聞きしたことがありませんでした（マイヤーズ本は何度も読み返してお世話になっていましたが、デシジョンテーブルは原因結果グラフのついでに出てくる感じで印象が薄かった……）。筆者がデシジョンテーブルを書いてテストを設計した時は、テスト技法を使っているという意識もありませんでした（テスト技法とは認識していなかったので当然ですが）。

{ISTQB, ISO/IEC/IEEE 29119}的網羅基準と基本的な考え方

「デシジョンテーブルのすべての規則をテストすること」が“標準的なテストカバレッジ”とされています。
すべての規則をテストする(テストされない規則がないようにする)　＝　
ひとつの規則にひとつ以上のテストケースを設ける
ようにします。

規則に適合するテストケースを考える・その1

規則中の各条件の値を満たす値を考えます。ここで同値分割や境界値分析といった他のテスト技法が活躍します。
Fig.09は説明用のサンプルです。旅行サイトの割引クーポン回りの仕様の一部とでも考えてください。

Fig.11 テストを考えるサンプル

条件Aは、規則に対してふたつの同値クラスが見てとれます(同値分割)。規則1, 2に適合する「“東北”、または“九州”」と、規則3, 4に適合する「“東北”でも“九州”でもない地域」です。
条件Bは、やはり規則に対してふたつの同値クラスが考えられます。規則1, 3に適合する「4人以上」と、規則2, 4に適合する「4人未満」です。条件Bはさらに数値の範囲ですから、4人が境界値と考えられます(境界値分析)。

規則1のテストを考えます。条件Aの候補は“東北”または“九州”ですが、同値分割の考え方を行使してどちらかひとつ、例えば“東北”を選べばテストはひとつになります。「でも“九州”もテストしておこう」と考えれば、テストはふたつになります。条件Aが"Y"である規則は1, 2とふたつありますから、規則1では“東北”で、規則2では“九州”でテスト、とするのも手ですね（どちらがよいか、どちらにするかは一概には言えません。テストの目的や求められる網羅度、得られる安心感、時間・工数の制約などの影響を受けます。以下同様）。
条件Bは、規則1を満たす値として境界値4を選ぶことになるでしょう。規則1で条件Aの“九州”もテストするなら、条件Bは同じ境界値4にするか、同値クラスの別の値を選ぶか、考える余地があります。
規則3, 4では条件Aは「“東北”でも“九州”でもない地域」になります。同値分割の考え方を行使してそれぞれひとつの地域を選ぶこともできるでしょうし、テストケースを増やして全地域をテストしておこうという考え方もあるでしょう。

このように、条件に適したテスト技法があればそれを適用して、規則を満たすような各条件の値を考えていきます。その結果規則ひとつに対してふたつ以上のテストケースを導出することもあります。条件によってはドメイン分析テストなどの技法が活躍することもあるでしょう。
（こうしてデシジョンテーブルに基づいてテストを考えていくと、「一つの規則に対してどれだけテストをするのがよいのか（既述）」や、「ほかのテスト条件に対するテストと重複する場合はどうするか」「別のテストでやっている、あるいは別にテストする予定があることと被る場合は」といったことが気になってきますが、それは重い話題なので、本稿では割愛します）

規則に適合するテストケースを考える・その2(簡単化された規則の場合)

簡単化されたデシジョンテーブルをテストする場合、"-"は「この条件は規則には関係しない」のだから"Y"でも"N"でもかまわないわけですが、適当にいい加減に決めるしかないでしょうか。どんな場合にも通用するとは言いませんが、「適当」「いい加減」よりマシな具体値を考える手がかりはあります（マシというのは、「なぜこの値を選んだか、根拠を言える」という意味）。

簡単化できる場合の①「当該条件がどの値を取ろうが関係なく規則が満たされる」。先のサンプルは、実は簡単化が適用できる対象です。規則2から規則3を見ると、条件Aと条件Bは「どちらかが"N"なら、（他の条件の値に関わらず）割引は適用できない」関係にあると見て取れます。簡単化すると：

Fig.12 テストを考えるサンプル：簡単化

  • 考え方(1)・テストの意図が判りやすい値を選ぶ。規則2, 3とも「どちらかが"N"なら割引はしない」と言っているのに、"-"の値として"N"を選ぶと（どちらの条件も"N"にしてしまうと）どちらの規則をテストしようとしているのか混乱を招きます。従って規則2, 規則3の条件A, Bとも"Y"を選ぶのがよいと言えます。

  • 考え方(2)・故障が起こりやすそうな値を選ぶ。「どちらかが"N"なら割引はしない」なら、“結果に関係しない”方の条件を"Y”にしてみたらどうでしょうか。割引はされない筈ですが、もしかしたら……！？　この考え方でも規則2, 規則3とも"Y"を選ぶのがよいと言えます。

簡単化できる場合の②「当該条件はその規則には関係し得ない（起こり得ない、あり得ない）」ではどう考えるとよいでしょうか。また別のサンプルを見てみましょう。条件A「スイッチがON」が"N"(＝スイッチがOFF)だったら、（計測自体がされないため）計測値がない、というイメージです。

Fig.13 テストを考えるサンプル(2)：簡単化の場合②

規則3、計測がされないなら、計測値はNULL(null)かも知れませんし、不定値(ゴミ)かも知れません。NULLだった場合や値が100未満だった場合の対処は設計・実装されていておかしくありません（そういう仕様だから）。それなら、100以上の値を与えてテストしてみると、思わぬ故障が見つかるかも知れません。先の考え方(2)に該当します。

なお、「簡単化は条件が取り得る値を"-"で代表しているのだから、テストする場合はその条件が取り得る値を全部展開して適用すべきだ」という考え方もあります。前述の考え方はヒント程度に捉えてください。

結び

JIS X 0125:1986は、2021年に「確認」され現在も有効である、生きた規格です。ちょっと堅苦しく感じられたり（動作部の記述など）、用語や内容が古びて感じられたりするかも知れませんが、厳密な適用が考慮されたものであり、（既に知っている人にとっても）直感的に理解していたことの裏づけを与えてくれる、というのが筆者の認識です。「デシジョンテーブル、（よく）知らない」という人にもお勧めです。

デシジョンテーブルというものを知らずにいて、ISTQBのシラバス（や、テスト技法の解説書）で初めてデシジョンテーブルテストに接すると、テスト設計のためのツールに見えてしまうかも知れませんが、そんなことは全然ない、テスト設計に先立って使うこともできるし使う値打ちがあるんだよ、ということを知ってもらえたら嬉しいです。

本稿の焦点から外れる話題を「補遺・デシジョンテーブルとデシジョンテーブルテスト (T3:Pt2:Ch01)」にまとめました。暇があったら読んでみてください（暇がないのに読むほどのものではありません）。

デシジョンテーブルの作成や解釈のあちこちにAND/ORといった論理演算が登場していることに気づかれたと思います。デシジョンテーブルの理解を深め、使いこなすには、論理演算の理解は欠かせません。
論理演算の基本について、別の文章を書く予定でいます。よかったらそちらもお読みください。

参考文献

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

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

  • ソフトウェア構造化技法―ダイアグラム法による / J.マーチン, C.マックルーア / 近代科学社

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

(2023-08-02 R001)

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