Playwrightを活用して8つのシナリオ・112個の項目のテスト自動化に成功

ツール導入前の課題

数ヶ月程度の開発期間のなかで、フィードバックの収集と並行して機能の実装を行う必要がありました。フィードバックの内容によっては、既に実装がおわった機能の仕様を変更することもありました。

はじめはスプレッドシートにテストシナリオとテスト項目を記入して、複数人で手動テストを分担する方法を考えました。しかし、解釈が人によって違ったり、操作を間違えたりすることが考えられたので、ある程度自動化できればよいと思うようになりました。

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

• シナリオテストを誰が実行しても同じ結果が得られるよう自動化されている
• テストシナリオをソースコードで管理し、リグレッションテストとしても使用できる

• スクリプト言語による自動化

• チームメンバーとテストシナリオを共有できること
• テストシナリオのソースコードをバージョン管理できること
• ソースコードの作成の自動化や再利用することでシナリオテストにかかる工数を削減できること

Test generatorの機能を使って、画面の操作をJavaScriptのソースコードとして生成することができます。 個人的な感想ですが、生成されたソースコードは直感的にわかりやすく、ソースコードを見てどのような操作をしているのか理解しやすかったというのもPlaywrightを使ってみたいと感じたポイントです。

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

最終的に、Playwrightを使って8つのテストシナリオ、112のテスト項目を自動でテストできるようにしました。

さらに、上記のテスト項目を自動テストに落としこむ過程で、当初想定していなかった例外フローやテスト項目にあげていない細かな挙動の差異を発見でき、品質向上の大きな助けとなりました。

実行時間という点では、ひとつのテストシナリオを実行が数十秒〜数分で完了できるようになり、全てのテストシナリオを10分程度できるようになりました。

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

本番リリース前に全てのテストシナリオを完了するだけでなく、テスト項目にあげられていなかった問題を効率よく発見することができました。

また、代替フロー・例外フローのテストのために前提となるテストデータを作成するのが大変だったのですが、Playwrightを使うことで手動でデータを作る作業をすべて自動化することができました。

Test generatorで生成されたソースコードは基本的にはそのまま自動化されたテストシナリオとして使えました。 ただ、リダイレクト処理などで画面遷移中にテストが失敗してしまうことがあり、そのようなときはTimeoutsを入れたりソースコードを直接書き換えたりする必要がありました。

Playwrightでブラウザ上でのちょっとした操作を自動化することは、様々な用途に応用できると感じました。 一方で、今回はシナリオテストを継続してメンテナンスする必要がありませんでしたので、1〜2ヶ月程度の短い期間に運用するものを割り切って導入しました。そのため継続してメンテナンスがしやすいかどうかの評価はしていません。 Playwrightは、OSSとして公開されているツールなので、費用的な制約を考えずに試していただきやすいと思います。実際に使って操作感を確認いただき、判断いただければと思います。

今回の導入では、短い期間の運用ということもありCIパイプラインに組み込むようなことはしませんでした。よりプロダクトのコアな部分に導入し、継続した運用に挑戦してみたいと思いました。

また、継続的に運用してゆくときには、ユニットテストにするかE2Eテストにするかといったテスト手法の使い分けも明確にできればよいと考えています。