原因結果グラフ法が扱う制約関係
以上、ここまでOne制約と、Mask制約の2つを説明してきました。ほかにどのような制約があるかは表にしてありますのでそちらを参照してください。すでに説明した2つが理解できていれば、ほかの制約の理解は難しくないはずです。
表に示してある制約はNeoCEGでサポートされているものです。原因結果グラフ法の原典などにあたると、ほかの種類の制約も示されていることがあります。ただ、それらの制約は使わなくても、ここに示した制約だけを使って同じことが表現できるので、この範囲で表現するほうが使いやすく、理解しやすいと思います。
原因結果グラフ法が定義する制約とは、基本的にここに示したものだけですが、設計で扱わなければならない制約をこの範囲でかなり表現できるので、十分な表現力を持っていると言えます。
制約関係というと制限事項のことを思い浮かべてしまうかもしれませんが、それだけではないことをご理解いただけたのではないかと思います。もちろん、制限事項の多くもこの表現を用いてモデル化できるので、必要があれば活用するとよいでしょう。
論理の複雑さを縮減するために、論理関係と制約関係（それを実現するアーキテクチャ）をうまく組み合わせる。この視点を意識的に持つと、そのような例はすでに身の回りに多数あることに気づきます。GUI部品や画面遷移の例を紹介してきましたが、ほかにも簡単に思いつくものだけでも図に示したようなアーキテクチャが使われています。その制約関係は原因結果グラフ法に用意されている制約関係で十分モデルに表現可能なものばかりです。
原因結果グラフ法は必要なテスト数を劇的に減らすので、テスト設計技法として知られるようになりましたが、筆者は論理とアーキテクチャとの境界線の整理・設計にこそ活用すべきだと考えています。十分に整理してからコード化することで、スパゲッティ化を防ぎ、シンプルなコードを実現することができるはずです。
制約関係を含む場合もAI活用方法は同じ
制約関係の意味がわかったところで、それもグラフに描き込まなければならないのは大変だと思われたかもしれません。確かにそうなのですが、これもAIに頼めばだいたい間違いのないものを描いてくれます。
実際のやり方を紹介します。先に保険の申込みの画面を示しましたが、この模擬サイトと仕様を以下のページで公開しています。
これを題材にやってみましょう。やり方は前回と同じです。NeoCEGの画面右上の「？」をクリックしてダウンロードできる「NeoCEG_DSL_Grammar.txt」ファイルと、今度は仕様が定義されている文書のURLの2つを与えて、次に示すようなプロンプトで指示すると良いでしょう。
注意：模擬サイトには業務ルール仕様と画面仕様が示してありますが、必ず業務ルール仕様のほうを与えます。業務ルール仕様を原因結果グラフ法で分析・整理して、論理処理するところと制約で実現する領域の分担を決めます。そうすることで、業務ルール仕様を論理処理によって実現するコードのスケルトンとテストが得られます。制約関係のほうはそれを実現する方法を別途用意しなければなりません。これもグラフのDSLを渡してAIに頼めばやってくれます。そしてAIが提案してくれたのがこのサイトに示してある画面仕様です。つまり、画面仕様のほうはこの手法を適用した結果です。
いずれ今度は画面仕様も含めたテストも設計したいという段階が訪れることになると思います。そこでは制約関係を既知の、すでに決定済みのルールとして正しく扱うことができるペアワイズ手法やデシジョンテーブル手法を使うとよいでしょう。
そこはまた別の手法の話になりますので、今回は紙面の都合で説明しませんが、筆者も「NeoCombi」と名付けたツールを提供しています。AIの活用法も含めて使用法はNeoCEGに似ているので、よろしければご活用ください。
プロンプト
添付のURLに示される仕様について、原因結果グラフ技法でテスト設計を行います。原因結果グラフ技法はあなたもご存知のはずのソフトウェアテストの国際規格ISO/IEC/IEEE 29119 Part4の中にも示されているものです。
PlantUMLやMermaidのように、言語で表現すれば原因結果グラフを描いてくれるNeoCEGと呼ばれるシステムがありますので、あなたは添付ファイルのNeoCEG_DSL_Grammar.txtに示されている文法に従って言語表現してください。
原因間の制約では、条件付きで存在する項目、適用対象外となる項目、質問がスキップされる項目はMASK制約を優先し、単なる同時成立不可・必須関係だけを表す場合にREQやEXCLを使ってください。
AIが返してきたDSLをコピーしてNeoCEGを起動し、Fileメニューから「Paste CEG Definition」を選べばグラフが描画されるはずです。
こちらのサンプルと同じような図が得られるはずです。もちろん必ず正解を出すとは限らないので、レビューして修正する必要があります。コンテキストを新しくした上で複数回生成させて比較してみるのもよいと思います。
また残念ながら、現状のNeoCEGはグラフのレイアウト（ノードの座標）をあまりきれいに配置することができません。そこは人手で動かして見やすいものにしていただければと思います。
NeoCEGでは、論理関係、制約関係、グラフの情報がすべて、NeoCEG DSLのテキストファイルに表現されます。このファイルをGitなどの構成管理ツールに格納しておけば、版管理や差分確認が簡単で、いつでもこのファイルからグラフやテストケースを再現できます。グラフもGitなどで管理したければSVG（XML）形式で出力できます。
DSLは簡潔な文法規則に従っているので、余計な情報を極力省き、論理関係と制約関係について、人間が読む場合にも十分わかりやすいものにしてあります。
NeoCEGにはCLI版が存在します、簡単なラップでAPI化もできていますので、CI/CDパイプラインに組み込んで使えます。レビュー済みで確定したソースからテストケースを出力させ、テスト自動実行ツールにそのテストケースを自動で送り込むことが簡単にできます。
おわりに
「何を制約としてアーキテクチャ側に担わせたのか？」「それはどの程度確実に機能するべきか？」「アーキテクチャと論理処理の狭間に落ちるケースはないか？」──こういった視点で扱う問題を吟味したり、検証方法を検討したりすることが、品質向上のためには必要です。そのような際に、原因結果グラフはとても役立ちます。
制約は、制限や禁止といった厄介なことばかりなのではなく、うまく活用すればコードの複雑さを減らしてくれる有益なものでもあるのです。
NeoCEGではグラフによるモデル表現と簡潔な文法規則に従った言語表現を、完全に一致させています。人間同士のレビューの場だけではなく、人間とAIとの間で合意を明確にすることにも効果的に活用いただけます。ぜひ試してみてください。
