E2Eテストのテスト範囲と優先順位を考えてみた

この記事は「レバテック開発部 Advent Calendar 2024」の 13日目の記事です！
昨日の記事は、ないとー さんの「営業組織を救え！Chrome 拡張「工数入力くん」で日々の工数管理を効率化」でした。

TL;DR

• E2Eのテスト範囲はユーザーストーリーで考える
• ユーザーストーリーごとに発生するリスクごとに優先順位を付けると戦略が立てやすくなる

はじめに

レバテック開発部の江間です。
現在レバテック開発部では自動E2EテストにAutifyを使っています。私はAutify導入の旗振りをさせてもらってます。導入経緯や選定理由は過去の記事をご参照ください。

Autify導入後、しばらくしてE2Eテストでは何をどこまでテストすればいいのか？という課題にぶつかりました。推進している立場なので、より満足感を得られるように指針のようなものが作れないかと思い、担当プロダクトであるレバテックキャリアのサービスサイトにて課題に向き合いました。

今回はE2Eテストの範囲をユーザーストーリーと定めて、リスクを元に優先順位付けをすることで課題を解決するアプローチを取りました。試行錯誤の経緯を含めてお伝えできればと考えています。

前提

• 本記事はAutifyの機能関する話はあまり出てきません。
• 私はQAエンジニアではないため深くテストに精通してない点ご容赦ください。
• E2Eテストシナリオの作成方法についてはお話しません。

想定読者

• E2Eテストこれから始める方
• E2E自動テストツール導入後の満足度を高めたい方
• E2Eテストのテスト対象や導入に対して悩んでいる方

Autify導入後の課題

Autify推進として導入初期は、基本的な使い方と活用事例を共有する活動をして、具体的なテスト方針は各チームに一任しました。

ある程度、利用方法が浸透してきて頃にチームごとの使用状況を確認すると明らかに濃淡があり、
積極的に活用しているチームと出来てないチームとで差が生まれてました。アンケートや個別ヒアリングの結果、積極活用できていないチームの課題感は下記の2点でした。

1. テスト対象範囲が測りにくい
   • ユニットテストのようにコードカバレッジで進捗を把握する指標がなく、網羅性をどう担保するかが曖昧
   • 網羅性を感じられないため、テストに対する満足感や安心感が得られていなさそう
2. E2Eテストは自由度が高いため何をテストするべきかわからない
   • E2Eテストはシステム全体を通してユーザー視点で動作を確認することが目的であり、テストケースの設計において自由度が高い
   • 自由度が高いので、どの機能やシナリオを優先的にテストすべきか判断が難しい

せっかく便利なツールを導入したにもかかわらず、十分に効果を感じられないチームがある状況を改善するべく、自身が開発を担当しているプロダクトにおいて上記の課題と向き合うことにしました。

話は少しそれますが、Autifyの導入以前からE2Eテストに積極的に取り組んでいたチームでは満足度が高い傾向がありました！！コードベースのテストのツラみをAutifyで解決できたことが要因と考えられます。

課題に対するアプローチ

課題に対してAutify社に相談をお願いしところ、エバンジェリストの末村さんとお話しする機会を得ました。
末村さんはテスト自動化実践ガイド 継続的にWebアプリケーションを改善するための知識と技法
の著者でもあります。E2Eテスト自動化の導入、改善に関して詳しく書かれておりとてもオススメです。私と同じ悩みを抱えている方は是非読んで見てください。

色々な話を伺いました。その中で課題の解決におけるヒントをいただきました。

• ユーザーストーリーを洗い出して、テスト範囲（カバレッジ）としてみてはどうか？
• 基本的に抑えるべきは正常系と異常系
• 細かなエラーは見る必要はなく主要経路を意識する
• ユーザーにとって意味のあるテストをする
• 細かな部分は単体・結合テストなどに任せる

この件に関しては書籍にも詳細に記載されています。

また、2024年7月に弊社CTO室にジョインしたメンバーがQA畑出身であったことも大きな助けとなりました。アドバイスを受けながら、課題解決に取り組みました。

課題に対する試行錯誤

ユーザーストーリーをE2Eテストの範囲とすると決めたのでユーザーストーリーを洗い出すことにしました。

ユーザーストーリーは要求・要件定義などに記載されていることが多いと考えて、古くから開発に携わっている開発者の方やビジネスサイドの方に問い合わせをしましたが、ドキュメントは残っていませんでした。

なので、ユーザーが達成したいことを定義して、そこに向かうまでの主要経路を元にユーザーストーリーをボトムアップ的に作成できないか検討しました。これから出す例は一部内容を抜粋して記載します。

1. 主要ページ・機能をリストアップ

