第217回：　「ソフトウェアテストしようぜ」31　CEGTest（1. ペアワイズとの違い　前編）

2023年2月26日 06:38

◀前の記事へ　 次の記事へ▶

≡ はじめに

前回は、「同時に複数の対策をとる意味」について書きました。前回のポイントは、「同時に複数の対策を実行してよい。できるならそうしたほうがよい」です。
さらに、『孫社長のむちゃぶりをすべて解決してきた～すごいPDCA』という本では、「毎日PDCAを回して、試した手段の効果を数値で評価する」という進め方を推奨していることを紹介しました。
ところで、同時に複数の対策を実行できるかどうかは、仕事の内容によります。本に載っていたセールス活動のように一日に何度もPDCAを回せる仕事もあれば、そうではない仕事もあるからです。ただし、抽象度を上げれば毎日同じことをしている箇所が増えるので、超短期のPDCAを意識して積み上げると良いのかもしれません。（そういうことはしたことがないので想像ですが）

さて、「ソフトウェアテストしようぜ」の連載に戻ります。
今回から始まる新しいお題は“CEGTest”（原因結果グラフ技法の面倒な作業をしてくれるツール）です。WEBアプリケーションなのでインストールの手間もなく、ブラウザからアクセスしたら無償で使える神アプリです。

私が1999年に会社に買ってもらった、Caliber RBTという原因結果グラフツール（Windowsアプリ）は80万円でした。
＃機能は、“CEGTest”のほうが良いです。

※　Caliber RBTですが、今はバージョンアップされて、Bender RBT という名前で販売されています。なお、Caliber RBTの前の名前は、”SoftTest”といい、私がアメリカにテスト設計リーダーに教えてもらったツールです。日本に戻って買おうとしたら名前が変わっていました。
※　そのテストリーダーは女性の方で、毎日、紙に原因結果グラフを描いて助手に渡す仕事しかしていませんでした。（助手は、手書きの原因結果グラフをツールに入力して、変なデシジョンテーブルができたら差し戻すのが仕事でした。完全な~~カースト制度~~分業体制で「これがアメリカのやり方か！」と妙に納得しました。
※　ちなみにSoftTestの源流をさらにたどれば、原因結果グラフや同値分割法をつくったIBMのWilliam Robert Elmendorf氏(1925/2/21 - 2006/8/31)のツールに行きつきます。（ざっくり言えば、メインフレームのテスト設計ツールがあって、それのPC版がSoftTestです）

原因結果グラフというテスト技法は、「聞いたことはあるけど、使ってはいない」という人が多いのではないかと思っています。
『ソフトウェアテスト技法練習帳』にも出てきませんし、『難しそう。デシジョンテーブルで間にあってる』と敬遠されがちなテスト技法です。

CEGTest関連で「凄い」って思ったのは、細谷さん（※）の事例です。（左記リンク先の発表に少し書いてあったので、該当する部分を下記に引用します）

開発者がTDDで書くテストコードをCEGTestで生成したデシジョンテーブルから自動的に作って走らせることで品質を向上したって話です。
CEGTestでつくった原因結果グラフにテストの意図が残るっていう点もポイント高いと思います。

※　細谷さんは『アジャイル同人誌UltimateAgileStories』でも有名なソフトウェアエンジニアです。尊敬しています。

話を戻します。

確かに、原因結果グラフは他のテスト技法よりは覚えることが多いです。また、ツールなしで原因結果グラフからデシジョンテーブルをつくるのは大変で面倒な作業です。
さらに、別の開発技術（例えば、ルールベースエンジンなど）を使うことよって、原因結果グラフの適用がはまる個所は減ってきています。

ルールベースエンジンとは、簡単に言えば、デシジョンテーブルを入力すると、デシジョンテーブルのルール（条件の組み合わせとアクション）を動かすプログラムを自動生成するようなものです。
例えば、複雑な「スマホの契約」や「勤怠処理」などのロジック部分の自動コーディングに役立ちます。開発コードは自動生成なのでコーディングミスの入り込む余地はありません。
ルールさえ間違えずに書ければ（つまりは、ルールのレビューをしっかりと行えば）そのロジックの動的テストは不要となります。

