こんにちは！estieでQAエンジニアをしているかすや（macho | きんにQA💪🏾 (@ma_cho29) / X）です。
今回ブログを書くにあたり、前回書いたのはいつだったかなー？と見返すと1年が経過していたことに気がつきました。
歳を重ねると体感時間が短くなると聞いたことがありますがそれでしょうか・・・
入社3年目になる今年もやり残しがないように過ごしたいところです。
さて、今回はQA未経験だった私が1人目のQAエンジニアとしてestieに入社し現在までおこなってきたE2Eテスト自動化の変遷について語っていきたいと思います。
私がメインで関わっているプロダクト「estie マーケット調査」は約2年間でテストフレームワーク移行を2度おこないました。
当時の意思決定やその際に個人的に感じたフレームワークごとのメリット・デメリットなど含めて話したいと思います。
（あくまで僕の所属する開発チームで当時感じたメリット・デメリットになります）
一つずつ深ぼっていきましょう。
ノーコードツール から Cypress への移行
私の入社する前からestieではノーコードツールが導入されており、最低限のテストが数本、定期的に実行される状態でした。
そのため、入社後はノーコードツールを使って実装・運用をしていましたが、本格的にQA活動を進めていく中で課題が発生し、移行を検討することになりました。
ノーコードツールのメリット
メリットはなんといっても実装コスト・初期学習コストの低さです。プログラミングが得意でない僕でも見よう見まねで最低限のテストが実装できました。
今思い返すと実行結果や履歴がブラウザ上から閲覧できるのも良かったです。
あとは疑問点不明点があったときに問い合わせた、カスタマーサクセスの方々の対応が手厚いこともメリットの一つでした。
「こういうことがしたいです」って感じの雑な問いかけに対しても、具体的な提案とセットでテストコードの例まで書いていただいた時はとても助かりました！
Cypressへの移行動機
ノーコードツールを使うメリットは多い反面大きく3つのを抱えていました。
実行回数制限があり使いたい時に使えない
契約プランの関係もありますが実行回数に上限があったため本来やりたいことができない場面がありました。
例えば、複数のプルリクエストをQA・リリースする際に本当はそれぞれを検証環境にマージする前にリグレッションテストを回してデグレードが発生していないことを確認したいところですが、回数制限があるため検証環境に複数まとめてマージし、そこで一度でテストを実行していました。
その場合テストが失敗した際にどのプルリクエストが原因でデグレが起こっているのか特定する作業が追加で必要になります。
SWE（ソフトウェアエンジニア）との親和性がイマイチ
estieでは品質活動にQAだけでなくSWEも関わっていこうという方針をとっているため、実装・運用を開発チームで協力していきたいと考えていました。
その上で機能実装と同時にテスト追加、修正ができない（GUI上でテスト実装しなければいけない）こと、やノーコードツールで作ったテストはバージョン管理が出来ない点（私ができることを知らないだけだったらごめんなさい！）は、エンジニアとの親和性が少し低かったかなーと感じました。
ノーコードツールとはいえコーディングも必要だった
ノーコードツールといえど、実現したいテスト全てが作成できるわけではなく、コードを書く必要が多々ありました。
そのため、コーディングスキルが必要となる場面が多く、1から自分で書けるようになった方が、QAエンジニアとしてのスキルアップ的な面と、テストの自由度の面でも、良いのでは？と思うようになりました。
CypressからPlaywrightへの移行
次にノーコードツールで感じた課題を解決するためフレームワークをCypressへ移行しました。
当初の課題が少しずつ解消されていく一方、新たな課題も出てくるように…
Cypressに移行したことによるメリット
Cypressに切り替えてE2Eテストでできる幅が大きく広がったと感じました。
テスト回し放題！！
当初一番課題を感じていた実行回数の制限から解放されたことが一番大きいメリットだったと思います。
以前の反動からかリモートブランチにコミットするたびにテストが走るように設定していたのですが、今思い返すとさすがにやりすぎだったかもしれません（笑）
JavaScriptベースでSWEにレビューをしてもらいやすい
Cypressでは独自のコマンドはあるもののJavaScriptベースとなっています。
そのため、QAが1人しかいない組織でもテストコードのレビューをして貰えるのは大きなメリットとなりました。
僕自身のスキルアップになった
これは個人的なメリットですが、コーディング経験少なかったけど興味があった私にとってテストコードを1から書くことはとても楽しく自分自身のスキルアップになったことは大きなメリットだと思いました。
CIへの組み込みなどもサポートをもらいつつですが経験できたのは僕にとって大きかったです。
Playwrightへの移行動機
Cypressに移行したことによるメリットもたくさんあったものの、課題はいくつかありました。
有償プランでないと並列でのテスト実行ができない
E2Eテストのボリュームが増えてくると問題になるのがテスト実行時間です。
並列でテストを実行することができれば実行時間を短縮することができるのですが、Cypressの無償プランは並列実行をサポートしていませんでした。
私のチームでもCIでのテスト実行時間が徐々に延びてきて、一番時間がかかっていた時期でビルドからテスト実行完了まで30分以上かかるようになっていました。
これはスクラム開発でこまめにリリースをしていく私のチームにとって課題になっていました。
マルチタブ操作ができない
これが、フレームワーク選定でCypressを選択する際に注意すべき点だと思います。
私の担当しているプロダクトでは別タブでウィンドウを開く振る舞いが頻繁に発生するため、できた方がスムーズにテストができるのになーと思うことがよくありました。
コーディングの必要性が増し実装コストが上がった
こちらは直接的にPlaywrightへの移行動機となったわけではないのでどちらかというとノーコードツールと比較してのデメリットになります。
当然のことながらCypressを使うことで、ノーコードツールではコーディングが不要だった箇所もコーディングをすることが必要になります。
そのため従前と比べるとどうしても実装コストが少し高くなってしまいました。
その点はPlaywrightでも同様なのですが、上述した動機の2点含め移行する方がメリットがあると判断しました。
CypressからPlaywrightへの移行
そして現在運用をしているPlaywrightへと移行していくことになりました。
Playwrightとは
PlaywrightはMicrosoftが開発しているE2Eテストフレームワークです。
CypressからPlaywrightに移行したというような話をよく耳にするようになり今勢いのあるフレームワークだと個人的に感じています。
最近も少し過激なタイトルでこんな記事が流れていました。
Playwrightに移行したことによるメリット
テスト実行が高速！
Cypressも実行速度は高速だと思いますが比較してもPlaywirghtはさらに速いなーという印象です。
さらにPlayrightではテストを並列実行することもできるのでテスト同士の依存性をなくせばさらに高速化することが可能です。
他社さんでCypressとPlaywirghtの速度比較をしたところでは実行速度が3分の1になったと書かれている記事も以前見たことがあるので驚いたのを覚えています。
Test generator が優秀
Cypressにも類似の機能はありますが、Playwrightにはブラウザ操作を記録してコードを生成するVSCodeのプラグインがあります。ノーコードツールのようにある程度のコードを自動で生成してくれるのは強いです。
まずはざっくりと画面録画でテストコードの大枠を生成して適宜コードをリファクタリングしつつ足りないアサーションを追加することでCypressよりも高速でテストが実装できます。
VSCode内でボタンひとつでテストが実行でき、ログの出力やブレークポイントを使ったデバッグが簡単にできるのが気に入っています。
実際に僕の担当しているプロダクト「estie マーケット調査」でTest generatorを使ってコードを生成してみます！
【テストシナリオ】
- 「estie マーケット調査」にログインする
- ビルを条件検索する
- 検索結果からリストを作成する
- 作成したリストを表示しビルの詳細ページへ遷移する
↓実際に生成されたコード（わかりやすいようにコメントを差し込んでいます）
import { test, expect } from '@playwright/test'; test('test', async ({ page }) => { // ログインページにアクセス await page.goto('http://localhost:3003/login'); // メールアドレス・パスワードを入力しログイン await page.getByPlaceholder('メールアドレスを入力してください').click(); await page.getByPlaceholder('メールアドレスを入力してください').fill('email'); await page.getByPlaceholder('現在のパスワードを入力してください').click(); await page.getByPlaceholder('現在のパスワードを入力してください').fill('password'); await page.locator('a').filter({ hasText: 'ログイン' }).click(); // 検索条件を入力しビルを検索する await page.locator('label').filter({ hasText: '建物' }).locator('span').click(); await page.getByPlaceholder('建物名を入力してください').click(); await page.getByRole('button', { name: '日比谷FORT TOWER 東京都港区西新橋1丁目1-1' }).click(); await page.getByRole('button', { name: '検索', exact: true }).click(); // 検索結果からリストを作成する await page.getByRole('button', { name: 'リストに追加' }).click(); await page.getByRole('button', { name: '新規作成' }).click(); // 作成したリストを確認し、ビルのリンクをクリックしてビル詳細ページに遷移する await page.getByRole('button', { name: 'リストを表示' }).click(); const page1Promise = page.waitForEvent('popup'); await page.getByTestId('buildingMiniCard-buildingLink').click(); const page1 = await page1Promise; await page1.getByRole('heading', { name: '日比谷FORT TOWER' }).click(); });
優秀ですよね！！
これで大枠を作って必要なアサーションを追加しリファクタリングすればテストが出来上がります。
様々な言語をサポートしている
PlaywrightはJavaScript、TypeScript、Python、C#など複数の言語を使うことができます。
私の担当しているプロダクトではTypeScriptが使われているのでそれに合わせてTypeScriptを使ってテストを書いています。
TypeScriptでテストを書くことは型安全性の点でメリットがあると感じました。
テストコードを書いている中で型エラーを事前にキャッチできるので助かっています。
まとめ
QAエンジニアとしてのキャリアにおいて短期間で複数のE2Eテストフレームワークに触れることができたのは、それだけ移行コストがかかってしまった反面、それ以上に学びと成長の機会となりました。
どのフレームワークが最適かはプロジェクトや状況により異なりますが、移行するたびにE2Eテスト自体も現状にマッチした形にブラッシュアップされ良いものに成長していることを実感しています。
estieでは他のプロダクトでもE2EテストフレームワークをPlaywrightに統一が始まっており、それぞれのプロダクトで得たナレッジを会社全体で共有できることも大きなメリットだと思います。
もう少しナレッジが貯まったら次回はPlaywrightのTipsまとめてを書いてみたいです。
最後に
estie では、Whole Product 構想を掲げ、新規プロダクトを次々に立ち上げて同時に走らせています。
増え続けるプロダクトの品質を担保していくには私1人の力では限界があります。
一緒に最高のQA組織を立ち上げ、estieの品質を作り上げてくださる方を募集中です。
選考にエントリーしたい方は以下から、
まずはカジュアル面談から気楽な気持ちで…という方は以下から申し込みをお願いします！
