生成AIによるE2Eテスト自動化の挑戦：理想と現実のギャップ

はじめに

• こんにちは。NCDCの藏原です。
• 皆様、生成AIで業務を効率化していますか？
  • PMの業務において、生成AIは以下のような作業を効率化できると期待されます：
    • 会議議事録の作成と要約
    • 要件定義書やイシューの下書き
    • 進捗レポートの自動生成
    • テストの自動実行
    • などなど
  • しかし、理想と現実は異なるもので、「AIでこれできるんじゃない？」と言う無邪気な思いつきをそのまま実装・実現できることはまずありません。
• この記事は、E2Eテストの自動化・効率化を夢見てPlaywright MCPに手を伸ばした結果、手動でテストするよりも時間がかかってしまったPMの、技術的供養記事になります。

基本的な考え方

検証の手順

• まずは、要件定義書や設計書、githubイシューからE2Eテスト仕様書を作成します
  • テスト仕様書の自動生成については別途説明します
  • ExelやPDFよりは、JSONなどの形式の方がデータを階層構造で表現できるため、計算機での処理に最適です。
• 手元にE2Eテストの仕様書がすでにある場合、MCPを使ったテスト自動化には２通りのアプローチが考えられます
  1. 仕様書を直接生成AIエージェントに流し込み、ブラウザを操作させる
  2. 仕様書からテストコードをAIに生成させ、テストを実施しながらコードを直していく

生成AIに仕様書を流し込む方法

• 以下のようなプロンプトを、生成AIに指示します。

以下の手順に従って、Webサービス<URL>に対するE2Eテストを実施し、結果を報告してください。
1. テスト対象:
テスト定義ファイル: <テスト定義ファイルパス> に含まれる、A機能のE2Eテストを実行します。
テストデータファイル: <データファイルパス> をアップロードしてテストを実施します。
2. テスト環境の準備:
（他システムや認証情報、DBなどのへの接続が必要な場合、ここに記述します）
3. テストの実行:
ステップバイステップでテストを実行してください
テストの各ステップ（APIリクエスト送信、レスポンスの検証など）の実行履歴を記録してください。

• Amazon Q Developer CLIを用いれば、普段は停止しているEC2踏み台サーバーの起動などがプロンプトで実行できます。

生成AIにテストコードを生成させる方法

• 以下のようなプロンプトを、生成AIに指示します。

<テスト定義ファイルパス>のテスト項目に従って、<テストコード>を作成して。
適宜<ソースコードのパス>を参照して。
POMの考え方に沿って、共通部分はクラス化して。

• 生成AIに生成させるスクリプトは使い捨てであることが基本ですが、長期に続くプロジェクトなどでテスト運用することを考えると、POM(Page Object Model)などを用いて再利用性を高めるのがいいのではないかと考えました。
• 初回のプロンプトで完成度の高いコードを生成する方が効率的です。対話的な修正は時間がかかり、一貫性を保つのが難しくなる上に、トークンを多く消費してしまいます。
  • プロンプトには、以下のような情報を含めると良いでしょう
    • フロントエンド実装の確認方法
    • Page Objectパターンを使用したテストコードの実装例
    • セレクター指定と待機処理のベストプラクティス
    • エラーハンドリングの実装方法
    • 具体的なテストケース例
• そして、出来上がったplaywrightベースのテストコードを実施します。これはbashに手打ちでも、MCPのbash_execのどちらでも良いでしょう。

$ npx playwright test hoge.test.js --headed

ツール

• コード生成
  • Claude 3.5(VSCode LM API) on Cline
• ブラウザ操作
  • amazon Q developer CLI

課題（結果）

生成AIに仕様書を流し込む手法

遅い

• 一つ一つの操作のたびに、数秒~数十秒の待ち時間が発生します。
  • ログインだけで1分以上ほどかかることも普通にあります
• ブラウザを立ち上げ、システムにログインし、目的の画面に辿り着くまでにかなりの時間を要します。

MCPサーバーを使ってくれない

• 一度に大量のブラウザ操作を指示すると、生成AIが実行を諦めることがあります。
  • スクリプトや手順書を生成して、「あとは人間が頑張ってね」という応答が返ってきたり
  • 「MCPで操作したあと、履歴をplaywrightスクリプトにして」などのように指示すると、最初からスクリプトを生成してきたり

