Playwright導入で効率化！QAエンジニアが語るテスト自動化ツール入れ替え事例

ツール導入前の課題

• リリース毎にリグレッションテストを手動で実施していた
• ノーコードツールでの自動化は進んでいたが、長いシナリオを実行している場合や長時間動かしているとメモリが逼迫するためか同じシナリオでも理由が不明な失敗が出てしまうことがあった
• 急を要するリリースなどでスピードのブロッカーになってしまっていた
• 手動でのリグレッションテストに6〜8時間かかっていた
• ノーコードツールの限界（メモリ制限、ローカル実行困難、カスタマイズの柔軟性不足）に直面

どのような状態を目指していたか

• より安定で柔軟な自動化ソリューションの導入
• リグレッションテストの大幅な時間短縮
• リリーススピードの向上
• テスト実行の安定性確保

• 既存のMagicpodの継続利用
• Autify
• Selenium
• Cypress
• Puppeteer

1. 動作の安定性

   • 推奨環境での安定動作
   • ほぼすべてのテストケースが安定して動作すること

2. 学習コストの低さ

   • 段階的に学習できる環境
   • コード生成機能の有無

3. カスタマイズ性と柔軟性

   • 複雑な要件にも対応可能
   • 将来的な拡張性

4. 開発効率

   • コード生成機能による開発支援
   • 単純なテストであればブラウザ操作でテストコード生成が可能

• 自動ブラウザドライバー管理により設定が簡単
• より安定した実行環境
• 並列実行が標準でサポートされている
• コード生成機能による学習コストの軽減
• GitHubのスター数が高く、継続的な開発が期待できる
• アクティブなコミュニティ

改善したかった課題はどれくらい解決されたか

• テスト実行時間の大幅短縮: 6〜8時間 → 十数分（最適化後）
• テスト実行の安定性向上: メモリ逼迫などの原因不明の失敗がほぼ解消
• リリーススピードの改善: 急を要するリリースでのブロッカー問題が解消
• テストカバレッジの向上: 95%超えを達成

どのような成果が得られたか

• 品質向上効果: 実行時間の可視化により、テストケースの実装ミスを早期発見
• 開発効率の向上: より精密なテスト設計が可能になった
• チームスキルの向上: プログラミングによる自動化のノウハウを獲得
• CI/CD環境の構築: GitHub Actionsによる継続的なテスト実行体制を確立

コード管理の壁

• Gitの本格的なプロジェクト運用経験不足
• ブランチ戦略のベストプラクティスが不明

CI/CDパイプラインの構築

• CI/CDの概念は理解していても実際の構築経験がない
• GitHub ActionsのYAML設定ファイルの書き方

ファイルの肥大化問題

• 冗長的なコードの増加
• ベタ書きの山
• 同じような処理の重複
• DRY原則、SOLID原則の理解不足

テストの品質問題

• 「◯◯がないこと」のチェックポイント実装ミス
• ページ遷移失敗でもテストがパスしてしまう問題

最初から完成度の高いものを作ろうとすると、学習コストが嵩むため最初は最低限動作するものをという前提で進めておくと気持ち楽になります。

徐々に拡張していけるような作りを考えて置くと追加したい機能が出た時にスムーズに組み込めます。 具体的には、設定値をベタ書きせず変数化しておく、繰り返し使う処理は後で関数化できるように意識しておく、といった程度で十分です！ 必要なら後で修正すれば良いというぐらいの気持ちで進めても大丈夫です。

• サーバー負荷問題の解決
• 追加を見越して実行効率の更なる改善
• テスト品質の向上

などをさらに高めていきつつ新たな連携ができないか模索していきたいと考えています！