第223回： 「ソフトウェアテストしようぜ」37 CEGTest（7. CEGTestツールの使い方 中編）
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は、「CEGTestツールの使い方」の前編で、「起動方法」と、全体を通して知っておくとよい、「モード」と「メッセージ」について書きました。
「起動方法」と「モード」と「メッセージ」さえ知っていれば、あとは、適当に触って試行錯誤しながら覚えるのが早いんじゃないかなと思います。
“CEGTestツールは、画面上方にある「NODE」、「ONE」、「EXCL」、「INCL」、「REQ」、「MASK」、「／」の7個のボタンを押すことでモードを変更するとともに、凹んだボタンが「自分がどのモードにいるか」を表している”ということだけ知っていれば、あとは勘で何とかなります。
でも、一通りの手順を体験しておくと無駄な試行錯誤をしなくて済むのではないかとも思います。
そこで、例題を解く過程を共有することで「CEGTestツールの使い方」について経験してもらおうとしています。
だから、本noteをPCでお読みのかたは、一緒にツールを試してみると、CEGTestツールの使い方を効率よく習得することができるんじゃないかなと思います。
「CEGTestツールの使い方」を一度マスターしてしまえば、もうテストの仕事でデシジョンテーブルを手書きでつくろうとは思わなくなるかもしれません。
※ 私は、よほど小さなデシジョンテーブル以外は、いつもCEGTestツールを使っています。そして、“小さなデシジョンテーブルをつくるくらいなら、つくっている間に全組合せをテストするほうが良い”とも思っているので、「テスト用のデシジョンテーブル」のほとんどは、CEGTestツールを使ってつくっています。
※ 仕様書に書くデシジョンテーブルは、多くの人にレビューしていただくために前提知識が不要で、読みやすいということが大切です。
ここで、デシジョンテーブルに加えて原因結果グラフをセットにして仕様書に記載しても仕様書のレビューア全員が、原因結果グラフを理解しているわけではありませんので（読みやすくなる）効果は薄いと思っています。
また、（デシジョンテーブルの簡単化やCEGTestツールのアルゴリズムにより）テストしないルールについても、そのようなルールであることを仕様書にわかりやすく明記する必要があります。
そのためには、簡単化後のデシジョンテーブルではないほうが良いと思っています。（巨大になるものはデシジョンテーブルを分割することで読みやすくしています。）
以上のことから、「（開発の）設計仕様書に記載するデシジョンテーブル」のほうは、Excelなどでつくるようにしています。
≡ CEGTestツールを使ってみよう
それでは、（前回提示だけした）例題を解きながら、CEGTestツールに慣れていただこうと思います。今回の例題では、まだ説明していない多階層で、しかも、制約もでてくる原因結果グラフがでてきます。
ひょっとしたら、「厳密な説明がほしい」と思う人もいらっしゃるかもしれません。でも、今回は、CEGTestツールを使ったテスト分析・設計の全体の流れと、雰囲気だけわかってもらえればよいので、深くは立ち入りません（詳しい話は、のちの連載のなかで書きます）。
それでは、Let’s get started!
■ 例題（再掲）
前回の例題を再掲します。
例題：
JaSST nanoという無料のオンラインイベントに参加するかどうかの意思決定について、デシジョンテーブルを作成しなさい。
■ 例題の分析
まずは、例題の意味を理解する必要があります。
と、えらそーに書いていますが、私は、子供のころにいろいろな人から何度も「問題文をよく読め」と言われて育ちました。
CEGTestを使うときには、分析もツール上でしています。ということで、まずは、CEGTestツールを立ち上げます。
起動方法は、前回書きましたが簡単です。パソコンのブラウザから、「CEGTestツールへのリンク」(https://softest.jp/tools/CEGTest)をクリックするだけです。
リンクをクリックするとこんな画面が開きます。
CEGTestツールが起動したらまずやることは、原因結果グラフを描くスペースを確保するために、画面に開いているマニュアル（ヘルプ画面）を消すことです。具体的には「✖ 閉じる」ボタンを押します。✖マークが赤くなっているので、見つけやすいですね。
なお、閉じたヘルプ画面は[ヘルプ]メニューから[ヘルプ]を選択することで、いつでも再表示できますのでご安心ください。
これで、原因結果グラフを描く準備が整いました。[NODE]ボタンを押して「ノードを入力するモード」にします。（ボタンが凹んでいることでモードがなにになっているか確認できるのでした。）このような画面になります。
いよいよCEGTestツールに入力しながらテスト分析です。例題を再掲します。
例題：
JaSST nanoという無料のオンラインイベントに参加するかどうかの意思決定について、デシジョンテーブルを作成しなさい。
原因結果グラフをつくるときに、私は、1番初めに仕様から【最終結果】を探します。「決定（ディシジョン）したいことは何か？」が【最終結果】となります。（デシジョンテーブルを生成したいということは、何の決定・判定を行う表を作りたいということだからです。）
最終結果が複数になる仕様もあります。
その場合、複数の最終結果を持つ１つの原因結果グラフをつくることも出来ます。
でも、とても分かりにくいデシジョンテーブルになりがちなので、初めのうちは、最終結果ごとに別々に原因結果グラフを作ることをお勧めします。
この例題で決定したいことは、「JaSST nanoに参加するかどうか」（「参加する／参加しない」のどちらに決定するのか？）です。そこで、ツールに「参加する」というノードを追加します。
「参加する」ではなく、「参加しない」を結果ノードにすることもできます。しかし、否定形を結果ノードにすると、論理を考えるときに面倒になります。
また、できあがった原因結果グラフも読みにくいものになります。
したがって、結果ノードの名前については、肯定形の「参加する」のほうが良いです。
※ 「懐中電灯が点かない」など、そもそも、調べたい結果が否定形の場合は、否定形のままにすることもあります。
原因結果グラフでは一番右側に「結果ノード」を配置しますので、上図のように、画面の右側のスペースをクリックしてノード名を入力して[Enter]を押します。（CEGTestツールが期待している使用者の入力は、画面上部の「メッセージ」ボックスに表示されます。操作に迷ったらメッセージボックスを読むと良いです。あと、変になったと思ったら、ESCキーを押すとかモードを変えるとかします。
つくった原因結果グラフはブラウザを閉じると消えてしまいますので、CSVファイルに保存していないときには何とか困った状況から復帰したいものです。）
ノード名を確定すると、ノードが完成し、「デシジョンテーブル」と「カバレッジ表」が現れます。何もしていないのに、2つの表が出てくるので、びっくりしますが、今はスルーしてください。
上記のとおり、今のところスルーして良いのですが、デシジョンテーブルをよく見ると「参加する」というノードが「原因：」となっています。これは、原因ノードであることを示しています。
「結果ノードを入力したつもりなのに……。」と疑問に思う人がいらっしゃるかもしれません。
実は、ノード間の関係を表すリンク（線）を引いて初めてそのノードが原因ノードなのか、結果ノードなのかが決まります。
今は「原因ノードに仮決めされている」と思ってください。
追い追い慣れてきます。
さて、結果ノードが「参加する」で確定し、入力も完了しました。次は、原因ノードの入力となります。今回の仕様は、「JaSST nanoという無料のオンラインイベントに参加するかどうかの意思決定」としか書かれていませんので、自分で「参加する」にいたる原因（条件）を考えるしかありません。
実際の仕様書には、原因（条件）について書いてあるだろうと思っている人が多いと思います。
ところが、実際には要件一覧表に顧客が求めていることが書かれ、仕様書にシステムの機能や動作が書かれていることが多く、要求と実装する機能との関係性が明記されていないことが多いです。
たとえば、大型の複合機は、割り込みプリントを行うため、“プリンターのジョブを並び替える”という要求を持つことがあります。
この要求は単純なものに見えます。ところが、よく考えると【さまざまな条件】が重なったときに初めて使うことができるようになっています。
分かりやすい条件を挙げれば、「管理者としてプリンターにログインしていること」でしょうか。この条件が“ジョブの並び替え”要件に書いてあれば、テストをつくるのも楽なのですが、要求仕様書の離れたページにある「ログインユーザー種別と実行可能な機能一覧」という表の当該機能のセルに☑️が付いているだけ、、、ということも多々あります。
他にも「ジョブ数が単数のときやプリント中のジョブの並び替えは出来ない」といった「そんなこと常識だろう？」という条件も要求仕様書には書かれません。書かれないということは、テストをつくる人がその常識を知ってテストする必要があると言うことです。
なぜなら、仕様書に書いていないので、開発者がプログラミングするときにその条件を見落とすことが多いからです。
と言うことで、原因結果グラフもはじめのうちは論理とか制約が気になるのですが、そこをクリアすると今回のnoteに書いているテスト分析で条件を洗い出すことが肝心なんだなとしみじみ思うようになります。
ということで、仕様書に条件がまとまっていない場合には、要件と機能の結びつきについて、自分で分析して、原因結果グラフをつくる必要がありますので、今回と大差ありません。
清水吉男氏の「USDM」という要求仕様記述フォーマットを使用しているプロジェクトでは、要求の理由を書く欄があったり、要求を仕様グループ化して仕様に分解していますので、わりと要件と機能の結びつきについて明確になっています。“わりと”と限定しているのは、USDMのExcelフォーマットを使用していても、使いこなせていない組織が多いからです。
それでは、原因（条件）について考えていきます。まずは、CEGTestツールの画面の左側に「JaSST nanoに参加するかどうかを決める要素（原因）」を、思いつくままに、ノードとして列挙します（マインドマップツールを使っても良いけれど、ツールを行き来するのは面倒なので、私はCEGTestツール上で行っています）。原因ノードの肯定・否定については、今は考えません。
原因ノードの否定とは、たとえば、「参加する」が結果ノードなのに、「○○で頭がいっぱい」といったような「参加しない原因」のことです。
定量的に立証できるかなどについても深く考えずに思いつくままに列挙します。
例えば、こんな感じになります。
原因として思いついたことを順不同で列挙しただけですから同じようなものも挙がっています。
このままでは、14個という多数の原因ノードを持つ原因結果グラフ（デシジョンテーブルは、2の14乗なので、16,384列！）をつくらないとなりませんので、似た要素をまとめていきます。
KJ法をご存じでしたら、その要領です。
KJ法の話が出たので、川喜田二郎先生の「探索の五原則」を思い出しましょう。
1. 360℃の視角から
2. 飛び石伝いに
3. ハプニングを逸せず
4. なんだか気にかかることを
5. 定性的にとらえよ
の5つです。特に最後の「定性的」が重要です。
探索の段階で「定量的」にこだわって、「こんな原因なんて少数だから」とか「これはデータを取りにくいから」と原因ノードを排除してはいけないということです。
その原因が本当に少数であったとしても、その原因と同じカテゴリの原因は多いかもしれません。また、思考に制約をかけると脳が委縮して良い発想がでてこないからです。
※ ちなみに探索的テストをするときにも上記の五原則を守るといいです。
まとめるといっても、似たノードを近くに集めてグループをつくり、そのグループに名前をつけるだけです。
ノードを移動するためには、前回でてきた「編集モード」に切り替える必要があります。凹んでいる[NODE]ボタンを押して、何も押されていないモードにすればノードの移動準備は完了です。
原因をグループ分けすると、こんな感じになります。
こちらで、十分にわかりやすいと思いますが、全体の構造部分についてマインドマップで描いてみます。（くどいですが、私はいちいちマインドマップは描きません）
このように、テスト分析を進めると、原因結果グラフの輪郭が見えてきました。
「要求の構造が見えてきました」、あるいは、「要求のモデル化」と言うべきかも。
≡ おわりに
今回は、「CEGTestツールの使い方」の中編でした。「テスト分析」をしたということです。
次回は、原因結果グラフを完成させます。今回最後に出てきたマインドマップを骨格として、原因を配置し、そこに論理関係と制約を追加すれば原因結果グラフの完成です。今回のテスト分析と対比させると、次回はテスト設計となります。