Playwright導入で効率化!QAエンジニアが語るテスト自動化ツール入れ替え事例
株式会社COMPASS / Isuzu
チームリーダー / QAエンジニア
| 事業形態 |
|---|
B to B |
| 事業形態 | B to B |
|---|
アーキテクチャ

アーキテクチャの意図・工夫
最初はアーキテクチャを深く考えていませんでした。とにかくテストを書いて動かすことが目標でした。しかし、実際に運用してみて分かったことがたくさんあります。
失敗から学んだ4層構造の必要性
最初は全部をひとまとめに書いていました。テストファイルが100個以上になったとき、同じようなコードが重複していましたので、エンジニアの方と相談しながら整理したのが今の構造です。
共通レイヤー : 全サービス共通で使うもの
みんなで使う環境設定やAPI認証処理を上に持ってきたことで、重複するコードが減少しました。サービス層 : サービスごとに独立
サービスAのテストでサービスBが影響受けないように、完全に分けたことで、並列実行しても影響が少なくなりました。実行制御層 : テストをどう実行するかの設定
並列実行の設定やレポート生成など、「どう動かすか」を独立させました。インフラ層 : GitHub ActionsやCI/CD
実際にテストを回す環境の設定をしました。
Page Objectsを各サービスの最上位に配置
UIが変更されたとき、Page Objectだけ修正すれば全テストが直るんです。最初はベタ書きしてたので、ボタンのセレクタが変わるだけで大量の修正が必要でした。
実行時間短縮へ
6〜8時間かかっていたテストを十数分まで短縮するために、並列実行とシャード分散は必須でしたが、ただ並列にするだけだとサーバーの処理が間に合わなかったため細かく調整できるようにしました。
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
- リリース毎にリグレッションテストを手動で実施していた
- ノーコードツールでの自動化は進んでいたが、長いシナリオを実行している場合や長時間動かしているとメモリが逼迫するためか同じシナリオでも理由が不明な失敗が出てしまうことがあった
- 急を要するリリースなどでスピードのブロッカーになってしまっていた
- 手動でのリグレッションテストに6〜8時間かかっていた
- ノーコードツールの限界(メモリ制限、ローカル実行困難、カスタマイズの柔軟性不足)に直面
どのような状態を目指していたか
- より安定で柔軟な自動化ソリューションの導入
- リグレッションテストの大幅な時間短縮
- リリーススピードの向上
- テスト実行の安定性確保
比較検討したサービス
- 既存のMagicpodの継続利用
- Autify
- Selenium
- Cypress
- Puppeteer
比較した軸
動作の安定性
- 推奨環境での安定動作
- ほぼすべてのテストケースが安定して動作すること
学習コストの低さ
- 段階的に学習できる環境
- コード生成機能の有無
カスタマイズ性と柔軟性
- 複雑な要件にも対応可能
- 将来的な拡張性
開発効率
- コード生成機能による開発支援
- 単純なテストであればブラウザ操作でテストコード生成が可能
選定理由
- 自動ブラウザドライバー管理により設定が簡単
- より安定した実行環境
- 並列実行が標準でサポートされている
- コード生成機能による学習コストの軽減
- GitHubのスター数が高く、継続的な開発が期待できる
- アクティブなコミュニティ
導入の成果
改善したかった課題はどれくらい解決されたか
- テスト実行時間の大幅短縮: 6〜8時間 → 十数分(最適化後)
- テスト実行の安定性向上: メモリ逼迫などの原因不明の失敗がほぼ解消
- リリーススピードの改善: 急を要するリリースでのブロッカー問題が解消
- テストカバレッジの向上: 95%超えを達成
どのような成果が得られたか
- 品質向上効果: 実行時間の可視化により、テストケースの実装ミスを早期発見
- 開発効率の向上: より精密なテスト設計が可能になった
- チームスキルの向上: プログラミングによる自動化のノウハウを獲得
- CI/CD環境の構築: GitHub Actionsによる継続的なテスト実行体制を確立
導入時の苦労・悩み
コード管理の壁
- Gitの本格的なプロジェクト運用経験不足
- ブランチ戦略のベストプラクティスが不明
CI/CDパイプラインの構築
- CI/CDの概念は理解していても実際の構築経験がない
- GitHub ActionsのYAML設定ファイルの書き方
ファイルの肥大化問題
- 冗長的なコードの増加
- ベタ書きの山
- 同じような処理の重複
- DRY原則、SOLID原則の理解不足
テストの品質問題
- 「◯◯がないこと」のチェックポイント実装ミス
- ページ遷移失敗でもテストがパスしてしまう問題
導入に向けた社内への説明
上長・チームへの説明
PoC(概念実証)の実施
- ベースとなるコードを作成してUI上での動作確認を実施
- 実際に動作する様子を上長・チームに実演
効果の定量的な試算
- ある程度作成したコードを直列実行で実行
- 従来の手動テスト(6〜8時間)と比較した工数削減効果を試算
- 一定以上の効果が発揮されることを数値で証明
導入判断
- 定量的な効果が確認できたため、本格導入に踏み切った
活用方法
自動実行による品質保証
- デプロイをベースとした自動実行
- リグレッションテストでの欠陥発見
リリース時の動作確認
- リリース後のチェックシナリオを作成
- リリース時の動作確認に活用
- 本番環境での品質保証
よく使う機能
- レポート機能
- デバッグ機能
ツールの良い点
- カスタマイズ性が高い
- 単純なことであれば学習コストは低め
- 実行時間の効率化
- ローカル環境での実行が容易
ツールの課題点
- 複雑度の高いことを考えると必要な技術レベルと学習コストが嵩む
- 気にせず作ってしまうと複雑化してメンテナンス性が低下する
- iPadの端末での実機操作に対応していない
ツールを検討されている方へ
最初から完成度の高いものを作ろうとすると、学習コストが嵩むため最初は最低限動作するものをという前提で進めておくと気持ち楽になります。
徐々に拡張していけるような作りを考えて置くと追加したい機能が出た時にスムーズに組み込めます。 具体的には、設定値をベタ書きせず変数化しておく、繰り返し使う処理は後で関数化できるように意識しておく、といった程度で十分です! 必要なら後で修正すれば良いというぐらいの気持ちで進めても大丈夫です。
今後の展望
- サーバー負荷問題の解決
- 追加を見越して実行効率の更なる改善
- テスト品質の向上
などをさらに高めていきつつ新たな連携ができないか模索していきたいと考えています!
株式会社COMPASS / Isuzu
チームリーダー / QAエンジニア
よく見られているレビュー
株式会社COMPASS / Isuzu
チームリーダー / QAエンジニア
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法


