Playwrightを活用した機能開発のスピードを落とさないE2Eテストの自動化

導入背景

2023年の6月に新プロダクトを正式リリースしてから、スピード感を持って新機能の開発を進めてきました。

機能リリースのプロセスの中で開発エンジニアよる手動テストと、重要な機能や影響範囲の大きい場合はQAによる手動テストを実施しています。 QAの人数も限りがあるため、思ったようなスピードでリリースができない場合もありました。 また開発エンジニアによる手動テストの場合は、影響範囲を全て理解できてないことから、テストの漏れなどがあり、デグレが発生することもありました。

他にも、先行でAutifyを利用していましたが、下記の課題もありました。

• ドラッグ & ドロップの操作をテストできないため、一部の機能をテストできない
• 料金形態がテストの足枷となっている (実行回数の上限があるので本当にAutifyを使いたいチームに回数を譲った方が良い)

上記の背景から他のE2Eテストツールを検討し始めました。

比較検討したサービス

• Cypress
• Autify

比較した軸

• マルチタブを開いてテストできるか
• ドラッグ & ドロップの操作をテストできるか
• 料金形態で実行回数の上限がないか

選定理由

上記を実現できる点。 また、ローカルで実行できる点やコードベースで管理できるため、レビューのサイクルと含めやすく、条件に当てはまったPlaywrightを選定しました。

導入の成果

• ドラッグ & ドロップの操作をテストできるようになり、以前はできなった機能のE2Eテストも実行できるようになりました。
• 以前の課題でありました、手動テストによる確認漏れのいくつかは、E2Eテストによって未然に防ぐことができ、QAの負担も少しは軽減できたかと思います。
• 現状はAutifyとまだ併用していますが、PlaywrightのE2Eテストが充実化してきたため、Autifyの実行を他のチームに譲り、費用を削減する事が見えてきました。
• 副産物ですが、開発メンバーが自らE2Eテストを作成することによって、E2Eテストに関する知見が高まり、自動テストで問題を未然に防ぐ意識が向上したと思います。

導入時の苦労・悩み

Playwrightを使用経験のあるエンジニアがチーム内におらず、初期設定からテストを実際に書くまでは、手探りで行い少し苦労しました。 E2Eテスト自体が壊れやすいため、あまり複雑なテストはせずに、ハッピーパス（正常系の基本的な使用ケース）のテストを書くことにしました。

導入に向けた社内への説明

よく使う機能

ツールの良い点

ツールの課題点

今後の展望

今後は各環境でのE2Eテストの整備や、定期実行などをしていきたいと考えています。