ステップが多いと止まる

• テスト実行中に、予期しないタイミングで実行が止まることがあります。

  • <Bボタン>を選択しようとしましたが、応答が大きすぎてエラーが発生しました
    

• 操作のたびにページ要素を取得しているのかと思いますが、10~20ステップほどで、トークンをあっという間に消費してしまうのではないかと考えています。

テストコードを生成させる手法

セレクターが正しくない

• モダンなJavaScriptフレームワーク(React等)では、CSSクラス名が自動的にハッシュ化され、一意の値として生成されます。
  • よって、Playwrightなどを用いて要素を選択する場合、MUIのロール属性や、要素中のテキストを指定するなどの手法を採用するのが、推奨される手法とされています。
  • しかし、Claude 3.5で生成されたソースコードのセレクターの品質はとても低く、要素の指定が完全に誤っていました。
  • $npx test を実行してもことごとく失敗するので、結局ブラウザを人間が開いて、ソースコードをデバッグしないといけません。
    • このセレクターのデバッグがかなり大変で、結局人が直接操作した方が早い　という本末転倒な状況に陥りました。

コードの修正が安定しない

• 現在の生成AIによるソースコードの修正作業は、修正のたびにファイルの全行を読み込んで変更箇所のみを修正するという振る舞いになります。なので対話の回数が増えてくると、挙動が不安定になりました。
  • 変更部分だけを残して残り全ての行が消える
  • ファイル更新ではなく、Clineのコンソールに修正結果が出力される
• このような不具合が出るたびに、「元に戻して」という指示であったり、コンソール画面からコードをコピーペーストしたりする必要が生じてしまい、コードの開発体験としてはよくなかったです。

考察

2手法の比較

• 今回検証した二つの手法と、従来の手動によるE2Eテストの比較表を、下に示します。

	ブラウザの直接自動操作	テストコード生成	手動
スピード	とても遅い	とても早い	早い
品質	良い	悪い	最良
再利用性	低い	高い	人次第
トークン消費量	高	高	なし
マンパワー	小	大 (デバッグのため)	大
課題	挙動が安定しない	デバッグ作業が大変	テストのたびに人間が必要

コストに関して

• セレクターの修正をポチポチ対応していたら、トークンが1mを超過しました…
  
• 今日の生成AIは、対話するごとに全ての履歴を読み込みながら返答を生成しているため、対話が長くなると消費トークン量がどんどん増えていきます。

打開策

1. ブラウザを直接操作した履歴から、テストコードを生成する

• 生成AIに直接ブラウザを操作させて一連のテストを実施した後、以下のようなプロンプトを指示します

• これまでの操作を再現できるplaywrightスクリプトを作成し、<テストフォルダ>に配置してください
  セレクタにはRoleやTextをなるべく指定し、CSSの指定は避けてください
  

• この指示の結果、最後まで正しく動く、再利用可能なコードベースのスクリプトが生成できました。
• このソースコードはテストシナリオごとに使い捨てになる前提ではありますが、１シナリオに限ったテストケースであれば、この方法で十分なのではないかと思います。
  • 不具合の再現テストなど

2. セレクターを修正しながらテストを実行するワークフローを構築する

• セレクターをロストした時のみページ要素を読み込んで…と言うような挙動ができるとなお良いですね
• 課題感としては、トークン消費量が膨大になると言うことでしょうか

3. ソースコードにtest-idを振りながら開発する

• そもそもフロントエンドの要素にidやtest-idが振られていれば、セレクターで困ることはなくなります。
• 画面を見ずとも、ソースコードからテストコードを生やすことができるでしょう
• ただそこまでやると、開発側に工数が発生することになり、開発作業を増やしてしまうのがデメリットです。

まとめ

• 今回の検証では、生成AIを用いたE2Eテスト自動化は、現時点ではまだ多くの課題を抱えており、「銀の弾丸」であるという結論には至りませんでした。
  • 手法が２つ考えられましたが、セレクターの不安定さや、対話に伴うトークン増大が顕著でした。
• しかしながら、ブラウザ操作履歴からのテストコード生成といったアプローチは、特定シナリオにおいては有効な可能性を示唆しており、今後の発展に期待したいところです。