シャペロンにおけるPlaywrightを使ったE2Eテストの導入と浸透
株式会社シャペロンのsrkwです。
2023年から、メインの機能開発と並行してE2Eテストによる機能担保の自動化を進めていました。
途中かなり試行錯誤がありつつも2023年末の段階ではある程度方向性が固まって来たので、シャペロンでのE2Eテスト導入の流れを、当時踏んでしまった失敗と合わせてご紹介したいと思います。
今後開発チームにE2Eテストを導入しようか悩んでいる・E2Eテストを導入したいがどのように導入してよいか悩んでいる方の参考になれば幸いです。
この記事ではE2Eテストに関する技術的な話は紹介していません。
技術面については zennに投稿するB面記事に記載するので、技術面について興味がある方はぜひそちらをご覧ください。
E2Eテストを導入しようと思ったきっかけ
シャペロンではリリースが四半期に一度あり、各リリース時期の直前には約800個以上の機能リストを分担して手動で動作確認していました。この動作確認にリリースごとに約80人時間の工数がかかっておりリリース間隔を短くできないという状況だったので、リリース間隔を短くして顧客への価値提供を早めるためにも動作確認をE2Eテストで自動化したいとなった次第です。
技術選定
E2Eテストフレームワークの選定
E2Eテストの本格導入に向けて検証するにあたり、CypressとPlaywrightが最終的な比較候補になりました。
検討時（2023/01時点）にCypressよりもPlaywrightの方が優れていると判断した点は以下の通りです。
速度面で優位性があった
複数タブ・複数ドメインのテストが書きやすい
運用にかかる費用が安い（単体なら基本無料）
テストコードの可読性が高く、書きやすいように見えた
よりスタンダードなTypeScriptで記述でき、キャッチアップのコストが安い
codegenが便利そう
その他、E2Eテストの実行環境の選定・構築
当初の目的と照らし合わせるとE2Eテストをローカルで回せても自動実行できないと意味がないので、実行環境の整備も行いました。
具体的にはE2EテストをCodePipeline上で日次で自動実行し、結果をSlackに通知しつつ、トレース情報をLambdaTestという外部のSaaS上で閲覧できるようにしました。
詳しい内容はzennに投稿した記事をご覧ください。
E2Eテストによる検証自動化の対象機能の選定
Playwrightの書きやすさ・メンテしやすさをもってしても全ての機能に対してE2Eテストを追加するのは現実的ではありませんでした。
そこで、機能一覧のうち、「ユーザー（製薬企業のMRなど）の顧客（医療従事者）への直接的な影響があるもの」「セキュリティおよび規制対応への悪影響が発生しうるもの」のいずれかに該当する機能のみをE2Eテストによる挙動担保対象としました。
失敗：一旦全部書こうとした
当初、溢れんばかりのやる気と元気で「今ある機能を全てE2Eテストで担保してやる！ドン！」と意気込み、片っ端から検証項目をE2Eテスト化していましたが、テストの実行件数が500件を超えたところで、機能追加に伴うE2Eの改修コストが無視できなくなり、対象機能を絞ることになりました。
大量にE2Eテストを書く機会があったことで、Playwrightに慣れられたという点では良かったかもしれませんが、もう一度同じことをやるなら絶対に対象機能を絞ると思います。
実装・監視・メンテの担当者を開発チーム全体で分担
E2Eテストはアプリケーションサーバー同様、いずれ開発チームの資産となり事業を支える一つの要素になります。そのため、一部のメンバーしかメンテできないという状況はもちろん望ましくありません。
E2Eテスト導入初期は利用するテストフレームワークで提供されている機能をどのように使えば自社の要件に沿ったE2Eテストになるのかという検証を行うことになります。この期間は方々で多種多様なコードを書くとコードの一貫性を保つことが難しく、また検証時の手戻りの多い作業を複数人で分担すると工数の消費が激しくなるので避けたいという理由で、E2Eテストの検証・実装メンバーは徐々に増やす進め方にしました。
具体的には検証初期は1人〜2人で検証を始め、基本的な設定やテストコードの構成、利用を推奨するAPIや推奨しないAPIの選定などを進めました。ある程度基本的な失敗を踏み抜いたあとはメンバーを3人〜5人と増やし、PR上やMTGでの相互のフィードバックはコーディングガイドライン（zenn側の記事で紹介します）に残すことで、後から意思決定の結果や経緯を参照しやすい形にしました。
しばらくするとさらに担当メンバーを増やし、現在ではE2Eテストの追加をPBI化して他の開発タスクと同様にスクラムの枠組みの中で取り組むようにしています。
E2Eテストは機能追加やテスト追加時の検討漏れなどで頻繁に失敗します。テストの追加についてはPBI化して各チームで分担するものの、壊れた際の改修作業で得られる知見・経験を平坦化するために、メンテ・監視の担当者についても開発チーム全体の中でローテーションするようにしました。
開発チームの中で得られた知見は常にコーディングガイドラインに集約することで、一部のエンジニア・チームに依存しないE2Eテストの運用を目指しています。
失敗：他のチームへの展開が遅れてしまった
E2Eテスト導入当初はどれくらいハマるのか、どれくらいの検証時間が必要なのかを読みきれず、気づけば随分長い期間自分一人でE2Eテストを淡々と書き続けているという状況になってしまいました。
個人的にはガイドラインに都度追記したり、要所要所でチームに相談したりはしていたものの、開発チームの他のメンバーから見ると「srkwがなんかやってんな」という取り組みになっていたかもしれず、E2Eテストによる検証自動化というテーマをチームのものにする機会を奪ってしまっていたかもしれないなと反省しました。
また、1人でなにかをやり続けていると個人の体調や検証速度がボトルネックになり、メンタル的にきつい状況になりがちです。今後同じように何かのプロジェクトを始める際には、「少し早いかな」という段階でも周囲を巻き込みながら一緒に試行錯誤するフェーズに移した方が、チームにとっても個人にとっても健全にプロジェクトを進められそうだなと思っています。
シャペロンのE2Eテストの現在地と、今後の展望
現在は前述の「失敗：一旦全部書こうとした」で述べた通り不要なE2Eテストが残っているものの、あらためて必要な検証対象機能の洗い出しが済んだ状態です。
現在の日次のテスト実行件数は500件程度で、flakyな5〜10件程度のテストがコケるものの、日々の機能追加を行いながらも、retryを通して99％〜100％のテストがPassしている状況です。
上記のE2Eテストの成功割合を見るに、割と品質の高いE2Eを書けているのかなと認識しているので、今後はここまで培ったノウハウ（＝コーディングガイドライン）を活かして、まずは大元の課題であったリリース時の工数削減と、リリース間隔短縮による顧客への価値提供の速度向上を目指す予定です。
これが完了したあとにも
部分的にflakyなテストを見直してE2Eテストの成功率向上
CI上でE2Eテストを実行して、PRごとのデグレを即座に検知できる仕組みづくり
LambdaTest（B面記事を参照）などの周辺ツールの見直しとコスト削減
などなど、課題を少しずつ改善していきたいと思います。
最後に
今回ご紹介したシャペロンのE2Eテスト周りの技術的な構成やtips等については、noteだと微妙に書きづらかったので、B面記事としてzennに掲載します。ご興味がおありの方はぜひこちらもご覧ください。
また、シャペロンにご興味を持って頂けた方がもしいれば、以下のエントランスbookをご覧ください。
E2Eテストに限らず、シャペロンでは日々技術的・事業的なチャレンジに取り組んでいます。この記事を読んでくださった方と一緒に働けることを楽しみにしております。