テスト設計をする際には、テスト技法を使うことで、効率的に効果的なテストケースを作ることができます。今回、本稿で紹介する技法となる「順序組み合わせテスト」と「波及全使用法：IDAU法」は、バージョンアップ開発や派生開発などで、テスト対象に変更が入ったときに役立つテスト技法です。これまでの7回の連載では、前半の4回はこの技法の特徴や具体的な使い方を湯本から紹介し、連載の後半では、後続研究として取り組んだCode Based IDAU法(CB-IDAU)とグラフ特徴量バグ予測モデル(GMT)を武田から紹介しました。
連載の最終回である今回はすこし話を変えて、この技法を今後どうしていくとよいのかを武田と湯本の対談でお伝えしたいと思います。
スクリプター：武田 友宏(たけだ ともひろ)のプロフィールはこちら
これまでの７回の連載を終えて
湯本：武田さん、今回はIDAU法の連載に協力してもらってありがとうございました。連載を通じて、私も改めて武田さんの研究成果を見直す機会になったので、とてもよかったです。武田さんはどうでしたか？
武田：論文で書いたことを要約しつつ、わかりやすく読者の方々に伝える機会ができて、自分の頭の中を整理できたのでとてもよかったです。ありがとうございました。
湯本：今後の展開について話すのが今日のテーマなのですが（笑）。私は、IDAU法はバージョンアップ開発や派生開発などで、テスト対象に変更が入ったときに役立つテスト技法として研究しましたが、一番の想いは、現場で多くの人に適用してもらいたいことであるため、ツール化して汎用的に使えるようにできないかなって思っているんです。武田さんが後続研究でテーマにしたCB-IDAUなんかは、ツール化して汎用的に使ってもらうのがやりやすいんじゃないかなって思っています。武田さんはどう思いますか？
武田：実は、私がCB-IDAUについて研究していたころと事情が異なってきていると思っています。最近ではChatGPTのようにすでにプログラムやコーディングパターンを大規模言語モデルとして学習済みのAI技術が出てきたので、CB-IDAUのようなテストは、うまくプロンプトを書けばできるのではないか？と思うようになりました。プログラムを学習済みの大規模言語モデルを使うことで、そもそも誰でもコードがプロンプトを使って簡単に作れるようになりました。なので、テストコードも同様に作れます。コードがあり、そこに対して一定のルールベースでテストを導き出すだけのことであれば、もはやAIのほうが確実に作れます。わざわざ人間がやるような時代ではなくなるのではないかと思います。
セマンティックなテストは人間が行なわなければならない
武田：ただし、システムテストで行うリグレッションテストをAIに学習させて良いテストが作れるようにするのは今後も可能性を感じます。セマンティック（データの持つ意味をコンピュータに理解させ処理する技術）なテストには人間が入れる余地が十分にあると思います。湯本さんとしては、IDAU法を今後どのように広げていきたいのですか？
湯本：IDAU法に基づいたテストケースのパターンが導き出せるツールが作れると良いと思っています。状態遷移モデルを描くとスイッチカバレッジのパターンを出してくれるようなツールがあるのですが、そのIDAU法バージョンのようなものです。
武田：それは、ソフトウェア設計者が作成したDFDをベースにするようなイメージですか？
湯本：私のイメージは、システムテストをテスト設計する際にモデリングするようなイメージです。そして、単なるDFDではなく、CRUDの情報も付加できるように拡張したモデルにして、テストに必要なCRUDのパターンが導き出せるようにしたいです。
ソースコードからリバースして確認する
武田：Code Based IDAU法(CB-IDAU)がソースコードからIDAU法の考え方に基づくテストパターンを生成する方法ですので、ソースコードからリバースしたパターンと湯本さんが話している方法で生成したパターンを比較して確認するのはどうでしょうか？そこで差異があれば、それはバグなのではないかと考えられます。
湯本：なるほど、いいところに目をつけていますね！それは、実はデシジョンテーブルで同様の先行研究があります。筑波大学大学院の研究室で私や武田さんの先輩にあたる植月さんの研究がまさにそれで、”An Efficient Software Testing Method by Decision Table Verification”という論文にて、研究成果を発表しています。
武田：コードからのリバースはどのような方法で実現しているのですか？
湯本：コンコリックテスティングです。
武田：なるほど。全パス解析をして、そこからデシジョンテーブルを作るのですね。
湯本：そうです。何か良い説明資料はないかな？（グーグルで検索をする）あー、植月さんがJaSST（ソフトウェアテストシンポジウム）で講演している資料で「はじめてのコンコリックテスト」というのがありますね。研究の内容も要約して説明されています。
武田：ありがとうございます。また後でしっかり読んでみます。このような話を自分で切り出しておきながらあえて言うのですが、課題が二つあると思いました。一つは、仕様から導いたパターンと、コードからリバースしたパターンでは途中経過で多くの設計行為が入り、単純に同じにならないので、比較が難しいと思うということです。もう一つは、コードからリバースしたらパターン数が爆発するので、絞り込みルールが必要になるということです。
湯本：まず、パターンの爆発に関しては、それを防ぐために最初に機能セット（feature set）を特定するようにしています。IDAU法は、データアクセスに対する順序性でパターンを作るので、変更が入ったタスク群、つまり先行の立脚点になるタスクが含まれている機能セットを選んで、その後に波及するタスク群、つまり後続の選択肢となるフィーチャーが洗い出されるので、選ばれるコードも絞り込まれます。絞り込まれることによって、爆発は防げるはずです。また、比較が難しい件に関しては、デシジョンテーブルで行った先行研究でも全く同じ課題はあるので、先行研究の中に解決の鍵があると思っています。
武田：コードからリバースする場合なのですが、選ばれるコードを絞り込む際に、入力のデータセットとエンティティとの関係を洗い出さないといけないと思います。コードレベルになると、現実的にデータセットがそのまま一つのエンティティに入るわけではなく、一部はここ、もう一部はここというようなロジックが複雑に入るので、入力のデータセットとエンティティの関係に対する解析が必要です。
湯本：確かに。画面から入力した情報がデータベースに書き込まれるときに、画面とエンティティが１対１のような関係になることは稀ですね。マイクロサービスアーキテクチャーのような構造だとさらに複雑な関係になることも十分考えられます。最初から全部いっぺんに解決できる方法を頭の中だけで考えていくのは大変だから、ステップ切って少しずつ試していかないと解決策見いだせなさそうですね。
武田：データの遷移（１カラムのデータに対する処理の順番）に絞ってスモールスタートでプロトタイプ検証していきたいです。
湯本：ぜひやりたいですね。データのCRUDレベルで変更が入ったときの影響範囲は、確実にテストできるようにしていきたいです。このレベルのバグは重篤度（Severity）がCriticalになるものが多くいからです。
まとめ
今回は、順序組み合わせテストとIDAU法というテスト技法について説明をする連載の最終回目として、武田と湯本でIDAU法の未来を話し合う対談をさせてもらいました。この後は、「このようなツールを作るとしたら、資金調達しないといけない」という話になり、世の中では、このようなことを実現したい時にはどうやって資金調達するのかといったビジネス的な話で盛り上がりました。
以上で連載は終わりになりますが、今回の対談にあるような研究を継続し、またどこかで成果を発表できるようにしていきたいと思っていますので、そのときをぜひ楽しみにしてください。
第1回：バージョンアップ開発や派生開発のときの影響範囲をテストしていますか？
第2回：バージョンアップ開発や派生開発のときの影響範囲をテストしていますか？
第3回：バージョンアップ開発や派生開発のときの影響範囲をテストしていますか？
第4回：バージョンアップ開発や派生開発のときの影響範囲をテストしていますか？
