PlaywrightとGitHub Actionsを用いたE2Eテスト自動実行環境の構築と、リリース頻度向上の取り組み¶
チェック¶
- [ ] 本文を確認した
- [ ] 概要を確認した
- [ ] タグを確認した
- [ ]
inbox/直下へ移行した
概要¶
手動で行っていたリグレッションテストを Playwright で E2E テスト化し、GitHub Actions と Self-hosted Runner で検証環境デプロイ後に自動実行する仕組みを作った記事。 IP 制限のある社内検証環境へ GitHub hosted runner から直接アクセスできないため、セキュアなネットワーク内に E2E 専用実行基盤を作り、Self-hosted Runner として運用している。 Slack 通知、Artifacts、動画、スクリーンショット、Playwright report を組み合わせ、リリース前確認の工数を削減し、リリース頻度を月3〜4回から月7〜8回へ増やした。
本文¶
筆者はエムスリーキャリアの QA エンジニア。 医師採用支援サービスのチームで、要件定義レビューからテスト実行まで、品質保証業務全般を担当している。
チームでは、機能追加やシステム改善を素早くユーザーへ届けるため、リリース頻度を高めたいという目標があった。 しかしボトルネックになっていたのが、リリース前の CV 確認などのリグレッションテスト。 毎回手動で画面操作をして確認する作業は負荷が高く、ヒューマンエラーも起きやすい。
そこで、Playwright による E2E テスト導入と、GitHub Actions / Self-hosted Runner による自動実行環境を構築した。
第1フェーズ: Playwright によるテストコード化¶
最初の取り組みは、手動確認を Playwright の E2E test script にすること。 画面操作による確認作業をコード化し、リリース前に実行できるようにした。
Playwright 導入により、手動操作の一部は大きく減った。 しかし、ローカル環境でテストが実行できるだけでは十分ではない。 QA エンジニアが手動でテストを起動する運用は残る。
リリース頻度を上げるには、検証環境へのデプロイに連動して E2E テストが自動実行される必要があった。
第2フェーズ: Self-hosted Runner の導入¶
目標は、リリース前の検証環境へアプリケーションがデプロイされたタイミングで、自動的に全 E2E テストが実行される仕組み。
ここで課題になったのが network access。 テスト対象となる社内検証環境や外部システム連携用のテスト環境には IP 制限などのアクセス制御があり、GitHub Actions の hosted runner から直接アクセスできなかった。
解決策として、セキュアなネットワーク内に E2E テスト専用の実行基盤を構築し、GitHub Actions の Self-hosted Runner として運用した。
Self-hosted Runner は、runner 側から GitHub へ job を取りに行く。 そのため、外部から runner に入るための inbound port を開ける必要がない。 社内ネットワークの制約を守りながら、検証環境へ接続できる。
自前運用のため、保守コストは発生する。 しかし、IP 制限、ネットワーク統制、検証環境への安全な接続を満たすには、この構成が妥当と判断されている。
生成AIとエンジニアの助言¶
専用サーバ構築では、network 設定、access control、実行環境の常駐化、container 環境の権限設定など、QA の通常業務から少し外れる作業が必要になった。 そこで生成 AI を技術的なサポート役として使った。
具体的には、次のような作業で AI を活用している。
- テスト実行ツールが消費する resource を見積もる。
- 同時実行数に応じた必要 memory を算出する。
- cost と performance のバランスが取れた server spec を選ぶ。
- container 実行に必要な user 権限や security 設定を確認する。
- Self-hosted Runner を background service として常駐させる手順を作る。
ただし、AI の提案をそのまま採用したわけではない。 社内ネットワークとの接続方針、全体 architecture、security risk など重要な判断はチームのエンジニアに相談している。
生成 AI による推進力と、チームメンバーの知見を組み合わせたことが、QA エンジニアの技術範囲を超える環境構築を進める助けになった。
自動実行 workflow¶
完成した GitHub Actions workflow は、次の仕様で運用されている。
- 検証環境へのデプロイ完了を trigger として E2E テストを自動開始する。
- 独立した test job は並列実行し、実行時間を短縮する。
- 外部システム連携 batch のように順序や待機時間が必要な test は、job 依存関係と待機時間を設定して順次実行する。
- テスト完了後、実行時間や status を Slack に通知する。
- 失敗時には Playwright report、動画、screenshot を GitHub Artifacts として保存する。
workflow の構造は、単に全 test を並列化するだけではない。 独立して安全なものは並列化し、データ競合や外部 batch 待ちがあるものは順序制御する。 E2E test では test data と外部 system の状態が絡むため、この切り分けが重要になる。
Artifacts に report、video、screenshot を残すことで、失敗時の原因特定がしやすくなる。 Slack notification からすぐ report を見に行けるため、テスト失敗の調査動線も短い。
成果¶
成果は、リリース前確認作業の自動化。 Playwright の test code 実装から CI/CD 環境構築まで完了したことで、開発サイクルが大きく改善された。
導入前のリリース頻度は月3〜4回程度。 CI/CD 環境構築後は月7〜8回程度に増えた。
リリース頻度が増えても、E2E test が自動かつ安定して実行されるため、手動リグレッションテスト工数はゼロに抑えられている。
今後は、実行環境の安定化、performance 改善、チーム内での E2E test 適用範囲拡大、他チームの product への横展開が予定されている。
読み替え¶
この記事は、QA の自動化を「テストコードを書く」だけで終わらせず、「いつ、どこで、どの環境から、どの証跡を残して実行するか」まで設計した事例として読める。
E2E test は、ローカルで動くことと、リリースフローに組み込まれて安定運用されることの間に大きな差がある。 IP 制限や社内 network がある場合、Self-hosted Runner は現実的な解になる。 ただし、runner の権限、network、secrets、常駐 service、update、監視は運用対象になる。
要点¶
- 手動リグレッションテストがリリース頻度向上のボトルネックだった。
- Playwright で E2E テストをコード化しただけでは、手動起動の運用負荷が残る。
- IP 制限のある検証環境には GitHub hosted runner から直接アクセスできない。
- Self-hosted Runner は runner 側から GitHub に job を取りに行くため inbound port を開けずに構築できる。
- デプロイ完了 trigger、並列/順次実行、Slack 通知、Artifacts 保存を組み合わせた。
- Playwright report、動画、screenshot を Artifacts に残すと失敗調査が速い。
- リリース頻度は月3〜4回から月7〜8回へ増加し、手動リグレッション工数はゼロに近づいた。