第226回： 「ソフトウェアテストしようぜ」39 CEGTest（9. 制約とは何か）
◀前の記事へ 次の記事へ▶
≡ はじめに
前回（箸休め回でない連載のほうの前回）は、「CEGTestツールの使い方」の後編で、CEGTestツールを使用して原因結果グラフをつくるまでの操作の説明でした。前回の内容の理解度の確認は、「おわりに」に書いたものを整理し直した以下のまとめ（4は説明していないので3まで）を読んで、「そういうこともあるかもしれないなあ」と書いている内容を読み取れたらOKです。（なにいってるか分からないというかたは前回を読み直すことをお勧めします。割と重要なことが書いてあるので。）
原因結果グラフの作成は、（例外はあるにせよ）基本的に、以下の手順で作成すると良いです。
1. 「大きな論理構造」を結果ノードから遡るようにしてつくる
2. 最左端の原因ノードが抽象的なものであれば、それを「同値分割」してクラスに分割する
3. 追加した原因ノードに対して「制約(ONE, EXCL, INCL)」をつける
4. 全体を見て「制約(REQ, MASK)」をつける
（私の経験則ではありますが、20年以上これでやってきたお勧めの方法です。）
ここまでの8回で、CEGTestツールがあれば「仕様書から原因結果グラフを作成して、デシジョンテーブルを生成する」ができるようになっているはずです。
そして、デシジョンテーブルを見ながら試行錯誤を繰り返せば、原因結果グラフのリファインができるようになっているはずです。
まずはそう言う使い方で半年くらい実際のテストへ使ってみる期間が必要です。
※ 少なくとも私は、そんな実験（トライアル&エラー）を1年くらい繰り返して、コツを掴んでいきました。コツとは、例えば、「結果から作っていく」などこの連載で書いていることなので、皆さんのトライアル&エラー期間はずっと短縮できるはずです。と言いますか、そのために書き残している感じです。
『ソフトウェアテスト技法ドリル』に書いたこともだいたいここまでです。改訂版の赤ドリル本でも大筋の変更はなく、あとは「CEGTestを使って慣れろ！」という感じで「CFD法」の話題に移っています。
でも、noteは紙幅の制約なく書けますので、前回までを初級編として、中級編にうつります。
CEGTest中級編のメインはドリル本に名前しか出てこない「カバレッジ表」になるのですが、その前に5つの制約について書きます。
原因結果グラフに補助的に付ける制約ですが、上記のドリル本では、各制約を「原因結果グラフ」、「ベン図」、「取りうる論理組合せ表」の3点セットで説明しているのですが、「取りうる論理組合せ表」について誤解を与えていたようですし、その辺もちゃんと文章として書いておきたいと思っています。
≡ 制約とは
上に、「原因結果グラフに補助的に付ける制約」と書きました。「はじめに」の手順に書いたとおり制約の付与は、ステップ3と4です。原因結果グラフのメインはステップ1の「「大きな論理構造」を結果ノードから遡るようにしてつくる」です。ところが、制約を上手く使うと、テスト実行をしやすいデシジョンテーブルが生成されます。特にデシジョンテーブルを読み込んで自動テストをしている場合、制約を正しくつけることができないと、テストができません。
■ 制約の辞書的意味
まずは、国語辞典をひいてみます。
せい‐やく【制約】〘名〙
①（━する） 条件をつけたり枠をもうけたりして、活動の自由を制限すること。制限。束縛。〔改訂増補哲学字彙（1884）〕
②哲学で、物事の成立や生起に必要な条件または規定。
要は、「制約条件を付けて動きを制限する」ってことです。
■ 原因結果グラフに制約をつけるとうれしいこと
ドリル本にはこう書きました。
原因結果グラフに制約を追加することで、仕様から論理的にありえない組合せがデシジョンテーブルに出現しなくなります。逆に言うと制約が正しく効いていることの確認はデシジョンテーブルでは確認できません。制約自体のテストを追加してください。
要は制約を付けると、「あり得ない組合せがデシジョンテーブルにでなくなる」ということです。
デシジョンテーブルを使って、ある列（ルール）のテストを実施している場面を思い浮かべてください。
セルの通りに値を設定しようとしたら、「その設定はできません」となったら、「設定できないことはバグなのか？」それとも「制約があるので設定できないようになっている正しい動き」なのかを調べないとなりません。
その結果、テスト実行中に調査という余計なタスクが入り、スケジュール通りにテストが進まなくなります。
また、調べた結果、バグならバグ票を起票して終わりですが、「制約による正しい動き」だったときがやっかいです。
というのは、その列（ルール）では制約の組合せ以外の組合せもテストしているから削除した列でテストしているロジック（条件の組合せ）をカバレッジ表で確認してテストを追加する必要があるです。
※ CEGTestであれば、網羅基準はMC/DC 100%です。列（ルール）ごと削除して追加テストをつくらなければ、その列でテストしようとしていた制約に関係のない条件の組合せのテストが漏れてしまい、網羅基準のMC/DC 100%はどんどん落ちてしまいます。これでは何をテストしているのか分かりません。
そこで、CEGTestでは制約を回避しながら組合せをつくり、網羅基準のMC/DC 100%を実現しています。
ここまでは制約を付けることの正の側面です。
さて、制約の負の側面としては、「制約の組合せがデシジョンテーブルに現れないために、制約の組合せをユーザーが入力しようとしたときに働くエラー処理（フールプルーフ）がテストされない」があります。
そこで、ドリル本の後のほうに書いている「制約が効いていることのテストを追加する」ことが大切になります。
制約が効いていることのテストをしないと、例えば、条件Aと条件Bに「両方同時にONにできない」制約を実装したあとに、追加で機能実装した条件Cに対して、条件Aと条件Bと条件Cの制約の実装に失敗して、例えば「条件CがONの時には、条件Aと条件Bが同時にONになる制約が効かない」といったバグをつくってしまうことがあるのですが、その手のバグを見つけることができません。
※ このバグをテストで見つけるには、制約条件の全組合せテストを実施します。
なお、制約条件がどこにあるかを想定せずに広く浅くテストしたいときには、強度3の直交表、あるいは、オールトリプルで組み合せテストをすることで見つけます。
■ 制約の種類
原因結果グラフの制約は、CEGTestのツールバーにある、「NODE」、「ONE」、「EXCL」、「INCL」、「REQ」、「MASK」、「／」の7個のボタンのうち、「ONE」、「EXCL」、「INCL」、「REQ」、「MASK」の5つ（原因結果グラフの制約は5種類）です。次回からこの5つの制約の使い方について詳しく説明します。
今の段階では雰囲気で使って「えー、何でそうなるの？」を繰り返すのがよいです。
私は未だに「何でそうなる？」って思うことがあります。一発で完璧な原因結果グラフを作ることなんて簡単なもの以外無理です。だって、原因結果グラフは複雑なロジックのモデル化ですから。
■ 制約と禁則
「制約」と似た概念に「禁則」があります。
近頃は「有則」と「無則」の方が有名になってしまったかもしれません。
「禁則」は「制約」の厳しい版だと思ってください。ソフトウェアテストではHAYST法が「禁則」って言い始めました。
「禁則」が生まれたきっかけは、大きな直交表に、プリンタドライバ上の設定項目を因子・水準として、割り付けて組合せ表をつくったら、そのほとんどが実行できなかったことです。（「ハガキは両面印刷できない」というような制約が山ほどあったのです。）
手作業ならともかく、データ駆動の自動実行では致命的です。
そこで、当時、「同時に組合せが取れない条件」のことを「禁止の規則」という意味で「禁則」と名付けました。
コンピュータ組版やワープロでの文章作成の際に、句点や読点、閉じ括弧などを行頭に置かないなどの規則も禁則と言いますが、その禁則ではありません。
上記の用語定義の通り、私たちが名付けた「禁則」は「機能」です。機能なので、「仕様書に禁則の仕様を書いて、ユーザーが禁則に引っかかる条件の組合せを入力しようとしたら、その入力ができない機能（例えば、片方を入力したときにもう片方を入力出来ないように不活性にする機能など）」が必ず実装されていないといけません。
制約のほうは禁則よりも広い概念なので、「ユーザーが設定しようとしたときに、入力できないことが機能として実装されていなくても良い」です。
例えば、マニュアルに「ハガキは両面印刷できません」と書いてあったら、それは、「制約」です。
「禁則」の場合は、「出力用紙サイズをハガキとした場合は、両面印刷をユーザーが設定することができないフールプルーフ機能」を実装する必要があります。
※ このことによって、「禁則」の場合は、「禁則が効いていること」をテストすれば、その先はテストしなくてよくなります。「禁則」によって、その先の分岐が無くなるので、実装とテストが不要になるからです。
ところが、「制約」で設定制限機能が実装されていない場合は、その制約を他の様々な機能と組み合わせてテストをする必要があります。
※ ところで、「禁則」の英訳はHAYST本の通り、「Constraint」（制約、制限（事項）の意味）なんですよね。対応する英単語がなかったので、一番近い意味を持つ「Constraint」を選んだのですが、今思えば「Kinsoku」にしておけばよかったです。それほど重要な概念で、「禁則」にまじめに取り組むと、開発やテストの効率アップとソフトウェアの品質向上に貢献します。
≡ おわりに
今回は、「制約」の全体説明でした。
次回から、「ONE」、「EXCL」、「INCL」、「REQ」、「MASK」の5つについて、この順番で3回に分けて説明します。
結果から言うと「MASK」以外はテストの削減（デシジョンテーブルの簡単化）にはほとんど効果はありません。さらに「MASK」を使いこなすのはかなり難しいです。
そこで、実務上は、「EXCL」と「REQ」の攻略を重点にするとよいです。
ということで、次回は、1番簡単で分かりやすい[ONE]について書く予定です。