Playwrightでテストを一部自動化し、テスト工数と不具合発生率を同時に減らす
株式会社イノベーション / miyaken0805
チームリーダー / フルスタックエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
---|---|---|
10名以下 | 2024年7月 | B to B |
ツールの利用規模 | 10名以下 |
---|---|
ツールの利用開始時期 | 2024年7月 |
事業形態 | B to B |
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
1.既存E2Eテストの品質低下
数年前にE2Eテストツールとして、Jest + Puppeteerが導入されていましたが、最新ブラウザに対応しなくなり、実行結果も不安定なFlakyテストとなってしまったため、実活用できなくなってました。また前回の導入工数が結構かかったこともあり、新しいツールの選定と導入に対する腰も重くなってました。
2.手動テストによる開発工数の減少
弊社開発チームのリリース前に行うテストの一つとして、サービスの根幹機能に関する箇所の総合テストを行なっています。 前述のJest + Puppeteerは、速度とFlakyさの観点で逆にテスト効率が悪くなってしまう側面があったため、全て手動で行なっていました。 そのため持ち回りの担当者が、毎回半日、多くて1日かけてテストするため、本来の開発に割ける時間がその分減少していました。
3.重要ドメインの不具合増加
細かく見ているとはいえ、テストカバレッジは担当者のドメイン知識等の経験に依存してしまうので、見落としが増えて細かい不具合はよく起こっていました。
どのような状態を目指していたか
上述した課題があったので、以下のような状態を目指していました。
- なるべく工数をかけずに、新しいe2eテストツールを導入できている
- テスト速度が早く、Flakyになりにくいe2eテストが実装できている。
- 開発者のテストに対する負担が減っている。(=テストにかける工数が大幅に削減できている)
- 重要ドメインの不具合率が減っている。
比較検討したサービス
- Cypress
- Selenium
比較した軸
- テスト速度の速さ
- 環境構築のしやすさ
- テストの書きやすさ
選定理由
1.テストの並列実行が無料で行える
Playwrightは、テストの並列実行が無料で可能であり、コストをかけずにより速くテストを行うことができるという点は大いに惹かれたポイントでした。
2.コマンドオンリーで雛形の環境を構築することができる
少ないコマンドでテスト環境を構築することができる点は、環境構築のしやすさという点でとても惹かれました。
3.UI ModeやCodegenで直感的にテストコードが書ける
テストコードをメンテナンスしやすくするためにも、テストを書くハードルを下げたかったので、GUI上で直感的にテストを書くことができる点も惹かれたポイントでした。
4.Microsoftが開発およびメンテナンスを行なっている
Microsoftによって盛んにメンテナンスがされていて、ツールが終了せず継続的な活用が見込める点も大きなポイントでした。 実際にコードを書く際の言語であるTypeScriptもMicrosoftが開発しているものなので、今後TypeScriptに破壊的変更が加わった際もアップデートを行いやすいかなと思いました。
導入の成果
半年間運用してみて
どのような成果が得られたか
1.E2Eテストの品質大幅向上
Playwrightにしたことで、技術スタックをモダン化でき、最新ブラウザに対応できたため実運用可能になりました。 また、テストの速度をJest + Puppeteer時に比べて約1/5に減らすことができ、動作もE2Eテストツールの中では比較的軽いため、Flakyになりにくい健全なテストを生み出すことがしやすくなりました。
2.テスト工数の大幅削減による開発工数の増加
今まで半日、多くて1日かかっていたテストが、E2E導入後、諸々含めても最低で30分程度で終わる程に大幅削減できました。
3.重要ドメインにおける細かな不具合の減少
テスト担当者に左右されずに機械的にテストを行えるようになったため、今までより重要ドメインの不具合が減り、その点における心理的負担も少し軽減されたかなと思います。
4.テスト時に確認する項目を減らせた
テスト担当者は、E2E含めて行なったテストをまとめて行うようにしていたものを、プルリクエスト上でテストレポート結果を残すようにしたので、テスト時に確認する項目を減らせました。 これによって更にテストにかける時間を削減でき、より開発に集中できるようになったのかなと思います。
導入時の苦労・悩み
前述した通り少ない工程で導入が可能且つ、他社の導入事例記事も豊富だったため、特に困った点や詰まった点はありませんでした。
導入に向けた社内への説明
上長・チームへの説明
- 上記の課題についてはチーム内共通認識だったため、Playwrightと他ツールの比較、導入イメージを伝え、その後の運用計画は上司と相談して決めました。
- その後、当時はスクラム開発を行なっていたので、スプリントレトロスペクティブでチーム内に周知しました。
活用方法
- リリースする前のテストを行う際に、各リリース担当者がコマンドを叩いて、本番同等の環境に対してテストを行なっています。
- テストレポートを出力して、リリースプルリクエストに添付し、エビデンスとしています。
よく使う機能
1.Codegen
GUI上でした操作をそのままテストコードに落とし込める、いうまでもなく神機能です。
2.Playwright Test for VSCode
Playwrightの機能というよりエディターの拡張機能だが、これを使うとエディター上でテストが実行できるので、コード書く度にnpmコマンドでテストする必要がなくなります。とても便利。
3.Test Report
テスト結果をレポートに出力してくれます。スナップショットやビデオも同時に出力されるので、どこでどのようにテストが落ちているかのデバッグがしやすいですし、エビデンスとしても使えます。弊社ではプルリクエスト上でテストレポート結果を残すようにしております。
ツールの良い点
- 公式ドキュメントの内容が豊富で、書籍や記事等も多く、導入がとても簡単な点かなと思います。
- 他のE2Eテストツールに比べて、並列実行ができることもあり、実行速度がとても速いです。
- Codegenなどでテストが直感的に書けて、テストコードのハードルを下げてくれます。
ツールの課題点
ABテストが絡む開発部分はflakyになってしまう
フォームでABテストを行なっている場合、それによって出てくるDOMが違うこともあり、「Aパターン想定でテストコードを書いてたら、実際にテストでブラウザ開いた時はBパターンがきたんで落ちる」みたいなことがあったりします。 対策として、テストを3回までならリトライするようにしてますが、潜り抜けて落ちることもあるかもなので、そこら辺は割り切るか、どうにかするかしたいところです。
変更が多い箇所はメンテナンス頻度が多くなる
社内管理画面側で編集して公開したものがDOMに反映されるような箇所のテストは、編集が行われる度にテストの方も修正を加える必要があります。変更頻度が多い箇所は中々面倒です。 テスト用のダミーデータを作成して対応するとかなんとかしたいところです.
ツールを検討されている方へ
PlaywrightはE2Eテストに必要な機能がオールインワンに揃っているとても優秀なツールです。 導入の際はツール自体の料金は0円なので少しの人件費しかかからず、費用対効果が凄まじいので、めちゃくちゃお得かなと思います。 まずはお試しでもいいので、とりあえず取り入れてみて効果検証を図ってみてはいいのではないでしょうか。
今後の展望
- 現状はCIに組み込んでいないので、後々は組み込みたいなと思っています。
- 最近Playwright MCPもリリースされ、このツール自身が現代Tech業界の変化に合わせて成長してきています。例えばAIエディターのCursorとPlaywright MCPを組み合わせて、E2Eテストを完全自動生成してみるなど、更に活用の幅を更に広げていけたらいいなと思ってます。
株式会社イノベーション / miyaken0805
チームリーダー / フルスタックエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
よく見られているレビュー
株式会社イノベーション / miyaken0805
チームリーダー / フルスタックエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名