第236回： 「ソフトウェアテストしようぜ」48 CEGTest（18. CEGTestの良いバグ）
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は、「カバレッジ表」のフォーマットについての説明でした。
原因結果グラフとCEGTestツールについての解説は、前回までで完結しています。
今回は、書こうかどうか迷ったのですが、CEGTestのバグについて書きます。（2023/7/8時点の話ですので、みなさんがご使用されるタイミングでは直っているかもしれません。）
書こうかどうか迷った理由は、「バグがあると知っているテスト設計ツールだから使わない」というように、“CEGTestと原因結果グラフというテスト技法を使わない理由にされる”のが嫌だからです。
新しいことはしたくない人の方が多いものです。
そして、これは、本当に「あるある」な話なのですが、そんな人にとっては、「新しいことをしなくて良い理由」というのは、自分の（新しいソレをしないという）行為を正当化する格好の言い訳となります。
詳しくは、『「変化を嫌う人」を動かす』を読むといいです。
読むといいというよりも、何かを人にしてもらう人は必読の書といってよいほどお勧めの本です。
この本は、タイトルに「動かす」とあるとおり、対処法について書いてあります。
「新しいことをしたくない人に対しては機能メリットを増やすことよりも抵抗を減らすことの方が有効である」とか、そういった知恵がたくさん書いてあります。
たとえば、「大きさ、色、形、素材等々をカスタマイズ可能な、ソファーのオーダーサイトをつくったのだけれど、最後の[オーダーボタン]を押さずにブラウザを閉じてしまう人が多かった」というケーススタディが載っています。
で、あることをしたらこの問題が解決したと……。どうしたかは本を読んでください。（私は「なるほどー」って思いました）
だから、この連載も「さあ、CEGTestをはじめよう。なんで使わないの？」で終わるほうが良いのではないかと思いました。
でも、わざわざこんなnoteを読んでくださる方に、そのような“変化を嫌う人”はいないよなあと思い直しました。であれば、そのような“変化を抱擁する人”にとっては、「CEGTestのバグを知ったうえで使ってもらうのが良い」か、「知らないままに使い始めてもらう方が良いか」と考え、前者を選びました。
≡ 今回のお題
今回のお題です。どこにバグがあるでしょう？
≡ バグの説明
バグはデシジョンテーブルの#4, #5列です 。
デシジョンテーブルを切り取ります。
原因結果グラフから、中間ノードIは、「I ＝ A ∧ B」です。
デシジョンテーブルの#4, #5列では 、AとBはともに「M」（制約MASKによって、原因ノードCがTなので、原因ノードAとBの値は、TかFか定まっていない状態）です。上の論理式に代入すれば、
「I ＝ M ∧ M」
です。
したがって、下表の赤枠部分は、現在のCEGTestツールでは、TとFが入っていますが、「I」（原因側のノードが真偽不明のため真偽が決定できない。）でなければなりません。←これがバグです。
なお、上記バグに引きずられ、#4, #5列の結果ノードE行の値も間違っています 。
≡ 対処方法
一番簡単な対処方法は、「制約MASKは使用しない」です。これは、この連載で何度も出てきました。
私が知っている限り、ブラウザの違いに基づくGUI的問題を除きCEGTestのバグはこれだけだと思います。したがって、「制約MASKは使用しない」という対策が一番楽だと思います。
ただ、テスト技法のエキスパートの方は、あえて、制約MASKを使用して、デシジョンテーブルに「M」が出現した列についてテストしてみることをお勧めします。
以前のnoteで、「実行不可（Infeasible）」と「テスト不可（Untestable）」について書きました。実行不可の例を原因結果グラフで言えば、以下のケースとなります。
「E ＝ A ∨ B」で、AとBに制約ONEがかかっていますので、AとBがともにFのケース（AとBがともにTのケースも）は制約ONEによって実行できません。これを「実行不可能」といいます。
一方で、先のMASKの例は、CをT（True）にするテストですから、実行はできます。（おそらく、原因ノードAとBは画面から消えるか、インアクティブ（操作不能）のGUIアイテムとなっていることでしょう）
CをTにしたときに、結果ノードであるEがどうなるか#4, #5列のテストをしてしまえばよいのです 。結果はどうなるか分かりません（結果がわからないことを“テスト不可能”といいます）が、テスターは結果がユーザーに受け入れられるものかどうかでテストケースの合否を判断します。
「実行不可能」と「テスト不可能」の違いについて少しずつわかってきたのではないかと思います。
テスト不可能の方は、「未確定なノードのため、テストを実行しても結果の正しさの判断ができない。」ということです。
上記は、何度か出ているX-CEGツールです。こちらをつくるときには、「テスト不可能」（カバレッジ表では「テスト不可能」な論理組合せを横2本線で表現しています）に対応し、“テストできないのだからデシジョンテーブルにも表示しない”という仕様にしました。
ちなみに「実行不可能」な論理組合せは、下記の制約ONEの例のように縦2本線で表現しています。
（カバレッジ表の1, 2, 3という数値は別の画面で論理式で確認します）
ということで、CEGTestには、上記のバグがあり、X-CEGには、そのバグはありません。
ただ、どちらのツールが良いかと言えば、「テスト対象の不具合を検出する」という意味では、CEGTestのほうが良いと思います。
なぜなら、CEGTestのバグを上手く使えば役に立つからです。
テストの目的のひとつは「テスト対象の故障を見つけて欠陥を直すことでテスト対象の品質を上げる」ことです。
であれば、X-CEGツールのように“テスト不可能”だからといってデシジョンテーブルを簡単化してしまうのではなく、デシジョンテーブルに残っていたほうがテスト対象の故障を見つける役に立つと考えるからです。
これが、このnoteのタイトルを「CEGTestの良いバグ」とした理由です。
≡ おわりに
今回は、「CEGTestの“良い”バグ」についてでした。
明らかに“バグ”なので直してほしいと思いますが、X-CEGのように「テスト不可能」を表示しないようにデシジョンテーブルを簡単化するのではなく、テスト不可能の列を残しつつ、テスト不可能であることが伝わるように直してほしいです。（カバレッジ表の方は、X-CEG形式で良いかもしれません。）
さて、今回で、CEGtestのパートは完結です。
次回は箸休め回とし、その次は、「ソフトウェアテストしようぜ」は休載にして、別の連載を始める予定です。いいかげん、「何とかしなくてはならないやつ」を始めたいのです。
