第94回： デシジョンテーブル（後編）
≡ はじめに
「ASTERセミナー標準テキスト」の105ページについてです。
前回は、デシジョンテーブルの基礎について書きました。今回は、基礎を踏まえた実践編ということで、「デシジョンテーブルの簡単化」と「デシジョンテーブルのルールとテストケースの関係」と「デシジョンテーブル2つの形式」の3つについて書きます。
「デシジョンテーブルの簡単化」とは、条件の全組合せだと巨大化してしまうデシジョンテーブルに対して、“条件の一部をズームアウトすること”や、“全組合せのテストを諦めて、妥協できる網羅基準で小さなデシジョンテーブルに変える”ことです。
2つ目の「デシジョンテーブルのルールとテストケースの関係」とは、デシジョンテーブルのルールの数とテストケースの数との関係のことです。基本は1対多になります。
3つ目の「デシジョンテーブル2つの形式」とは、基本的な形式と、松尾谷徹さんのCFD法で見かけるデシジョンテーブルの形式の違いのことです。理由についても考えます。
どれも、デシジョンテーブルテストを実施するときには知っておいた方が良いことです。
≡ デシジョンテーブルの簡単化
「デシジョンテーブルの簡単化」とは、条件の全組合せだと巨大化してしまうデシジョンテーブルに対して、“条件の一部をズームアウトすること”や、“全組合せのテストを諦めて、妥協できる網羅基準で小さなデシジョンテーブルに変える”ことです。
「巨大化してしまう」と書いたとおり、そもそも巨大化しなければデシジョンテーブルを書く必要はありません。
私はテストを始めた頃、“組合せテストについては。どんな時でもデシジョンテーブルを作るもの”と思い込んでいました。
でも、「巨大化しないのなら、デシジョンテーブルを作らずに全組合せのマトリクスを作ってテストする方が良い」と日科技連主催の「松尾谷徹のCFD法セミナー」（5日コース？）に出たときに教わって目から鱗でした。目安としては条件が4つまでなら簡単にマトリクスが作れますし、テストもしきれます。4^4でも256回のテストですから、悩むくらいなら、“やっちゃえNISSAN”です。
ところで、簡単化の方法については、湯本さんのnoteにディシジョンテーブルを見ながら簡単化する方法の解説があります。また、『ソフトウェアテスト技法練習帳』にデシジョンツリーを書いてそこから簡単化したデシジョンテーブルを作成する方法が丁寧に書いてあります。
ですから、それらに付け加えて、ここに書くことは何もありません。
そこで、ここでは、「簡単化する方法の説明は最小限として、簡単化の意味や注意点」を中心に書きます。
まずは、説明のための例題の仕様です。
仕様：
・ 水曜日のみ女性には女性割引（※）が適用される
・ 水曜日かどうかの判定のあとに女性かどうかの判定を行う
（※） 映画が1,100円になるとか。いいなあ。
このときに、通常のデシジョンテーブルを作ると、以下のようになります。
これを簡単化すると、以下のようになります。
要は、水曜日が“N”のときには、女性かどうかに関わりなく女性割引は適用されないので女性の条件には「“Y”と“N”のどちらでも構わない“－”マーク」を書き込み、4つのルールを3つにするのが簡単化です。
この簡単化したデシジョンテーブルからテストケースを作ります。例えば以下のようにテストケースを作ります。
ルール1に対するテストケースは、
入力： 水曜日で女性
期待結果： 女性割引となる
でしょう。
ルール2に対するテストケースは、女性が“N”となっている点が気になるところです。
女性が“N”を“男性”としてテストすればよいのでしょうか？
もちろん男性のテストは必要ですが、性別が確認できなかった条件でもテストしたいところです。
したがって、
入力： 水曜日で男性
期待結果： 女性割引とならない
入力： 水曜日で性別確認できず（※）
期待結果： 女性割引とならない
※ 操作としては、性別のラジオボタンを両方オフにすることを想定
といったようなテストケースが考えられると思います。
GUIや入力や運用仕様にもよりますので、あくまでも、考え方の例としてです。
ルール3に対するテストケースは、もっとモヤっとします。
まず、水曜日が“N”について、どうしましょう？
同値分割をして、水曜日以外の同値パーティションから一つ（例えば月曜日）をテストしたらよいでしょうか？ 曜日には順序が付けられるので、水曜日以外を境界値分析する方が良いでしょうか？ そのときは、日曜日と土曜日が境界値でしょうか？ それとも、水曜日の直前の火曜日と、直後の木曜日が境界値でしょうか？？
ひょっとしたら、
・ 無効同値パーティション： 日、月、火
・ 有効同値パーティション： 水
・ 無効同値パーティション： 木、金、土
と考えて日火木土の4曜日をテストする人がいるかもしれません。
次に、女性の“－”が悩ましいです。どちらでもよいのだから、“Y”でも“N”でも同じと考えますか？ それとも、このロジックがANDである（かもしれない）ことを想定して“Y”にすることで、「水曜日でなかったらもう一つの条件が整っていても女性割引にならない」こと（言い換えれば、水曜日が“N”の条件が結果に影響を与えていること）を確認しますか？？
そもそも簡単化している箇所が1番バグを作り込んでしまう箇所じゃないの？ という話も。
この話を深追いすると簡単化が使えなくなるので、「気になった人は、簡単化で見つからなくなるバグが作られるパターン」について考えてみてくださいね。
このモヤモヤは【網羅基準を決めていない】ことが原因です。
「（いちいち網羅基準を決めるのは面倒だから）なんとなく状況を察して、いい感じにテストケースを作ってよ」というのがテストの現場の本音だと思います。
現実には、このようなモヤモヤすら感じずに、デシジョンテーブルから直接テストを実行している組織の方が多いのかもしれません。
ここで残念なお知らせなのですが、「この網羅基準を使え」という正解はありません。テストの7原則の6にある通り「テストは状況次第」ですので、例えば、水曜日が“N”の条件のルールに対して、残りの日月火木金土の6つの曜日を全部確認することが正解の場合もあるでしょう。
もしも、以前のバージョンでは、水曜日ではなく火曜日が女性割引の曜日だったら“火曜日”をテストすべきでしょう。
まさに、「テストは状況次第」です。
このように、正解は無いのですが、テスト担当者の知恵だけでなく組織の知恵を結集するという戦略はありです。
つまりテスト設計レビューです。
今回、意思決定が必要なのは、
(1) 個々の条件のズームイン・ズームアウト
： 湯本さんのnoteで「条件の全体像の把握と同値分割の粒度の設計」と書いてあるもの
(2) 組合せの網羅基準
の2つです。
こちらが決まれば、あとは機械的にテストケースが作成できますので、この2点をレビューします。
できあがったテストケースだけでは、上記2点についてテスト担当者がどう考えたのかわかりません。
そこで、条件を整理した過程（例えば、NGTやマインドマップ）や組合せを作ったツール（例えば、CEGTestやクラシフィケーションツリーやCFD）をレビューのときに伝える必要があります。
≡ デシジョンテーブルのルールとテストケースの関係
2つ目の「デシジョンテーブルのルールとテストケースの関係」とは、“デシジョンテーブルのルールの数”と“テストケースの数”との関係のことです。基本は1対多になります。
1対多になるのは、一つ前の「デシジョンテーブルの簡単化」の話題を読んだときに気が付いたと思います。
でも、それは説明のためであって、実際にテストケースを1対多で作るのかというと、私は作りません。理由は、
・ メンテナンスの手間がかかりすぎる
・ 作ったテストケースのレビューができない
からです。
■ メンテナンスの手間がかかりすぎる
テストの実施中に「条件漏れ」が見つかることはよくあります。
例えば、電子マネーの種類について、“スマホアプリ”が漏れていたなどです。
そのようなときに、テスト分析に使ったチャートを直して、デシジョンテーブルを直して、テストケースを直すのは面倒です。直した後には、マネジメントの承認を取る必要もありますし。
怖いのは、「面倒だから、“スマホアプリ”はテストはするけど、デシジョンテーブルやテストケースは直さない」人が出ることです。
「直さないけど、テストはするので文句ないだろう」と思う人が多いのですが、百歩譲ってそのプロダクトのテストとしては良いとしても、次のバージョンアップ時に“スマホアプリ”が漏れているデシジョンテーブルが参照され再利用されることを考えると怖いです。
■ 作ったテストケースのレビューができない
デシジョンテーブルから作成したテストケースは条件の値が違うだけで同じフォーマットの文章のことが多いので、読んでいると集中が途切れます。また、ナラティブ（散文的）な文章をリバースして条件のセットを見つける作業は手間がかかります。
ですからテストケースのレビューをしても、「この機能に対してXX件もテストケースがあるのなら大丈夫でしょう」という、いい加減なレビューとなりがちです。
そこで、私は、テストケース数が多くてもルールの1.5倍くらいで済むような粒度の細かいデシジョンテーブルを原因結果グラフから作るようにしています。
CEGTestのようなツールを使うことで組合せの網羅基準は自動的に決まりますし、メンテナンスもツールに入力する条件を更新するだけで済みます。
≡ デシジョンテーブル2つの形式
3つ目の「デシジョンテーブル2つの形式」とは、基本的な形式と、松尾谷徹さんのCFD法で見かけるデシジョンテーブルの形式の違いのことです。ここでは、違う理由についても書きます。
まずは実物を見てみます。
普通のデシジョンテーブルとして、先ほどの女性割引のものを再掲します。
こちらについて、CFDで見かけるデシジョンテーブルの形式で書くと、
となります。
「1」が入っているセルが選ばれている条件です。
合計は、単に横合計で、ここが0だと一度もその条件のテストがされないことを意味します。手作業で表を作るためうっかりすることがあります。特に大きな表になると実用的なテクニックです。
縦計も求めて、その数が多い順からテストすると多くの条件を早く確認出来るというテクニックもあるのですが、こちらは、左から順番にテストをする方がテストしやすいのでお勧めしません。
この表の良さは、「曜日は“水曜日”か“水曜日以外”」、「性別は、“女性”か“男性”か“確認できず”」というように、それぞれの条件について同値分割をどのように行ったか、分割後の同値パーティションは排他関係にあるかを行見出しでチェックできることです。同値分割のところで学んだ「補集合」についてのレビューも簡単にできます。
また、多値の条件もルールのセル内に書く必要がありませんのでルールの抜け漏れチェックの負担が軽くなります。
一方で、全部の組合せを作ってから簡単化したいという場合は、普通のデシジョンテーブルの方が簡単です。
先に2の条件数乗分の列を作ってから、1行目について半分をY残り半分をN、2行目について1行目のYの下を半々に1行目のNの下を半々に、、、とすることで機械的に作れるからです。
条件が4つあれば、まず、2^4=16列作って、
1行目についてYを8個Nを8個（YYYYYYYYNNNNNNNN）、
2行目について4個4個4個4個（YYYYNNNNYYYYNNNN）、
3行目について2個2個2個2個2個2個2個2個（YYNNYYNNYYNNYYNN）、
4行目について交互に（YNYNYNYNYNYNYNYN）
と記入すれば全組合せの完成です。
ということで、CFD法で見かけるデシジョンテーブルの形式は、手作業でCFDからデシジョンテーブルを作成する上級者向けかなと思います。（CFD法については、そのうち書きたいと思っています。すぐに勉強したい人は、手前味噌ですが『ソフトウェアテスト技法ドリル』でマスターしてください。ウェブだと、Enterprise Architectのプラグインの説明ページが良いかな。
CEGTestも同じですが、このようなテスト設計をサポートするツールは決まったアルゴリズムでデシジョンテーブル が作成されるため、何も考えなくても適当な網羅基準がついてくるので、どんどん活用したほうが良いと思います）
≡ 終わりに
今回は、デシジョンテーブルの実践編でした。
デシジョンテーブルはテストでは必ずと言っていいほど作ります。ですから、この機会に前回含め読み直してマスターしてしまいましょう。
（これが分からないと、原因結果グラフやCFD法も中途半端な使い方になってしまいます）
次回は「状態遷移テスト」について書きたいと思います。
こちらも、「状態って何？」、「何をテストしたいの？」という話から書こうと思っているので、前・後編になりそうです。
テスト技法は、先人の工夫が詰まっているので楽しいのでつい長くなってしまいます。