上述のとおり、原因結果グラフを使う場面は減ってきます。しかし、面倒なデシジョンテーブルの生成は、CEGTestというツールがやってくれますし、ルールベースエンジンを使わないケースのほうが多いですから、ソフトウェアエンジニアなら使えるようになっておいたほうが良いと思います。

≡ 原因結果グラフが好き

「一番好きなテスト技法はなに？」と質問されたら「原因結果グラフ」と答えます。ここでは、好きな理由について掘り下げてみます。

■ テストっぽい技法だから好き

好きな理由の1つ目は、一番テストっぽい技法だからです。ちょっと分かりにくいですね。

25年以上昔のこと。
私がまだ職業プログラマーだったときに作っていたソフトウェアは、ネットワークデバイスの制御をおこなうファームウェアでした。（C言語を使っていました）

当時の私は、割り込みとかそういうところで厄介なバグを量産？していました。まぁ、割り込みはプログラミング直後のユニットテストではテストしにくいので、仕方のない面もあります。

ところが、そういった複雑な個所でなくても、ユニットテストでバグを取りきることができず、自分のプログラミング力の低さにガッカリしていました。バグが発生しているところは、複数のif文で構成されるいわゆる「ロジックの実装」部分でした。ファームウェアなんて少ないメモリで高速に動かすこと以外は、値を代入したり、長いデータをフォーマットに従って分解したりする程度の単純な処理ですので、他にバグが起こりようがないということはあります。

当時の私は、プログラミング直後にユニットテストを行い、見つかったバグをデバッグして、「これで全てのバグを取り切っただろう」と思って、次の結合テストへ渡していたのですが、そこで、先の単純なバグが見つかっていました。

バグの原因は、「ユニットテスト漏れ」でした。ホワイトボックステスト技法の制御フローパステストも知りませんでしたので、命令網羅や分岐網羅も測らず、適当につくったものの動作を気になったところだけ確認していたので、今から思えば当然の結果です。

「自分がそうだったから今の経験不足のプログラマーもそうに違いない」と考えるのはとても失礼なことかもしれません。

でも、逆に、「5個程度のif文によって作られたロジックなら、どんな開発者でも、もれなくダブりなくユニットテストをするだろう」と考えるのは楽観的すぎるように思います。

■ 要件からハイレベル・テストケースをつくれるから好き

原因結果グラフを好きなもう一つの理由は、要件から原因結果グラフをつくることができる点です。

パースペクティブレビューが良いと言われて、要件や仕様から“ハイレベル・テストケース”を書こうとしても、何を書いたら良いか悩むのではないでしょうか。

そんなときに使ってほしいのが原因結果グラフです。

先にCaliber RBTやBender RBTというツールを紹介しましたが、両方のツールについている“RBT”とは、“Reqirements Based Testing”の略です。
初めから「要件を基にしたテスト」という位置付けなので、原因結果グラフは、要件や仕様のパースペクティブレビューにぴったりのテスト技法です。

実際に私が試したときにも要件や仕様の問題検出に役立ちました。

ということで、「原因結果グラフ」好きです。

≡ ペアワイズとの違いについて

原因結果グラフについて知るためには組み合わせテストとの違いを知ることが役に立ちます。

『BenderRBT Test Case Design Product Overview』というプレゼン資料があります。先に紹介したBenderRBTというツールの紹介資料です。

そのなかに技法を比較した表が載っていますので以下に引用します。

『BenderRBT Test Case Design Product Overview』 p.62

『BenderRBT Test Case Design Product Overview』 p.63

表の「Cause-Effect Graphing」が原因結果グラフの列で、「Pair-Wise」がペアワイズの列で技法の特徴の比較となっています。「X」はバッテン（ダメ）の意味ではなく、あてはまるという✅の意味です。
赤文字の行を見ますと、「observability of defects」（欠陥が見つかる）、「test coverage」（テストの網羅性）、「Can support Agile project」（アジャイルプロジェクトに対応可能）なところがセールスポイントのようです。

営業のための資料なので、眉唾なところはあるのですが、原因結果グラフを勉強してみようかなという動機づけになると良いと思って紹介しました。このnoteの連載が終わる頃には答え合わせができることでしょう。

それでは、シンプルな例題をとおして、原因結果グラフとペアワイズテストの違いをみていきましょう。まずは例題です。