はじめに
AIにテストコードを作ってもらうことは、すでに珍しくありません。
では、テストデータの準備から実装・デバッグ、ドキュメント作成、テストデータやテストケースの登録、テスト実行まで、テスト開発に関わる一連の作業をどこまで進められるのでしょうか。
この記事では、テスト自動化の学習用の練習サイト 宿泊予約システムのデータドリブンテストを題材に、コーディングエージェントへテスト開発の各工程を依頼し、実際にどこまで任せられるのかを実際の画面とともに紹介します。
なお、本記事では、UiPath Test Cloud環境で、UiPath Studioのコーディングエージェント「Studio Autopilot」を使用しています。
UiPathでは、UiPath SkillsとUiPath CLIを通じて、Claude Codeなどの外部コーディングエージェントから開発機能やプラットフォーム機能を利用することもできます。RPA開発を題材にその方法を紹介した@utanesukeさんの記事もありますので、興味のある方は以下をご覧ください。
Studio Autopilotとは？
Studio Autopilotには、自然言語で開発内容を指示できます。要件定義書や設計書、Test Managerの要件・手動テスト手順、既存のUiPathプロジェクト、対話で追加した情報などを、作業のコンテキストとして利用できます。
＜Studio Autopilotの機能構成図＞
図の左側は、Studio Autopilotへ与える情報と、作業に利用する機能を示しています。
Studio Autopilotは、UiPath Skills／CommandsとUiPath CLIランタイムを通じて、既存プロジェクトの理解・作成・編集・デバッグ、パブリッシュ、テスト作成・管理、ジョブやキューの操作などを行います。必要に応じて、PowerShell、ドキュメント検索、Web検索、接続済みのMCPサーバー上のツールも利用します。
中央は、コーディングエージェントとしての作業サイクルです。
計画 → 作成・編集 → 実行・検証 → 原因調査・修正 → 再検証
作業を分解して計画し、成果物を作成・編集したあと、実際に実行して結果を検証します。エラーが発生した場合は、Lint、ログ、セレクターなどを調査し、修正後にもう一度検証します。
図の右側は、作成・編集できるプロジェクト資産と、そのオートメーションによって操作・テストできる対象を示しています。
テストコードだけでなく、RPAワークフロー、Object Repository、依存関係なども扱います。作成したオートメーションは、Web、デスクトップアプリ、Microsoft Office、業務パッケージ、レガシーシステム、仮想化環境などの操作やテストに利用できます。
テストコードの作成後は、実際の画面でデバッグし、検出した問題を修正して再実行しました。
さらに、Studio内の実装だけでなく、UiPathプラットフォーム上のData Fabricへのテストデータ登録、Test Managerへのテストケース登録、ドキュメント作成まで依頼しました。
本記事では、作業内容と結果を分かりやすく紹介するため、テスト開発の流れを5つのユースケースに分けています。各工程の作業内容や完了条件を1つの指示書にまとめ、一連の作業として依頼することもできます。
それでは、各ユースケースを順番に見ていきます。
ユースケース1：要件からテストデータを作成する
最初に、Test Managerへ登録された要件とExcelテンプレートをもとに、データドリブンテストで使用するテストデータの作成を依頼しました。
要件とExcelテンプレートを用意する
Test Managerには、宿泊予約システムの概要、テスト対象となる機能、宿泊プラン、料金・割増条件、テストで使用するユーザー情報などが登録されています。
＜Test Managerに登録されたテスト要件＞
出力形式として、宿泊日数、宿泊人数、宿泊プラン、追加オプション、期待する合計金額などの列を持つExcelテンプレートを用意しました。
＜テストデータ用Excelテンプレート＞
Studio Autopilotへ指示する
Studioで対象のテストプロジェクトを開き、Excelテンプレートを添付します。
宿泊料金に影響する条件を網羅すること、実行日に応じて宿泊開始日を算出すること、料金計算パターンが分かる説明を付けることなどを指定しました。
マネーパスにフォーカスしたデータドリブンのテストケースを作成するため、HOTEL:229（宿泊予約の機能要件）を参照し、添付ファイルのテストデータを完成させ、Dataフォルダに格納してください。
テストデータは、宿泊料金の計算に影響する条件を網羅するように作成してください。
テスト実行時にテストデータの「宿泊開始曜日」の値から算出し、宿泊開始年月日は、実行日より後かつ3か月以内の日付とします。
予約を完了するために必要なログイン情報および予約者情報も、テストデータとして適切に設定してください。
各テストデータには、検証する料金計算パターンが分かるよう、テストデータパターンの説明を設定してください。
Studio Autopilotは、Test Managerの要件とExcelの列構成を確認し、指定された条件に合わせてテストデータを作成します。
作成されたテストデータ
Excelには、宿泊プラン、宿泊人数、宿泊日数、追加オプションなどを組み合わせたテストデータが入力されました。
＜自動生成されたテストデータ一覧＞
動画で実演
試して分かったこと
単にExcelの空欄を埋めたのではなく、Test Managerの要件から宿泊料金に影響する条件を読み取り、指定された列構成に合わせてテストデータを作成できました。
特に、宿泊プランや人数、追加オプションを組み合わせるだけでなく、宿泊開始曜日と宿泊日数から土日に該当する日を判定し、25％の割増を反映した期待金額まで算出できた点が印象的でした。
ユースケース2：データドリブンテストを実装・デバッグする
次に、Test Managerの要件、画面定義書、ユースケース1で作成したテストデータをもとに、データドリブンテストの実装を依頼しました。
画面定義書と実装条件を渡す
宿泊予約システムの画面定義書には、操作対象となる画面、入力項目、ボタン、画面遷移などが記載されています。
＜宿泊予約システムの画面定義書＞
実際にStudio Autopilotへ渡した指示は次のとおりです。
マネーパスにフォーカスしたデータドリブンのテストケースを作成してください。
データドリブンのテストデータはDataフォルダに格納しているため、テストケースにインポートして使用してください。
HOTEL:229（宿泊予約の機能要件）を参照し、添付の画面定義書もサポートドキュメントとして参照してください。
テスト実行時は、テストデータの「宿泊開始曜日」から宿泊開始年月日を算出してください。
宿泊開始年月日は、実行日より後かつ3か月以内の日付としてください。
宿泊予約確認画面の合計金額のみを検証し、テストデータの「ExpectedTotal」と一致することを確認してください。
URLに移動アクティビティは使用しないでボタンで遷移してください。
検証アクティビティは成功時もスクリーンショットを作成してください。
各シナリオの検証完了後に、そのシナリオで開いたブラウザーを閉じてください。
実装が終わったらデータを1件使ってデバッグしてください。
実際の画面でデバッグする
Studio Autopilotは、画面定義書とテストデータをもとにテストコードを作成し、宿泊予約システムを実際に操作してデバッグを進めました。
実行中に問題が見つかると、実行結果やエラーの内容を確認し、テストコードを修正して再実行します。
＜作成したテストコード＞
動画で実演
試して分かったこと
最もコーディングエージェントらしさを感じたのは、テストコードの生成ではなく、その後のデバッグです。
画面定義書と要件を確認 → テストコードを作成 → 実際の画面で実行 → 問題を特定 → コードを修正 → 再実行
実行結果から問題の原因を特定し、最終的に動作するテストケースまで完成させられた点が、このユースケースの大きな特徴です。
AGENTS.mdで開発ルールを指定する
Studioのプロジェクトに格納されているAGENTS.mdには、プロジェクト構造、命名規則、実装パターン、制約など、コーディングエージェントに継続して参照させる開発ルールを記載できます。
あらかじめ開発ルールを定めておくことで、依頼ごとに同じ条件を繰り返し伝えなくても、プロジェクトの方針に沿ってコードを作成・修正させやすくなります。
今回の検証では、テストコードの構造と実装方法をそろえるため、AGENTS.mdには例えば、次の様な項目で開発ルールを追加しました。
- 処理内容に応じてモジュールを分割する
- 共通化できる処理は再利用する
- 操作対象が画面上の値によって変わる場合は、動的セレクターを使用する
ユースケース3：テストデータとテストケースを管理基盤へ登録する
次に、テストデータを共通のデータソースとして管理するため、ExcelファイルからData Fabricへ移します。
あわせて、作成したテストケースを継続的に実行し、その結果を管理できるように、OrchestratorへパブリッシュしてTest Managerへ登録します。
テストデータをData Fabricへ移行する
ユースケース1で作成したテストデータを、ExcelファイルからData Fabricのエンティティへ登録します。
あわせて、テストケースのデータソースをExcelからData Fabricへ変更し、実行時に取得した各レコードが型付きテスト引数へ渡されるように修正します。
Studio Autopilotへ次のように指示しました。
テストデータをUiPath Data Fabricのテナントレベルエンティティへ登録し、StudioのData Serviceテストデータソースとしてテストケースに関連付けてください。
実行時にData Fabricから取得した各レコードを生成型の型付きテスト引数へ自動注入してください。
Data Fabricには、シナリオID、シナリオの説明、ログイン情報、宿泊条件、期待値などがレコードとして登録されました。
＜Data Fabricへ登録されたテストデータ＞
Test Managerから実行できる状態にする
続いて、作成したテストケースをOrchestratorへパブリッシュし、Test Managerへ登録します。
Studio Autopilotへ次のように指示しました。
本テストケースを公開可能に変更し、Orchestratorにパブリッシュしてください。
Test Managerに本テストケースを登録して、Test Managerから実行できるように設定してください。実際のテスト実行は不要です。
Test Managerへ登録されたテストケースには、実行に使用するOrchestratorのパッケージが関連付けられました。
＜Test Managerに登録されたテストケースとパッケージの関連付け＞
動画で実演
試して分かったこと
印象的だったのは、Studio内のコードを修正しただけでなく、UiPath Platform上のData Fabricにエンティティを作成し、テストデータを登録した点です。
さらに、テストケースのデータソースをExcelからData Fabricへ変更し、Data Fabricから取得したデータを使用できるようにテストケースも修正しました。
Data Fabricへのエンティティ作成とデータ登録 → テストケースの修正 → Orchestratorへのパブリッシュ → Test Managerへの登録
Studio内の実装にとどまらず、Data Fabric、Orchestrator、Test Managerをまたいで、テストデータの登録からテストケースを実行できる状態まで進められた点が、このユースケースの大きな特徴です。
ユースケース4：テストケースを分析してドキュメントを作成する
次に、作成したテストケースの内容を分析し、テストの目的、前提条件、操作手順、期待結果などを確認できるドキュメントの作成を依頼しました。
作成した内容はファイルとして保存するだけでなく、Test Managerのテストケース説明欄へ反映し、Word文書として添付します。
作成内容と形式を指定する
ドキュメントに記載する内容、作成時に参照する対象、作成するファイル、Test Managerへの反映内容は、Markdown形式の指示書に定義しました。
＜Markdown形式のドキュメント作成指示書＞
あわせて、Word文書の構成を指定するため、テストの目的、前提条件、テストデータ、操作手順、期待結果、処理の流れなどを定義したテンプレートを用意しました。
＜Wordテンプレートの記載項目＞
Studio Autopilotへ次のように指示しました。
Docs/test-case-documentation-prompt.md と Docs/test-case-documentation-template.md を読み、指示に従って現在のテストケースを分析してください。
以下をすべて実施してください。
- Markdown形式の詳細説明書を作成する
- Test Manager添付用のWord文書を作成する
- Test Managerの対象テストケースの説明欄に、Markdown原本の「Test Manager登録用説明」を登録する
- 作成したWord文書を対象テストケースに添付する
- ファイルの内容、説明欄の保存結果、Word文書の添付結果を確認して報告する
- 既存のXAML、テストデータ、設定ファイル、テストケースの動作は変更しない
ドキュメントを作成してTest Managerへ反映する
Studio Autopilotは、指示書とテンプレートを確認し、プロジェクト内のテストケースを分析しました。
分析結果をもとに、テスト条件、使用するデータ、画面操作、期待結果などを整理したMarkdownとWordのドキュメントを作成しました。
＜StudioのDocsフォルダに格納されたMarkdown形式の詳細説明書＞
さらに、Test Managerのテストケース説明欄へ概要を登録し、Word文書を添付しました。
＜Test Managerに登録されたテストケース概要＞
＜Test Managerに添付されたWord文書＞
動画で実演
試して分かったこと
Word文書を生成できたことに加え、既存のテストケースを分析し、指定した構成に沿って内容を整理できた点が印象的でした。
既存テストケースの分析 → 指定した構成でのドキュメント作成 → Test Managerの説明欄への反映 → Word文書の添付
ドキュメントを作成して終わるのではなく、Test Manager上のテストケースへ説明を反映し、Word文書を添付するところまで、まとめて依頼できました。
ユースケース5：Test Managerからデータドリブンテストを実行する
最後に、Test Managerへ登録したテストケースを実行します。
データバリエーションごとにテストを実行する
テストを開始すると、Data Fabricのエンティティからテストデータが取得され、各レコードがデータバリエーションとしてテストケースへ渡されます。
テストケースは、データバリエーションごとに次の処理を実行します。
- 宿泊条件を予約画面へ入力する
- 予約確認画面に表示された合計金額を取得する
- テストデータの期待値と比較する
- 検証結果と画面エビデンスを保存する
すべてのデータバリエーションを実行した結果、各パターンの合否がTest Managerへ記録されました。
＜全テストパターンの実行結果＞
検証時の画面も、データバリエーションごとのエビデンスとして保存されています。
＜エビデンスとして保存された検証画面＞
試して分かったこと
これまでに作成・登録したテストデータとテストケースが、実際のテスト実行でも想定どおりに動作することを確認できました。
おわりに
記事では説明のために5つのユースケースへ分けましたが、実際には各工程の作業内容や完了条件を1つの指示書にまとめ、テストデータの作成から実装・デバッグ、ドキュメント作成、実行管理までを一気通貫で依頼できます。
今回確認した内容も含め、UiPathのコーディングエージェントには、次の3つの特徴があります。
-
テスト対象をWeb以外にも広げられる
今回はWebアプリケーションを対象としましたが、デスクトップアプリ、Microsoft Office、業務システムなども操作・テストの対象にできます。 -
テストの準備から実行管理までをつなげられる
テストデータの作成、実装・デバッグ、ドキュメント作成、テスト実行、結果管理までを一連の流れとして進められます。 -
調査範囲をコードの外側まで広げられる
コードだけでなく、パッケージ、実行設定、権限、Test Managerとの関連付けなど、UiPath Platform側も調査対象にできます。
AI駆動開発によって開発が速くなるほど、継続的に品質を確認し、その結果を次の開発へつなげる仕組みも重要になります。
テスト対象の幅を広げ、テストの準備から実行管理までをつなぎ、トラブルシューティングもコードの外側まで対応できる。
そこが、UiPathのコーディングエージェントならではの価値だと感じました。
個人のテスト周辺業務まで幅広く、AIエージェントに任せるケースは、こちらも是非ご覧ください。
少し古い記事（特にコード生成はレガシー）ですが、生成AIを使ったTest Managerの管理機能については、こちらをご覧ください。