第203回： 「ソフトウェアテストしようぜ」19 GIHOZ（6. デシジョンテーブルテスト後編）
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は、「デシジョンテーブルテスト」の簡単化の３つの方法のうち、ラスボスの「網羅基準を全組合せからMC/DCに変えることで、デシジョンテーブルを小さくする話」について説明しました。
MC/DCや原因結果グラフがイマイチ苦手という人は、処理の順番に条件を並べて、下の方から簡単化していくといいです。
また、このノートのマガジンにまとめたCFD法を使ってデシジョンテーブルをつくってもよいです。同値図をなぜ処理順に並べるのか、CFD法の説明の回では結論の「同値図を処理の順番で時系列に並べ、それらを流れ線で結合しCFDを作成します」だけを書いていますが、今ならその理由を説明できるようになっているはずです！？
今回は、GIHOZの「デシジョンテーブルテスト」ツールを使い、GIHOZ用のテストをつくる話です。
≡ 前回の練習問題をGIHOZで解く
まずは、GIHOZのデシジョンテーブルテストツール（長い名前だな。DTTT？）を知るために、前回に出した「練習問題」をGIHOZで解いてみます。
問題は次のとおりです。
大規模イベントを開くにあたり、警備員を1名募集することになった。その条件は以下の通りであり、条件に当てはまれば報酬額を当てはまらなければ“不採用”を出力するものとする。
1. 身長： 180cm以上
2. 性別： 男性
3. 報酬： 経験者3万円、未経験者2万円
上記について、デシジョンテーブルを作成して簡単化せよ。
※ プログラムは、2→1→3の順に処理している。
前回、こんなことを書きました。
専門用語を覚えるよりも、「条件は入力の同値クラス（同値パーティション）、動作はテスト対象の主要な機能処理部分を指す」ということを理解しているほうが、ずっと大切と思います。
ということで、まずは、仕様（問題文）から、デシジョンテーブルの「条件」（入力の同値クラス）と「動作」（テスト対象の主要な機能処理部分（や出力の同値クラス））を見つけます。
「条件」については、「身長が180cm以上である」と「性別が男性である」はすぐに見つかると思います。
3の「報酬： 経験者3万円、未経験者2万円」から、「（警備員の）経験者である」という条件を見つけることはちょっと難しいかもしれませんが、数をこなせばすぐに見つかるようになります。
次に、デシジョンテーブルに書く条件名ですが、「身長：180cm以上」、「性別：男」、「経験有」といったように端的にまとめます。（「経験有」としている理由は、YとNで答えられる条件名にしたいからです。）
端的にまとめる意味は、表の横幅を取らないことでルールを少しでも多く画面に表示したいという意図と、短い方が理解しやすく間違いに気づきやすいというメリットがあるからです。
「動作」の方は、「採用結果」と「報酬額」としました。それではGIHOZに入力してみます。
問題文に「プログラムは、2→1→3の順に処理している。」とあるため、条件は上から「性別→身長→経験」の順番となります。
条件部と動作部の入力が終わったら、デシジョンテーブルの上にある、[組み合わせを生成]ボタンを押します。
ボタンを押すと、GIHOZがYとNを埋めてくれます。とても便利です。
あとは、「動作」について入力します。出来上がったデシジョンテーブルはこちらです。
このように、セルの中には「YN-」だけではなく、「3万円」や「2万円」といったように、任意の文字を入力することができます。条件も同じです。
それでは簡単化のために、結果に関連性のない条件の値を「-」（関係なし）で置き換えます。
上の図は、セルの範囲選択やコピペを使って、セルのYとNを「-」で置き換えたところです。重複している（＝同じ条件の組合せで同じ動作となる）列の列番号が赤くなり、列番号上にマウスを移動すると上図のようにどの列が重複しているかを表示してくれます。（上記の例では、8列目の見出しにマウスカーソルが当たっています。）
ちょっと気になったので、多数の重複列をつくってみました。
スクロールバーが出るのですね。（中身のコピペもできました）
私は、実際のテスト実行のときにも、こういった寄り道をよくします。そして「おぉ、うちの開発者えらい（みわさんふう）」となります。
重複列の情報を参考に、「有効/無効」のチェックを外せば、簡単化の完成です。
無効列を削除しても構いません。
列は複数のセルを選択してまとめて削除できますので、いまのGIHOZの仕様のままでも良いとは思うのですが、多くの列を持つデシジョンテーブルのために「無効列を非表示にする機能」あるいは「無効列を削除する機能」があってもいいかなと思いました。レビューのときなどに役立ちそう。
MC/DCにしたいときには、（今回のケースなら）「andなのでYを埋める」方法を用います。
続いて、[テストケースを生成]ボタンを押すと以下の表が得られます。
デシジョンテーブルの方が分かりやすいと思いました。動作のところは、「採用結果, 3万円」といった意味不明のものになってしまいました。「採用結果」ではなく「採用」にしておけばよかったですね。
「テストケース」生成機能よりも、「デシジョンテーブルの縦横変換」機能があるほうがうれしいかもしれません。
いや、その前に条件が追加された時の「デシジョンテーブルの再生成機能」の改良が先か？
条件を階層化したパターンも載せておきます。
テストケースはこのようになりました。
こちらの方がテストケースは見やすい（動作名を直したから？）ですが、デシジョンテーブルは2値のほうがよいでしょうか。
「性別：男」は「性別」の方が良いですね。直し忘れですが、間違いの例として残しておきます。
条件が多値の場合は必然的にこちら（EEDTs）を使うことになります。
この練習問題について、よこぴーさんから回答をいただいています。
練習問題解いてみました！ pic.twitter.com/b82Ve1MmSI
— よこぴー (@y_6_5_) November 15, 2022
「条件」と「動作」の書き方は少し違いますが、もちろん正解です。ありがとうございます。
※ こうして解けているのを拝見すると、安心します。（もっとも、よこぴーさんは、このnoteを読まなくったって解けていると思うけど、それはそれとして。）
なお、デシジョンテーブルの「動作部」ですが、元々は動作するモジュール名を書いていたようです。
今は、「結果」を書くことの方が多いかもしれません。
≡ GIHOZのテスト
それでは今回のテーマの「GIHOZのデシジョンテーブルテストツールへの適用」をおこないます。
GIHOZデシジョンテーブルテストツールのマニュアルに以下の文があります。
デシジョンテーブルテストとは、複雑な判定ロジックの整理に有用なデシジョンテーブルを用いて、 入力条件の組み合わせと対応する出力結果を整理することでテストケースを作成する技法です。
言い換えると有則部分に対しておこなうテストです。
太字にしたとおり、デシジョンテーブルテストは、「複雑な判定ロジックの整理に有用」です。
したがって、「複雑な判定ロジック」があるテストアイテム（テスト対象のなかで着目している小さな箇所）を探す必要があります。
通常の業務ではテスト技法を先に想定して、想定したテスト技法を適用する所を探すアプローチはスジが悪いです。
でも、このnoteでは、GIHOZのツールにデシジョンテーブルテストを適用することでツールの活用事例をつくり、それを通してテスト技法とGIHOZを同時に理解することが目的なので、しかたがありません。
それと、テスト技法は練習問題を解くことに加えて、実業務で使ってみることによって、理解が進みますし自信もわいてきます。ですから、テスト技法からその技法が使える箇所を探すことにも、メリットがあるかなと思います。
実際には単に“テストつくるの楽しー”ってだけなのですが……。
■ テストアイテムの選定
まずは、どこをテストするのかについて決めるためにGIHOZのヘルプを読みました。
ところが、サラッと読んだだけでは、「複雑な判定ロジック」を持つ組み合わせの仕様は見つかりませんでした。マニュアルは設計仕様書ではありませんから、たとえ複雑な仕様があったとしても、そう思わせない工夫がされているはずです。
そこで、内部の実装を想像しながら、もう一度、ゆっくりとマニュアルを読み直しました。そうして、見つけたのが「デシジョンテーブル上の右ボタンメニュー」です。
こちらに対してデシジョンテーブルテストをしたいと思った理由ですが、同じ項目を持つメニューがクリックしているセルによって、利用可（enable：黒色文字）になったり利用不可（disable：灰色文字）にするのは、「マウスの位置の条件に対して、メニューを変更する」という「複雑な判定ロジック」が存在するはずと思ったからです。
まずは、実際のGIHOZのデシジョンテーブルのいろいろな場所で右ボタンを押して、反応を確認しました。確かに場所によってメニューの灰色文字の場所が変わっていました。
Webアプリの場合、内部のロジックは未完成でも、デザイナーさんがつくったGUIはあることが多いものです。
そういうときには、設計仕様書を熟読することに加えて、現物を触りながら理解するのもよいでしょう。
※ 今回のメニューのようなものはデザイナーさんがつくったGUIではでてこないと思いますが。
マニュアルの該当箇所の記載は下記のとおりです。
右クリックメニューは記述部と、指定部で実行できる内容が異なります。
・ 記述部では上下への行の追加、行の削除、元に戻す及びやり直しが選択できます。
・ 指定部では左右への列の追加、列の削除、元に戻す及びやり直しが選択できます。
■ デシジョンテーブルの作成
それでは、上記マニュアルにしたがってデシジョンテーブルを作成してみます。
それでは考察です。まず、ルール2（列2）とルール3（列3）ですが、動作部にある「-」は何でしょう？
「そんなの選択不可（または、disable）に決まっているだろう！？」という声が聞こえたような気がします。
それはそうなのですが、マニュアルには、「記述部では上下への行の追加、行の削除、元に戻す及びやり直しが選択できます。」と書いてあるだけで、「選択できません」とは一言も書いてありません。
ソフトウェアでは、「選択できないこと」もプログラミングして選択できないように作ったから選択できないのであって、勝手に選択できなくなっているわけではありません。
むしろメニューは、「選択できる」ことがデフォルトで、「選択できないこと」を作り込んでいることのほうが多いです。
ですから、今回のメニューのテストでは、「-」の箇所にも着目して、
1. そこがdisableになって灰色文字となっている
2. 灰色文字を選択しても何も起こらない
の方のテストもおこないます。
次に着目したのはルール1です。ルール1では、「記述部」、「指定部」ともに「Y」となっています。簡単化の規則の1番目でやった「実行不可」を適用して消したくなりますが、ちょっと待ってください。
GIHOZでは複数のセルを選択できます。そこで、「記述部」と、「指定部」にまたがる範囲で複数のセルを選択して右ボタンを押すテストをするのは、どうでしょうか。
今のマニュアルでは、このときの仕様が、わかりませんので「テスト不可」です。仕様を確認して期待結果を明らかにしてからテストします。
最後にルール4ですが、今度は、「記述部」、「指定部」ともに「N」です。ここでは、マニュアルに記載のない見出し部分や、表の外側の領域で右ボタンを押してみたいものです。
私は、このように、テストしたいことを見つけるためにもデシジョンテーブルを使っています。
例えば、探索的テスト中に、「ここ、ロジックがありそうだな（if文があるな）」と思ったら、探索する手を止めて、デシジョンテーブルをつくって想像を膨らませて探索箇所を探っています。
そうそう「元に戻す及びやり直し」については、この動きでいいの？と思いました。
最初は、追加削除した行や列の取り消し機能と勘違いしていました。そうではなく、セル内の文字に対する機能のようなのですが、選択中の箇所とは関係ない箇所について働いています。（最後に編集した箇所が対象？）
ひょっとしたらバグかもしれません。バグではないとしてもこのメニューになくても良いと思いました。（ショートカットやミニアイコンの方が良いと思いました。）
■ そのほかのテスト
右ボタンメニューのテストについて考えてきたわけですが、このほかにも最小のテーブル、すべての行の削除、バックアップ機能とのタイミング、キーボードだけで操作、他アプリとのコピー&ペースト、解像度や拡大表示率、などなど。
テストしたいことはたくさんあります。
≡ おわりに
今回は、GIHOZの「デシジョンテーブルテスト」ツールを使い、GIHOZのテストをつくりました。
「デシジョンテーブルテスト」のコツが伝わっているといいなあ。
次回は、GIHOZの次のツールである「状態遷移テスト」に移ります。まずはテスト技法の解説からとなります。
