「テストシナリオの洗い出しはむずかしい」多数寄せられる現場の声

「先日、SHIFTのテスト設計支援ツール『TD（Test Designer）』を使用している製造業のお客様から、『TDのシナリオテスト設計書機能が役立ちそうだ』との意見をいただきました。」

石井は講演の冒頭で、このように語ります。たしかに、製造業では複数のサブシステムが連携することによる複雑な状態遷移が発生しがちで、シナリオテストの重要性が高いと考えられます。

「ですが、重要性は高い反面、テストシナリオをつくっていくことは非常にむずかしいようです」と石井は語り、実際に「SHIFTでは、『テストシナリオの洗い出しを手伝ってほしい』というご依頼を多く引き受けています。

そのほかに、SHIFTが運営しているYouTubeチャンネルでも、『テストシナリオの洗い出しがむずかしい』というコメントをいただいたことがあります」とつづけます。

そもそも、シナリオテストは複雑で、SHIFTが標準化している方法でも以下の6つのステップを踏む必要があります。

• 業務プロセスの分解
• シナリオの整理
• テスト観点の検討
• シナリオとテスト観点の紐づけ
• パターンの洗い出し
• テストケースへの落とし込み

石井は、「特に、システム間連携や状態遷移の整理は、ベテラン設計者であっても難易度が高いものです。そこで、SHIFTでは、1～4のステップに生成AIを適用できないかと考えました」と説明します。

ベテラン設計者のようにAIが寄り添う──新ツールの全体像

今回の取り組みの概要を、下図にまとめました。

図のように、利用者は生成AIとのチャットを通じてテストシナリオを洗い出します。ベテランのテスト設計者と相談しながら、いっしょに洗い出しを進める感覚です。

本ツールの対象となるフェーズは、システムテストや受け入れテスト。支援可能な作業スコープは、業務フローとテストシナリオの洗い出しです。

「テストケースの作成については、支援の対象外となっています。テストケースは粒度が細かく、生成AIに作成させるとテストケースをテストするという本末転倒な事態が発生しかねないためです。

そのため、アウトプットの抽象度が一段階高いシナリオ分析を支援対象と定めているわけです」と石井は補足します。

SHIFTでは、本ツールの利用者としてテスト設計リーダー（第三者の立場からテスト計画やテストメンバーのアサイン方針を決める、テスト設計を熟知しているポジション）を想定しています。

テストシナリオの洗い出しは、もともと難易度が高く、ツールを使ったからといって素人が簡単に行えるものではないためです。

生成AIが投げかける質問に答えて、10個のシナリオを生成！

石井は「今回は、製造業での利用を想定して、スマートリモコンを経由して、アプリからエアコンを操作するというシナリオの抽出を、デモ操作でお見せします」とつづけます。

出力までの一連の流れは、上図の通り。青く色づけられている部分はAIの力を借り、「TD」を使ってテスト設計書に落とし込む作業は人間が行います。

白い吹き出しは、AIが投げかける質問です。青い吹き出しが、利用者の回答です。このUIは、普段チャットツールを使っている方にはなじみのあるものかもしれません。

「裏側の話を少しだけ。各フェーズのプロンプトは、シナリオテスト作成に精通したメンバーによって定義されています。この後の生成画面は非常に質の高いものになっていますよ」と、石井は自信をのぞかせます。

ステップ1では、テスト対象となるシステムの概要やテストの目的、テストに求める細かさなど、AIが把握しておきたいことを提示しています。

回答については、画面仕様書からそのまま抜き出してもかまわないといいます。

「今回は、一般的なスマートリモコンの機能を言語化して入力しました。仮に、画面仕様の言語化がむずかしい場合は、画面キャプチャをもとにほかの生成AIを使って言語化してもいいかもしれません。」と石井は説明します。

ステップ2では、シナリオテストを行う目的や範囲、検証が必要な異常系シナリオのカテゴリ（想定する障害）といった情報をAIが提示します。今回は、提示された内容で進めます。

ステップ3では、先ほど伝えた仕様からテスト対象のコンポーネント、テスト条件、周辺環境などをAIが分析し、提案します。

「今回は、スマートリモコン、アプリ、エアコンといった各コンポーネントに対し、通信条件や状態など、さまざまな条件でのシナリオが抽出されています。面白いのは、あいまいな部分をAIが説明してくれるように仕組まれている点です。」と石井は指摘します。

「例えば、上の画像では通信障害の状況定義、障害発生時のユーザーへの表示方法などを聞かれています。こうした細かな点を確認されるため、見落としにも気づきやすくなります」と石井は説明します。

さらに、ステップ4で「通信回復時はどのような状態になるか」といった不明点を聞かれた場合、「画面を開きなおせば最新の状態が反映されている状態」と要件を回答。

こうして質問と回答を繰り返していき、要件が矛盾している場合についてもAIが指摘します。

一連の質疑応答が終わると、ステップ5のフロー分析に移ります。説明した動作や処理をまとめてくれるので、その内容を確認し、OKであれば次に進みます。

すると、ステップ6で業務フロー図（Mermaid記法）が生成されます（上の画像はシナリオのみ）。今回は、10個のシナリオが生成されました。基本シナリオ、アプリ側のネットワーク障害、スマートリモコンのネットワーク障害などです。

システムの専門用語で書かれていて少し分わかりづらいので、ステップ7に進み「日本語で解説してください」と指示し、1シナリオずつ内容を解説させます。

この一連の7ステップを約30分で終え、10個のシナリオを作成できました。

シナリオの作成背景や説明などが言語化されているため、ドキュメント化してまとめておくと、後から「このシナリオはなぜ必要だったのか」「何をやったのか」を参照できます。

将来的に、本ツールはアプリ化を目指しています。フェーズを追跡できるようにしたり、プロパティ情報を確認できるようにしたりしていく予定です。

最後に、石井は「今回の取り組みで、客観性のあるシナリオを素早く洗い出せる未来が見えたのではないでしょうか。

経験豊富なテストリーダーでも数時間、若手なら数日かかるテストシナリオの洗い出しを30分で終わらせることができました。

これは、開発当初の目標であるシナリオを簡単かつ的確に整理してくれる、思いつかなかった観点を提示してくれる、スピーディーに対応できるといった期待値を大きく上回る結果です。

一見地味に見えるかもしれませんが、ベテラン設計者に相談しているような安心感があるのです。

『この仕様は考慮されていますか？』『矛盾はありませんか？』と指摘してくれるため、手戻りは大きく減らせると見込んでいます」とツールの有用性を示し、発表を締めくくりました。

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです）