Playwright導入（ノーコードツールとの併用事例）

ツール導入前の課題

弊社ではMagicPodを活用した自動テストを行っていましたが、テストケースの増加に伴い、以下の課題が発生しました。

• テストシナリオを冗長に作ってしまったため、実行時間が長くなりがち
  • 30項目のテスト実行に 約5時間かかっていた
• より細かいカスタマイズが必要な場面が増えてきた
  • 一部のシナリオでは、コードベースでの細かい制御が求められた
• テスト対象の拡大
  • E2Eテストの対象が広がる中で、テストの拡張性を高める必要があった

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

• リリース前に実施する手動でのリグレッションテストの工数を削減する
• 自動テストの実行時間を短縮し、hotfix時の対応力を向上
• リグレッションテストを分解・並列実行 し、自動化数を増やす
• メンテナンスコストを抑え、コーディングをしたことのないQAエンジニアも運用可能にする

• MagicPod（※現在、継続利用中）

• 実行速度（テスト時間の短縮）
• メンテナンスのしやすさ
• テストの拡張性（柔軟なカスタマイズが可能か）
• コスト（テスト数増加時の費用負担）

• 実行速度が速かった
• 変更に強く、テストの安定性が高い
• オープンソースのため、テスト数が増えても追加コストなし

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

• 8割解決

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

• 実行時間約5時間 → 約1時間に短縮
• 170ケースを自動化
• hotfix対応の時も自動テストで確認ができるようになった
• 失敗したケースの再実行や原因調査が迅速化

※ただし、MagicPodは継続利用しており、Playwrightと併用中です。

導入前は、全部をPlaywrightに移行することを考えていましたが、MagicPodのノーコードによる柔軟なテスト管理や、Visual Regression Test、メールテストの強みは引き続き活用したいとなったため下記の様な使いわけを行っています。

ツールの使い分け

• QAエンジニアがコードベースのテストをメンテナンスできるか
• Playwrightの学習コスト（ノーコードツールに比べ、最初の学習が必要）
• チーム全体での知識共有が必要だった

• MagicPodのようなノーコードツールとの併用を検討するのもアリ
• 実行速度と拡張性を重視するならPlaywrightは最適
• 環境構築などの資料を並行して作成すると便利

• MagicPodとPlaywrightの使い分けをさらに明確化
• コーディング経験がないQAエンジニアでもPlaywrightのメンテナンスをできるようにする