レバテックキャリアのサービスサイトはITエンジニア向けの転職メディアです。主だったページ・機能をまずリストアップして見ました。

• 主要ページ
  • 求人詳細
  • 企業詳細
  • レバテックキャリアのサービスに関するページ
  • 転職やスキルアップに関する記事
• 機能
  • 求人検索
  • 企業検索
  • 会員登録フォーム

2. ユーザーが達成したいことをリストアップ

続いて、ユーザーがサイトに訪れて達成したいことをざっくりとリストアップしました。

• ユーザーはレバテックキャリアの転職サービスを利用したい
• ユーザーは自身の条件にあった求人を探したい
• ユーザーは自身の条件にあった企業を探したい
• ユーザーは転職やスキルアップに関する情報を知りたい
• ユーザーは転職サービス利用後の流れを知りたい

3. 主要経路の探索

1と2で洗い出した点を踏まえつつ、「主要な経路 = ユーザーが達成したいことへ到達するための導線」と考えて、Google Analyticsを使って主要経路の分析を始めました。
が、結論これはちょっと早かったです。ユーザーストーリーを洗い出すという本来の目的をから外れて具体的なテストシナリオの検討になってしまいました。さらに、この作業では下記の疑問が浮かんできました。

• 達成したい目的を逆に辿るといくつか太い経路があるけど、これ全部網羅するの大変そう
• 検索機能って検索要素の組み合わせ次第でパターンが膨らむけど、どうしよう、、、

課題に挙げていた「E2Eテストは自由度が高いため何をテストするべきか」に自分自身でハマってしました。

4. アドバイスをもらう

この時点でCTO室のメンバーに疑問をぶつけたところ、以下のようなアドバイスをいただきました。

• システム的なバリエーションテストはE2Eテストでするべきではない
  • 単体・結合テストでの実施が理想的
  • E2Eテストでは代表的な経路に絞る
    • 上位Top5とかに決めて実施してはどうか
• リスク（ユーザー影響、ビジネスインパクト）が大きいものから優先的にテストするべき
  • ユーザー目線では満足度の低下、ブランドイメージ毀損の度合い
  • ビジネス目線では売上の減少の度合い
• 優先順位を付けると、テストシナリオの作成順、リリース基準、CI連携するべきテスト/定期実行に回すべきテストの切り分けに使える
• まずは主要経路を意識してユーザーストーリーを洗い出し、リスクに対して重み付けをして優先順位を付けるとどうか

特にリスクに対する優先順位付けのアドバイスは、「E2Eテストの自由度が高すぎて何をテストすべきかわからない」という課題の解消につながると感じました。さらに、優先順位を明確にすることで、テストシナリオの作成順やリリース基準が整理され、テスト導入の進め方を具体化する指針となると感じました。

5. リスク観点の整理

上記アドバイスをもとに、さらに考えられるリスクについて検討しました。
このような一覧としてまとめておくことで、リスクの網羅性を高めるとともに、テストシナリオに対する優先順位付けの根拠にもつながります。

No.	リスク観点	リスクの詳細	E2Eテスト対象	事業に与えるインパクト
1	ビジネス要件の不備	ユーザーが期待している機能が使えない状態	⭐️ 対象	売上の大幅減少、顧客満足度の低下
2	システム連携の不備	外部APIが正常に動作せず、エラーが発生する	⭐️ 対象	サービス停止によるビジネス影響、顧客対応コスト
3	リグレッションの発生	新しい機能によって既存の機能が壊れる	⭐️ 対象	顧客体験の悪化、追加修正コストの発生
4	ユーザー体験の悪化	UIが崩れてユーザーにストレスを与える	⭐️ 対象	ユーザー離脱、ブランドイメージの低下
5	セキュリティ悪化	不正アクセスが発生する可能性	🌚 対象外	顧客データの流出による信用失墜、法的責任
6	パフォーマンスの低下	高負荷時に応答速度が低下する	🌚 対象外	ユーザー離脱、ビジネスチャンスの喪失
7	データ不整合	ユーザー情報が不整合になる	🌚 対象外	ユーザーからの信頼喪失、データ修復コストの発生

6. 発生リスクの影響度を元にした優先順位の作成

続いて、ユーザーストーリーごとに想定されるリスクを元に影響度を高、中、低の3段階で検討しました。

E2Eテストを全ユーザーストーリーに基づいてシナリオ化し、変更ごとにメンテナンスすることは、かなりの人的リソースを要します。また、E2Eテストは実行時間が長くなりがちなため、必要なタイミングや頻度を見極め、現実的なキャパシティに収める工夫が必要だと考えます。

