Playwrightでシナリオテストを自動化し、安全かつスピーディなリリースサイクルを回す

ツール導入前の課題

手動テストの限界

プロジェクトが発足して以来自動テストを導入していなかったため、プロダクトオーナー（以下PO）によるシナリオテストがリリース時に手動で行われていました。半日〜1日の工数が割かれており、数か月に一回のリリースならなんとか手動テストで耐えられるかもしれませんが、リリース頻度が増え、機能が増えると、毎回の手動テストは大きな負担になります。 リリース頻度を増やして継続的に開発したものをデリバリーするためには、自動テストを導入して手動テストに割く工数を減らす必要がありました。

リリースの遅延

自動テストで不具合を検知する体制が出来ていなかったため、シナリオテストで不具合が見つかり修正作業が必要になることも頻発していました。そのため、計画通りに本番環境への反映が行われない事態が発生するだけでなく別機能の開発スケジュールにも影響が出ていました。

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

上記のような課題から、以下の状態を目指しました。

• リリースの安全性と高速化: 毎リリースで一定の品質を担保し、安全かつスピーディにリリースできる体制を構築する。
• 修正コストの削減： 不具合を事前に検知することで、修正にかかるコストを下げる。

• mabl

• 実行速度
• 運用コスト
• 学習コストや保守性

• 実行速度の速さ: E2EテストはフロントエンドからDB層までの一気通貫で検証を行うので実行時間が長くなりがちですが、Playwrightは実行速度が速いため、効率的にテストを行うことができます。
• 管理とレビューのしやすさ: 開発メンバーが実装・メンテナンスを行うのでコードベースのPlaywrightの方が馴染みやすいという点や、レビューの観点でも差分の確認などがしやすいというメリットがありました。
• Cucumberとの組み合わせで仕様書とテストコードを一元管理：Cucumberというテストシナリオを自然言語で書くことができるテストツールと併用することで、テストコードを仕様書としても管理することができます。当初はPOがテストを実行する想定だったため、開発メンバー以外、特にプロダクトに関わるPOにとっても内容を認識しやすいという点がメリットに感じました。
• クロスブラウザ対応: PlaywrightはChrome以外にもFirefoxやSafariに対応しています。異なるユーザー環境に合わせて検証を行える点も大きな評価ポイントでした。
• コスト: 上記に加え、Playwrightはオープンソースのため、テストが増えたとしてもCI以外でコストがかからない点も利点です。

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

• 2,3か月ごとにリリースしていたものを1か月ごとのリリースに短縮されました。
• リリース直前に検知されていた不具合が開発段階で分かるようになったため、リリース直前の手戻りとそれにより起こるスケジュール遅延が8割減少しました。
• 自動化できていない機能については手動テストを行っているものの、半日以上かかっていた工数が数時間に短縮されました。

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

• リリース時の手動テストを大幅に削減できました。
• 開発中にもテストできるようになったため早期に不具合を検知できるようになりました。

• プロダクトが大きくなり機能も増えたことで、テストの実行時間が導入時より長くなってきていることに課題を感じています。並列実行などを組み込んで実行時間の短縮化を図りたいです。
• Playwright MCPも出たようなので、テストの作成自体も自動化して効率化を目指したいです。