🧪
E2Eテスト自動化の事例4選 ～Playwright活用編～ イベントレポート
公開
2025-03-29
更新
2025-03-29
文章量
約3174字
Yard 編集部
Yardの編集部が、テック業界の最新トレンドや知見について発信します。
2025年3月13日、Findy主催による「E2Eテスト自動化の事例4選 ～Playwright活用編～」がオンラインで開催されました。
開発の現場でますます存在感を増しているテスト自動化。その中でもPlaywrightが近年、多くのエンジニアの支持を集めているのはなぜなのか。
本イベントでは4名の登壇者が「なぜE2EテストにPlaywrightを採用したのか」、そして「具体的にどう活用しているのか」を、実際の課題や効果も交えて語ってくださいました。
1. 『StotybookからはじめるVRT -個人開発編-』 (arrow2nd さん / ちょっと株式会社)
まずトップバッターとして登壇いただいたのは、フロントエンドエンジニアであるarrow2ndさん。個人開発している読書記録アプリ「4co」に、Storybook×PlaywrightによるVRT(Visual Regression Testing)を導入し、見た目の品質を守っている事例を紹介しました。
主なポイントは次のとおりです。
導入背景 個人開発では、開発コストや時間に限りがある。見た目の検証をどう効率化しつつ担保するかが悩みどころ。Storybookで既にコンポーネント管理を行っていたため、VRTとの相性が良かった。
なぜPlaywright？ 他のVRT専用ツールを増やすと保守コストが増大するため、E2Eテスト等でも利用予定だったPlaywrightで統一。これによりツール追加のオーバーヘッドも抑えられた。
VRTの書き方 コンポーネントごとに Storybook の
index.jsonをループで取得してスクショを比較。既存のコンポーネント数が増えても、1つのファイルで完結する仕組みを整えた。効果と課題 Tailwind CSS のアップデート時に差分を的確にキャッチでき、短期間のリリースでもデザイン崩れを素早く発見。テストレポートの閲覧体験向上など、さらなる改善余地はある。
個人開発とは思えない丁寧な運用が印象的でした。必要最低限のコストで“見た目”を守りたい方には大きなヒントになるセッションだったと言えます。
2. 『StorybookとPlaywrightではじめるインタラクションテスト』 (中山 晶平(nakker1218) さん / 株式会社enechain)
2人目は 中山 晶平（nakker1218） さんが、細かいユーザー操作が多い業務アプリにインタラクションテストを導入してみた話を披露。事業インパクトが大きい領域だからこそ、E2Eテストは欠かせないという現場視点が際立ちました。
インタラクションテスト導入の背景 enechainではエネルギー系の大型取引を扱うWebシステムを運営。ポップアップウィンドウやショートカットキーなど、細かな操作部分での不具合が多発し、これをテスト自動化で防ぎたかった。
なぜプレイライト？ ネイティブのブラウザ操作を前提としたテストが必要。さらにストーリーブック上でコンポーネント単位のテストを書きたい。VS Codeプラグインなど開発体験も良く、チーム内で取り組みやすかった。
実装方法 ローカルで Storybook を立ち上げ、プレイライトがそれぞれのストーリーを読み込み、実際のブラウザ上でコンポーネントを操作して動作を検証。ポップアップ上でのUI挙動などもカバーできた。
課題 CIの実行時間が伸びるため、シャーディングや差分実行（変更されたコンポーネントのみテストする）など工夫を実装。モックデータを整えるのも大きな労力で、運用負荷とのバランスが鍵。
複雑なUIをもつ業務アプリへのE2Eテスト事例として、 「必要不可欠だからこそインタラクションテスト」 とする強い動機が印象的でした。精度と効率化を高めるための工夫も、実務に活かせそうな良い学びでした。
3. 『開発が大規模化しても破綻しないナレッジワークのE2Eテスト基盤』 (鳥居 陽介 さん / 株式会社ナレッジワーク)
3人目は鳥居 陽介さん。大規模化するプロダクトに合わせて、E2Eテスト基盤を拡張してきた話が魅力的でした。ちょうど組織拡大に伴う悩みをクリアしてきたリアルな事例です。
テスト環境競合問題 同じテナントを同時に使うと競合してテストが落ちる。手動で「今からテストするんで待ってて」が発生。そこでテナントプールを用意し、前提条件を満たしたテナントを複数確保、同時実行を可能に。
コードベースのモノリスを分割 プロダクト単位にディレクトリを分割し、通知先やセットアップも分割。必要のないテストを走らせる無駄を削減し、実行時間を減らした。さらにオーナーシップを開発チーム側に渡し、メンテしやすく。
大事なポイント こうした仕組みを作る際、複数メンバーでリバースエンジニアリングを行い、前提条件をドキュメント化。仲間を巻き込みながら問題を一つずつクリアし、破綻しないE2E基盤を整備していった。
「複数プロダクト」「組織拡大」「テスト資産の再編」の三拍子が同時に来た会社で、しっかりと基盤を作り上げている事例は非常に貴重。チームオーナーシップと仕組み化の大切さを再認識させられました。
4. 『Playwrightで実現する品質保証の好循環な仕組み』 (木下 智弘 さん / ウェルスナビ株式会社)
最後は木下 智弘さん。QAチームの立場から、PlaywrightによるE2Eテスト運用を「継続利用」できる仕組みに焦点を当てて語られました。
継続して活用できる自動テスト 「一度作ったE2Eテストを使い続けるには、運用や保守コストに対して得られる恩恵が十分かどうかが鍵」との指摘。安定性の高いプレイライトが、そこを支えている。
ツール選定の基準 テスト結果の信頼性・実行速度・視認性・ケースの容易な修正・ツール自体の臨機応変な対応――この5つの観点をクリアしたのがPlaywrightだった。
インフラ整備 AWS上にテスト実行環境やレポート格納用バケットを構築し、アプリへのリリース前などにもスムーズにテスト可能。QAチームのみならず他チームも品質チェックを自分たちで回せる体制を実現。
今後の展望 リグレッションテストからさらにビジュアル比較や、より幅広いケースへの適用を検討中。ロボアドの複雑な金融サービスだからこそ、より自動テストの恩恵を大きくしていきたいとのこと。
運用コストを冷静に見極めつつ、“手動テストが不要になる”のではなく“QAチーム以外でも品質担保し続けられる”仕組みにしている点が好印象でした。
全体を踏まえた感想
イベント全体を通して、Playwrightは機能的に大変強力である一方、運用や組織対応による課題はそれぞれの規模感やチーム構成で大きく異なることが浮き彫りになりました。個人開発ならミニマムな導入で見た目を守る、スタートアップならインタラクションテストで高度な操作性を担保、大規模化にはテスト環境やテストコードの分割、そして“チームで保守する”仕組みづくりが必要、などなど――「Playwright × E2Eテスト」と一口に言っても、その使い方は千差万別です。
しかし共通していたのは、「目指すのは作り捨てではなく継続可能なテスト」。それには“コードの分割”や“テナントプール”“シャーディング”など、現場ならではのアイデアが続々と紹介されました。今まさにE2Eテストをどう実装しようか悩んでいる方、既存のテスト基盤が破綻しがちで困っている方には、多くのヒントを与えるイベントだったはず。ぜひ今回の事例を参考に、運用まで含めたPlaywright導入を検討してみてはいかがでしょうか。
Yardでは、テック領域に特化したスポット相談サービスを提供しています。
興味がある方は、初回の無料スポット相談をお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
