UPSIDERでテスト自動化を担当しているQAエンジニアのeriです。
この記事では、PlaywrightとMagicPodを併用しながら自動化を進めてきた1年間の試行錯誤を、包み隠さず紹介します。
冗長なテストと膨らむ実行時間
当初、MagicPodを中心に自動テストを構築していましたが、テストケースの増加とともに以下のような課題が出てきました。
- テストシナリオが冗長化し、実行時間が長くなる傾向
- 30項目のテスト実行に約5時間かかっていた
- より細かい制御が必要になるケースが増加
- MagicPodのGUIでは表現しづらい、条件分岐などの細かな処理
- テスト対象の拡大
- E2E対象の増加により、テストの拡張性が求められた
そんな背景から、「そろそろ別のアプローチも必要では？」と話し合うようになりました。
理想とする状態を設定する
闇雲に自動化を進めても意味はないため、まずは理想像を明確にしました。
- リリース前の手動リグレッションテスト工数を削減する
- 自動テストの高速化により、hotfix時の迅速な品質チェックを可能にする
- 各ツール内で並列実行を実装し、実行時間を短縮する
- メンテナンスコストを抑え、コーディングをしたことのないQAエンジニアも運用可能にする
PlaywrightとMagicPodを“併用”することにした
理想像を踏まえ、まずはPlaywrightによる自動化に着手することにしました。
既にMagicPodで実装しているテストもありましたが、それはそのまま継続運用することにしました。
というのも、Playwrightでの実装は初めてで、どれくらいの工数がかかるか未知数だったからです。 また、インシデント対応など即時対応が求められるケースにはMagicPodのほうが適していると判断しました。
「スピードを重視して、まずやってみる」姿勢で取り組みました。
そのため、最初から非常に細かいルールを決めて自動化を進めるというやり方はとっていません。
先行事例は参考にはしつつも、実際に使いながら「こうやっていくと良さそう」という方向に少しずつやり方を変えてきました。
ツールの使い分け
| ツール | 具体的な用途 |
|---|---|
| Playwright | 一般的なリグレッションテスト、UIの動作検証, メール認証、認証を含むログインなど高速で確認しやすい項目 |
| MagicPod | UIの視覚的変化チェック、インシデント対応、そして、環境への依存度が高くPlaywrightでは実施が難しいテスト |
Playwrightでの自動化が進むにつれ、MagicPodで対応していたテストの一部をPlaywrightへ移行することにも取り組みました。
「どちらかに統一する」ことよりも、目的に応じた使い分けで効率よくカバーする方針です。
Playwright × GitHub Actions × Slack連携で構築した自動実行フロー
当初から下記のフローを構築して実行していました。
- 毎日深夜にGitHub Actionsで定期実行
- 結果をSlack通知し、朝に失敗箇所を確認
- 失敗原因を記録し、修正やリカバリーにつなげる
- 例：初期設定状態に戻す方法を記載することにより再実行が可能になる
途中から以下も追加しました。
- 機能の改修頻度が少なく、テスト環境に負荷がかかるテストについては週次実行に変更
- テスト単体・ファイル単位でGitHub Actions上から実行可能な仕組みに
Playwrightで途中から取り入れたこと
- Cursorの導入
- 開発メンバーが既に使用しており、QA向けにカスタマイズ
- 今まで作ったコードを学習しているため、実装速度がアップ
- 並列実行できるように環境構築をし直す
- テスト対象の企業アカウント・カード設定などを分離して、テスト同士が干渉しない構成に
自動化によって得られた効果と実感
達成できたこと
☑️リリース前に実施する手動でのリグレッションテストの工数を削減する
☑️自動テストの実行時間を短縮し、hotfix時の対応力を向上
☑️hotfixの時に自動テストを実施して確認をできるようになった
☑️リグレッションテストを分解・並列実行 し、自動化数を増やす
まだ課題が残る部分
- メンテナンスコストを抑え、コーディングをしたことのないQAエンジニアも運用可能にする
自動化の実績
| 実行者 | 実装数 | 実行時間 |
|---|---|---|
| MagicPod | 26 → 40 | 約5時間 → 約1.5時間 |
| Playwright | 0 → 270 | - → 約1.5時間 |
| 手動（4人） | - | 2日 → 約1日弱 |
※手動の時間は、開始当初に必須だった項目の確認にかかる時間です。
カバレッジ改善と副次的効果
- カバレッジ：約40%まで向上（母数が増減する中でも継続的に整備）
- 開発中の不具合検知が可能に（データ不備や副作用を早期発見）
課題と今後取り組むこと
- Webでの自動化が完了したため、Appのリグレッションテスト自動化を開始(iOS/Android)
- コード改修による安定性向上（リカバリー処理を含む）
- 可読性・メンテナンス性を高めるコード修正
- AIによる自動改修対応
正直、もっと上手くできたところもあったかもしれません。 でも、その都度チームで話し合いながら一歩ずつ前進してきました。これからも少しずつ改善を重ねて、誰でも使える、安定した自動テストの仕組みを作っていきたいと思っています。 読んでいただきありがとうございました！
