こちらのイベントにオンライン参加しました↓
E2Eテスト自動化の事例4選 Playwright活用編 - connpass
参加のきっかけ
Playwrightはがっつり使っているわけではないものの、現QAで元テスト自動化エンジニアとしてはおさえておきたい話だなーと思ったので参加しました。昼休みイベントありがたい。 あとは社内でVRTやりたいねという話が一部であり、参考になりそうだなと思ったのもきっかけのひとつです。
会の概要
4名の方のトークでした。
StotybookからはじめるVRT -個人開発編
arrow2nd @_arrow2ndさん ちょっと株式会社 フロントエンドエンジニア
今回は所属元のプロダクトの話ではなく、個人開発したサービスでのVRTのお話でした。
yondako | “よんだこと”をわすれないという読書記録サービスを作っているそうで、なんと3ヶ月くらいで作ったとのこと。（開発者はこういうの作れるのがうらやましい）
素人としては「えっ、個人開発でもVRTまでやるんだすごいな」と最初感じたのですが、
- デザイン頑張ったので壊れてほしくない
- 個人なので時間に限りがある
- コンポーネントや関数の単体テストだけだと心配
- 時間かけずに効果的なものはStorybookのVRTかも、と思い立った
といった点でVRTをPlaywrightでやることを決めたそうです。時間に限りがあるゆえに、というのは開発経験があってこその発想かもしれません。
効果的に行うための工夫もされているそうです。
たとえば新しいコンポーネントを追加してテストを実行すると、そのままだとテストが失敗します。VRTで過去と現在を比較するにあたって、初回は「過去」の画像が無いから、ですね。この対処として、比較対象のスクリーンショットがあるものだけテストするようにしているそうです。
サービスのリポジトリも公開しているとのことで、知りたい方はこちら→yondako/yondako: 🐙 よんだことをわすれないための読書記録サービス
もちろんVRTさえあればOK！と思ってらっしゃるわけではなく、見た目が変わってないけど内部が壊れてる、という可能性はあるにせよ見た目という切り口での安心感は得られており、直近だとTailwindのバージョンアップ時に役立ったとのことでした。たしかにUI関連するもののバージョンアップ時なんかはVRTあると安心そう。
StorybookとPlaywrightではじめるインタラクションテスト
中山 晶平(nakker1218) @nakker1218さん 株式会社enechain ソフトウェアエンジニア
enechain社ではエネルギーのマーケットプレイスを運営しており、中山さんは取引を管理する社内システムを担当しているそうです。この社内システムでは、ユーザーがミスなく素早く操作できるようポップアップやショートカットなどが大事で問題があると事業影響が大きい・・・ということなのですが、ここでバグが発生していたと。
一方ですべて手動テストで担保するのは無理なので、自動テストをしよう、ということになったそうです。
自動テストの戦略として、
- End to Endテスト：MagicPod
- インタラクションテスト：Playwright
という棲み分けになっていて、
- 実際のブラウザ上でテストができる
- Storybookとの組み合わせでコンポーネントに対してテストができる
- VS Code Pluginが強力
- 別プロダクトで導入事例があった
といったポイントでPlaywrightを導入したそうです。社内での導入事例があるのは大きいですよね。
インタラクションテストを実現したことで、人手でのQA工数を低減しつつデグレの早期発見につながった一方、CI時間が延びたりテストを書いて更新するコストが高いなどのデメリットも発生。CI時間削減のため、分割実行や変更に関係ないコンポーネントをテストしないようにするなどの工夫をしているそうです。
最後のほうにおっしゃっていた「コストに見合うかで導入判断すべき」というのは本当にその通りだなと思いますね・・・。
開発が大規模化しても破綻しないナレッジワークのE2Eテスト基盤
鳥居 陽介@jinjorさん 株式会社ナレッジワーク フロントエンドエンジニア
QA界隈でも有名なナレッジワークさんの発表でした。
ナレッジワークさんでは、フロントエンドエンジニアとQAエンジニア（の一部）がPlaywrightでE2Eテストを書いていて、機能カバレッジをスプレッドシートで管理しつつ、自動テストは毎朝CIで実行されているそうです。
タイトルも「開発が大規模化」とありますが、事業拡大でプロダクトが増え、それに伴って人も増えたことで課題が出てきたようでした。
そのひとつが、複数人が同時にE2Eテストを回したい状況が出てきたこと。単一のテスト用のテナントに対して同時に複数の人がテストを実行する・CIからキックした実行と人による実行が被るなどでテストが落ちるという問題が起こっていたそうで、これはあるあるですね・・・。Aさんが作ったデータがBさんの実行で消されたりとか。
そのため、「いまからテスト流すので、みなさん待っててください！」とSlackでアナウンス出すなど、運用カバーしていたらしく、これまた、わかる。
そこの対応として、テナントを増やしつつ排他制御をして、テストを自動で空いているテナントに割り振って実行する仕組みにしつつ、テナント間でデータの状態を揃えるための手順化などを行ったそうです。（ここはマンパワーかけて頑張ったと。）
ほかにもモノリシックになっていたE2Eテストを適切に分割して、開発チーム個々でオーナーシップもってメンテ等して貰う形にするなど、運用面もアップデートしているそうでした。
わかりみが多いお話でした。
Playwrightで実現する品質保証の好循環な仕組み
木下 智弘@kikkis_jpさん ウェルスナビ株式会社 SETエンジニア
ウェルスナビさんのお話では、ナレッジワークさんの話に通じる部分があるかもしれませんが、こちらも会社が成長して組織が大きくなり、それに伴ってQAの体制を見直す必要が出てきて、その中で自動化もやろうという流れになったそうです。
自動化にあたって、品質保証のやり方やテスト自体の整理・位置づけの確認も行ったそうで、テストピラミッドやテスティングトロフィー等のモデルを参考にしたり、テストレベル・テストタイプなどの概念で整理をしたとのこと。これはQAがちゃんといる組織、という感じですねー。
また自動化を行うにあたって大事なのはなにか、を考えて「継続して使い続けられること」であるとし、そのための条件として
- 結果の信頼性
- 迅速な実行
- 結果を誰でもわかりやすく閲覧
- 誰でも容易に回収
- ツールの仕様変更に臨機応変に対応
などを挙げて仕組み化やツール選定を行ったというお話でした。
この流れ、E2Eテスト自動化の経験者としてはこれから自動化しようという方は皆参考にすべきだなと思いますね。
さらに、QAチームだけが自動テストを使えるのでは不十分で、開発など他チームでも自動テストを作成・運用・保守したいと。すばらしい・・・ そのためには素のPlaywrightだけでは足りないよね、ということでAWSのECSやS3などなどを使って様々工夫した、というのがお話の中盤でした。
結果として、
- QAチームが主管しているプロダクト以外でもテストシナリオを作成し、品質保証の一貫として運用されている
- QAチームで安定して品質保証が行える仕組みができ、他チームでもできるようになっている
という状況になっているということで、社外発表にあたってキレイにまとめてらっしゃる部分はあるだろうとは思いつつも、**ちゃんとしてるな～**というのが正直な印象でした。
とくに、自動化する際にテストレベルやテストタイプでまず全体を整理したうえで、「ここをPlaywrightで自動化しよう」など決めている流れは、自分もそのように進めていたりしたので勝手に共感しながら聞いてました。
今回VRT目当て的に参加しましたが、全体通してそれぞれに学びのあるよいイベントでした。 昼開催ありがたい～という思いと、2時間枠でゆっくり聞きたい～という思いが両方ありますね・・・。