この記事は、「ヌーラボブログリレー2025 冬」のTechブログ 13日目の記事です。
Findy AI Meetup in Fukuoka #3で発表した内容を記事にまとめました。ほぼほぼスライドの内容と変わらないですが、スライドでは説明しきれなかった部分を補足していこうと思います。
スモークテストとは
定義・計画した全テストケースのサブセット。プログラムの必須機能が正常に動作することを確認するのが目的で、コンポーネントやシステムの主要機能を網羅し、細かな点は無視する。
引用元: ISTQB Glossary
Backlogでは元々スモークテストをSeleniumとJavaで書かれており、Backlogの主要な機能をカバーするように設計されています。代表的なテストケースを挙げると以下のようなものが含まれています。
- 課題の作成、編集、削除
- Wikiの作成、編集、削除
- ファイルのアップロード、ダウンロード、削除
こういった主要な機能が正常に動作することを確認するために、スモークテストは定期的に実行されており、Backlogの品質を保つために重要な役割を果たしています。
なぜスモークテストを移植しようと考えたのか？
「なぜか？」と問われれば、答えとしては「ノリ」でありいい感じの言葉にすれば思ったが吉日というのが正直なところですが、背景としてはいくつか理由があります。
- 以前からメンテナンス面を考えて、SeleniumからPlaywrightへの移行の話は社内であったがなかなか進まなかった
- 一方フロントエンドの開発でPlaywrightがBacklog内でもよく使われるようになり、デファクトの存在であった
- ちょうど社内でGemini CLIが使用できるようになり、体験するためにちょうどいい題材だった
こういった背景のもと、スモークテストの移植を行うことにしました。
どうやって移植していこうか？
さて、移植を進めていくわけですが一種のプロジェクトでもあるので、とにもかくにも目指すべき方向性を決める必要があります。ここでは目標として「Seleniumで書かれて現在稼働しているスモークテストと同等の機能を持つPlaywrightベースのスモークテストを作成する」こととし、これが達成されたのちに追加で改善を加えていくことにしました。
また、移植を進めていくにあたって以下のような方針を立てました。
- SeleniumではChromeを使用していたため、スモークテストで使用するブラウザはChromiumベースで動作させる
- 既存のSeleniumテストケースを一つずつPlaywrightに書き換えていく
- 各テストケースの動作確認を行い、問題がないことを確認したら次のテストケースの移植に進む
- Playwrightのベストプラクティスにしたがう
これらの方針をもととして、gemini cliに実際の移植計画を立ててもらい、レビューを与えながらブラッシュアップし実際に移植を進めていきました。
AIエージェントとペアプロしていく
先ほど立てた計画をもとに進めていくわけですが、特筆すべきこともなく既存の稼働しているスモークテストの移植自体はgemini cliがほぼ数時間程度で完了してしまいました。少し面白い点があるとすれば、各テストケースの移植についての指示に「t_wadaのTDD的な進め方でやってください」と伝えたところ、gemini cliがTDD的な進め方で移植を進めてくれたことです。
ある意味当初の目的としてはこの時点で達成していましたが、せっかくなので移植したスモークテストの改善をgemini cliとペアプロしながら進めていくことにしました。
flakyさからコメントアウトされていたテストケースの復活
移植の過程で、Seleniumでflakyさからコメントアウトされていたテストケースがいくつかあることに気がつきました。これらのテストケースはPlaywrightに移植した際にもコメントアウトされたままでしたが、せっかくなのでこれらのテストケースを復活させることにしました。
こちらも単純にgemini cliに指示して、既存のテストケースと同等の動作をするよう実装してもらいました。指示の中でPlaywrightのベストプラクティスに従うよう伝えているため、PlaywrightのAuto-waitingを活用した実装になっており、flakyさが解消されていました。
クロスブラウザでの実行の実現を試みる
Playwrightの強みの一つとして、クロスブラウザでのテスト実行が容易にできる点があります。移植したスモークテストもこの強みを活かし、Chromium、Firefox、WebKitの3つのブラウザで実行できるようにしようと試みました。
しかし、Chromeiumでは問題なく動作したものの、FirefoxとWebKitではいくつかのテストケースが失敗することが多く安定した実行ができませんでした。これらの問題を解決するために、gemini cliと協力して各ブラウザでの動作確認を行い、問題の原因を特定し修正を加えていきました。具体的にgemini cliには以下のようなタスクを依頼しました。
- 各ブラウザで全てのテストケースを複数実行し結果を集計、失敗しやすいflakyなテストケースを特定する
- flakyなテストケースの原因を調査し、必要に応じて修正を行う
これらのタスクから失敗しやすいテストケースを特定し原因を調査していくのですが、gemini cliはコード上に問題があると仮定してさまざまな修正を行うも、最終的には人間側で原因を特定し修正を行う必要がありました。内容的にHTMLの構造がわかっていないため、的外れな修正になってしまうことが多く、人からコンテキストを与えられないと難しい部分があるようです。
面倒だなと思っていたちょうどこの頃、Playwriht mcp serverが公開されていたこともあり、以下のような手順で修正を行えないか試してみました。
- gemini cliからPlaywright mcp serverに接続できよう設定
- 問題のテストケースをブラウザ操作から実行し、その内容からテストケースの修正点を提案するよう指示
- 提案された修正点をもとにテストケースを修正
これによりgemini cliがより効果的に問題の特定と修正を行えるようになりました。しかし完全に全てのブラウザ、特にFirefoxでのflakyさを解消することは難しく、当初の方針に沿ってChromiumベースでの実行に落ち着くことにしました。
Playwright mcp serverを活用して、新規テストケースを追加する
移植と改善が一段落した後、せっかくなので新規のテストケースを追加してみることにしました。ここでもPlaywright mcp serverを活用し、以下のような手順で新規テストケースを追加しました。ここではBacklogのプロジェクトを作成・削除してみます。
- gemini cliにPlaywright mcp serverでプロジェクトの作成を指示
- gemini cliが操作した内容を一旦markdownファイルに保存
- markdownファイルの内容をもとに、テストケースのコードを生成
- 生成されたコードをレビューし、必要に応じて修正
- 同様の手順でプロジェクトの削除のテストケースも追加
この手順により、比較的スムーズに新規のテストケースを追加することができました。また指示自体も以下のような平易な言葉で伝えても問題なく実施してくれるので、こういったE2Eのテストを書くハードルが下がるのは非常に良いなと感じました。
ダッシュボードページからプロジェクトの作成を行ってみてください。プロジェクト名は何かランダムな名前を指定してください。キーもランダムで構いません。
プロジェクト名の入力がされてないです、また確かにプロジェクトキーのフォーマットがおかしいです。プロジェクトキー入力欄の下にフォーマットについて制限が記載されているのでその制限に従ってください。
今行ったプロジェクト作成の操作を記憶してほしいです。適切なmarkdownファイルに書き起こしてください。
このようにして、gemini cliとPlaywright mcp serverを活用することで、スモークテストの移植だけでなく新規のテストケースの追加も効率的に行うことができました。
おわりに
これらの取り組みは2025年の7月から8月にかけて行なっていましたが、この記事を書くまでにPlaywright 1.56でtest agentsが登場したりして、AIエージェントを使用してE2Eテストを書くことがより身近になってきたなと感じています。とはいえ、最終的な判断は人が行う必要があるのでうまくAIエージェントを活用していくには、使う側のスキルも必要になってくるなと感じました。DORAレポート2025のみならず「AIは増幅器」であると感じている人は多いようです。適切なタスクわけ、レビューの観点などなど、ある程度のスキルがないとAIエージェントで自身の能力をブーストしていくのも難しいなと思います。
というわけで、皆様精進していきましょう。