影響度 = テストの優先順位と考えることができ、優先順位を明確にすることで、テストリソースを効率的に配分できるようになります。これにより、人的リソースの無駄を削減しながら、重要なテストを確実に実施することができます。また、新しいE2Eテストを作成する際にも優先順位が指針となるため、何を優先すべきか迷うことがなくなります。

発生リスクの影響度 / テストの優先順位

影響度 / 優先順位	理由
🔴 高	会員登録はサービス利用の根幹であり、ビジネス要件の不備やシステム連携の問題が発生すると売上に直接影響を与える。
🟡 中	ユーザーが求人詳細や企業詳細を確認する行動は重要ではあるが、会員登録や応募といった直接的なコンバージョンに比べると事業インパクトが限定的。
🔵 低	記事ページやサービス紹介ページは補完的な役割が強く、ビジネスへの直接的な影響は軽微と考えられる。

活用例

• テストシナリオの作成順の指針として活用する。
• リリース基準やCI/CDで実行すべきテストの選定に活用する。
• 定期実行するテストと、そうでないテストの切り分けに利用する。

優先順位によるリリースプロセスへの適用例

優先順位を設定することで、以下のようにリリースプロセスや運用フローを効率化できます。

• 🔴 高優先度のテスト
  • CI/CDパイプラインに組み込み、すべてのテストがパスしない限りリリースを許可しないルールを設定。
• 🟡 中優先度のテスト
  • 重要ではあるが緊急性が低い場合、週に3回程度の定期実行を設定して検証。
• 🔵 低優先度のテスト
  • リスクが小さいため、週1回の定期実行で十分な検証を実施。

7. ユーザーストーリーとテストの優先順位

作成したユーザーストーリーとテストの優先順位を整理した結果（一部のみ）が下記になります。
ユーザーストーリーと言いつつ、ユーザーストーリーマッピングのような要領でページと機能を元に作成しています。

No.	ユーザーストーリー	テストの優先順位	理由
1	ユーザーは、転職サービスを利用開始するために、LPから会員登録フォームにアクセスしてアカウントを作成したい。	🔴高	会員登録はサービス利用の基盤であり、障害が発生すると売上やユーザー離脱に直結するため、影響が大きい。
2	ユーザーは、応募を検討している求人に直接アクセスするために、求人詳細ページから会員登録フォームを使ってアカウントを作成したい。	🔴高	会員登録が直接的に絡む重要な行動であり、障害発生時の事業や顧客満足度への影響が非常に大きい。
3	ユーザーは、応募を検討している求人の情報を深く理解するために、求人一覧ページから求人詳細ページを確認したい。	🟡中	求人検討の重要な行動だが、会員登録や応募に比べると事業インパクトは限定的。
4	ユーザーは、特定の企業の詳細を知るために、企業検索ページで企業を検索し、企業詳細ページを確認したい。	🟡中	企業詳細の確認は重要だが、直接的なコンバージョンには繋がりにくく、事業への影響は中程度と判断。
5	ユーザーは、転職やスキルアップに関する知識を深めるために、転職やスキルアップに関する記事一覧から興味のある記事ページを読みたい。	🔵低	記事の閲覧は補助的な役割が強く、直接的なコンバージョンへの影響が少ないため、事業インパクトは小さい。
6	ユーザーは、信頼できる転職サービスを検討するために、サービス紹介ページで全体的なサービス概要を確認したい。	🔵低	サービス紹介の不備は補完可能であり、ブランドイメージへの影響は限定的。UIやパフォーマンス低下の影響も軽微と判断。

8. 課題に対するアンサー

下記の方針により、テストの自由度が高いがゆえに起こりがちな迷いを解消し、効率的かつ効果的なE2Eテスト運用を目指す具体的な指針を作れたのではないかと思います。

1. テスト対象範囲が測りにくい
   • ユーザーストーリーをテスト対象範囲に設定する
2. E2Eテストは自由度が高いため何をテストするべきか分からない
   • 細かなエラーよりも主要な経路を意識することで、テストの範囲を絞る。
   • ユーザーにとって意味のあるテストを優先し、実際の体験に即したシナリオを作成する。
   • 細部のバリエーションは単体テストや結合テストに任せ、E2Eテストではシステム全体の動作確認に注力する。

まとめ

本記事では、自動E2Eテストを導入した後に直面した「何をどこまでテストするべきか」という課題に対する取り組みを、ユーザーストーリーをベースにしたテスト範囲の設定とリスクベースの優先順位付けによるアプローチで解決できないかという点を中心に記載させていただきました。

今後はユーザーストーリーと優先順位を元に順次テストシナリオ化を進めつつ、開発部内に考え方を広めていければと思っております。

明日は かに さんが投稿します！
「レバテック開発部 Advent Calendar 2024」をぜひご購読ください！