はじめに
こんにちは！メドレーで QA エンジニアをしている @Daishu です。所属チームのプロダクト (Web) の E2E テストで MagicPod を運用して 3 年になります。
最近よく「AI を活用して Playwright で自動化した」という話を聞く機会が増えました。先日の STAC2025 でも Playwright の話題はホットでしたね。AI × QA を推進している身としては Playwright が気になっていたので、MagicPod の一部シナリオを Playwright で実装してみました。
やってみて「確かに使える」という手応えは感じた一方で、MagicPod の良さにも改めて気づきました。この記事では、Playwright を触ったからこそ見えた MagicPod の良さを紹介します。
Playwright を触ってみて
基盤設計の 0→1 込みで AI がサポートしてくれる
これまで、自分のスキルでは自動テストの基盤設計 (PageObject[1] 等) は難しいと思っていました。コードベースの自動テストは、まず専門性を持ったアーキテクトが枠組みを作ったあと、メンバーがテスト実装や修正のメンテをする認識で、設計と実装は別物と考えていました。
ところが、Claude に「ログイン画面のテストを PageObject パターンで書いて」と投げたら、ディレクトリ構成から実装まで一気に作ってくれました。もちろん、100% 完璧ではないと思いますが、以前なら設計担当と実装担当で分業していた部分が、AI のおかげで 1 人で回せる未来を見ました。
テストコードをプロダクトコードと同じリポジトリで管理できるので、機能開発と並走しやすい点も魅力的です。開発者にも E2E テストの存在をより身近に感じてもらえそうと期待しました。
運用環境の 0→1 は自分で作る必要がある
一方で実装したテストコードを品質保証に繋げていくには、E2E テストを継続的に回し続けるための運用環境を整備する必要があります。
ローカルで動かすだけなら問題ありませんが、定期実行やチームでの共有を考えると CI などのリモート実行環境が必要になります。Playwright はテストフレームワークとしては優秀ですが、「テストを運用する」ための周辺機能は自前で揃える必要がありました。
MagicPod から E2E テストを始めた身としては、「これらの課題感が全くなく使っていた」ことを思い知りました。
MagicPod の提供機能
Playwright を触ったからこそ、MagicPod が最初から提供してくれていた機能に気づきました。
| 機能 | 説明 |
|---|---|
| 定期実行 | 「毎朝 9 時に実行」と設定すれば、Slack 通知もレポートも全部セットで動く |
| 固定 IP | 開発環境の IP 制限設定が簡単。CI で固定 IP を用意する手間が不要 |
| 環境変数 | UI 上で簡単に設定して、一括実行に紐づけ可能。並列実行の設定もできる |
| その他 | 自己修復、Git 操作不要、手厚いサポート |
また、MagicPod は Web・iOS・Android のテストを一元管理できます。
MagicPod での学びが Playwright で活きた
Playwright を触ってみて、MagicPod がノーコードテストツールとして自動テストの概念をうまく抽象化してくれていたことに気づきました。
| MagicPod | Playwright | 共通の考え方 |
|---|---|---|
| UI 定義 | PageObject | 画面ごとに要素を管理し、テストから詳細を隠す |
| 共有ステップ | ヘルパー関数 | 使い回す処理をまとめておく |
特に MagicPod の UI 定義 (スクリーンショットにセレクタを紐づけて管理できる) は、改めて使いやすいと感じました。Playwright だと loginButton という変数名を見ても、それが画面のどこにあるボタンなのか、コードからわかりづらいです。MagicPod なら画像を見ればわかるので、デバッグ実行しなくてもテストが Fail した原因がぱっと見でわかります。視覚的に UI の変化を理解できる点も大きいです。
左が MagicPod の UI定義、右が Playwright の PageObject
MagicPod から始めて良かった
個人的には、MagicPod から始めて良かったと思っています。自動テストを品質保証に繋げるまでの 0→1 を最速で実現できるのは大きいです。1→100 までのフェーズも QA チーム主体で実現することができた実績もあります。
E2E テストの考え方、設計、運用のノウハウはツールを超えて活きます。例えば「1 テストケースでどこまでやるか」という粒度の感覚。最初は 1 ケースに詰め込みすぎて失敗原因の特定に苦労し、ユニットテスト相当のものを入れて実行時間が膨らみ...という試行錯誤を経て身についた感覚は、Playwright でもそのまま使えると思いました。
振り返ってみて、MagicPod は私にとって「E2E テストの教科書」でした。MagicPod での運用を通じて学んだことは、以前ミートアップでも紹介しました。
まとめ
AI の登場で Playwright による E2E テストの 0→1 は短縮できました。ただ、1→100 のフェーズで安定して運用するには、運用環境の整備に加え、AI が生成したコードを理解してメンテナンスできる力も必要と感じました。MagicPod の運用を続けながら、AI × QA の可能性を探る意味でも Playwright は引き続き触っていきたいと思います。
メドレーでは生成 AI 利用のガイドラインが社内で展開されており、各部門の業務ではそのガイドラインに沿って利用をしています。
-
画面ごとにクラスを作り、セレクタや操作をまとめる設計パターン。詳細は Playwright 公式ドキュメント を参照。 ↩︎
Discussion