E2Eテストのカバレッジはどう定義する？「全量」をチームの合意で決めるための考え方
こんにちは、MagicPodでエバンジェリストをしているYoshiki Itoです。
E2Eテストの自動化を進めるなかで、「カバレッジをどう定義・計測すればいいか」という問いに直面することがあります。ツール導入の目標設定や、社内での効果説明に使いたいなど、さまざまな場面で必要となるようです。
本記事では、E2Eテストにおけるカバレッジの考え方を、単体テストとの違いを踏まえながら整理します。
目次
そもそも「カバレッジ」とは
カバレッジとは、「全体のうちどのくらいの範囲をカバーしているか」を表す割合のことです。分母＝全体・全量と、分子＝カバーしている部分で構成され、これら分子・分母がともに計測可能であることが前提になります。
テストカバレッジの文脈では、分母に何を置くかが指標の意味を大きく左右します。分母の設定が曖昧だったり、本来計測したいものに対して的外れな分母を選んでしまっては、指標として機能しません。私自身、QAエンジニアとしてよく「カバレッジが向上しました！」などの文章を見ると「それは何の、何に対するカバレッジか」が気になります。大事なのは分母、何のカバレッジなのか、の部分です。
単体テストのカバレッジには「客観的な全量」がある
単体テストのコードカバレッジを例にとると、分母の設定がとてもシンプルです。分母はソースコードそのものであり、これは客観的かつ機械的に定まります。
命令網羅（C0）や分岐網羅（C1）といった指標はそれぞれ「どの単位でコードを全量とみなすか」の違いですが、いずれも「コードという実体が存在する」という事実を根拠にしています。コードの全量は議論の余地なく決まり、ツールで自動計測できます。
もちろん、コードカバレッジが高い、あるいは100%に達したとしても、それはソフトウェアの品質を保証するものではないという点には注意が必要です。カバレッジはその網羅基準、テストが通った行や分岐の割合を示すものであり、テストの内容が適切かどうか、仕様を正しく検証できているかどうかは別の話です。テストを書けばカバレッジは上がりますが、意味のないアサーションでも数字は上がります。
この点から、テストカバレッジは「カバレッジ＊%」のような定量目標を盲目的に追う（ましてや小手先のテクニックで数字をつくったりする）ものではなく、「テストされていない箇所・偏りがないか」を検知するツールとして使うほうが適切です。もちろん、テストカバレッジの数字が高いほうが、低い状態に比べるとバグを見つけられる可能性は高くなるので、チーム目標として80%, 90%を目指そう！と取り組むのは良いことです。しかし、カバレッジが高いからちゃんとテストできている、バグは無い、とは限らないという点に注意が必要です。
E2Eテストの「どこまでやるか」問題
ここからは視点をE2Eテストに移してみましょう。
E2Eテストの導入や定着に関してお手伝いをしていると必ずといっていいほど出てくる問いが「どこまでやればいいの？」です。
さきほど説明したように、単体テストでは「コードカバレッジを高める」という方向性が一定の指針になりますが、E2Eテストではその発想がそのままでは通用しません。E2Eテストはシステム全体を通した操作を検証するため、1件あたりの実行コストが高く、テストケースの組み合わせも膨大になりえます。
そのため、E2Eテストの世界ではよく「重要なシナリオを優先しよう」とか「ハッピーパス（正常系の主要フロー）をまずカバーしよう」といいわれます。これは、全部はできないという前提に立った上で、何を選ぶかという話です。
この「何を選ぶか」という問いは、そのまま「E2Eテストのカバレッジの分母に何を置くか」という問いと同じ構造を持っています。選ぶ基準を定めることが、カバレッジを意味のある指標にする第一歩です。
E2Eテストの分母に「画面・機能」を置くと何が起きるか
E2Eテストのカバレッジを計測しようとしたとき、比較的思いつきやすいのが「画面数」や「機能数」を分母にする方法です。アプリケーション内のすべての画面や機能をリストアップし、そのうちいくつをテストしたかを割合で出す、というアプローチです。
この方法は、数値として出しやすいという利点がありますが、いくつか問題もあります。
一つは、深さが揃わないという問題です。たとえば「ログイン画面」を1つの単位とした場合、正常系・異常系・二要素認証・セッション切れからの再ログインなど、検証すべきシナリオは数多くあります。ログイン画面を「1テスト済み」としても、どの深さまで検証したかはまったく異なります。画面数ベースのカバレッジ100%が、実際にはとても薄い検証しかしていない状態を意味することもあります。
もう一つは、「カバレッジを上げること」自体が目的化してしまうリスクです。分母が画面数であれば、浅いテストを追加するだけで数字は上がります。この点は単体テストのカバレッジと同様で、単に数字を上げることが目的になってしまうと、指標としての意味を失います。
「数字が出る」ことと「指標として意味がある」ことは別の話です。
ユーザーストーリーを分母にする考え方
さまざまな書籍等で語られているのは、画面・機能ではなく、ユーザーストーリーを分母にする考え方があります。
ユーザーストーリーとは、ユーザーが価値を受け取る単位で切り出した要求のことです。一般的には「〇〇として、〇〇したい。なぜなら〇〇だから」という形式で記述されます。技術的な実装の話ではなく、ユーザーの目的や文脈から出発するのが特徴です。
E2Eテストは「ユーザーが実際にシステムを操作するフロー」を検証するものなので、ユーザーストーリーとの相性は非常に良いと言えます。実際、E2Eテストのテストベース（テストケースの根拠となる情報）としてユーザーストーリーが推奨されることは多く、「ユーザーストーリーに沿ったテストシナリオを作る」というアプローチは現場でも取られています。
ここで本記事冒頭のカバレッジの定義の話をふりかえってみます。カバレッジは分母＝全体・全量と、分子＝カバーしている部分によって算出されると説明しました。
では、ユーザーストーリーに「全量」はあるのでしょうか。
コードには「全量」があります。しかしユーザーストーリーの「全量」はソースコードと異なり客観的に定まったものではありません。開発チームや、プロダクトの関係者皆で挙げたユーザーストーリーが全てである、とも言えますが、「思いついていないユーザーストーリーはないのか？」「ユーザーストーリーに抜け漏れはないのか？」等の考え方をすると、客観的な全量とは言い難いですよね。
この非対称性こそが、コードカバレッジとE2Eテストのカバレッジの違いだと私は考えています。コードカバレッジは「存在するコード」に対する割合ですが、E2Eテストのカバレッジは「誰かが定義したストーリー」に対する割合です。全量の性質がまったく異なります。
全量は「チームの合意」によって決まる
では、ユーザーストーリーの全量はどのように決まるのでしょうか。
私の考えでは、それはチームの合意によって決まるものです。「これらのユーザーストーリーが実現できていれば、このプロダクトはリリースしてよい状態だ」とチームが合意したものが全量になります。
コードカバレッジとの違いをあらためて整理すると、こうなります。
コードカバレッジは、全量（ソースコード）は客観的に存在する。ツールが自動的に計算できる。 E2Eテストのカバレッジは、全量（ユーザーストーリーのリスト）はチームの合意によって決まる。自動的には定まらない。
この違いを認識することが、E2Eテストのカバレッジを考える出発点になります。
チームで何をテストすべきかを議論し合意するプロセス自体が、プロダクトの品質基準を定める行為でもあります。全量を決めることは、テスト設計の話であると同時に、プロダクトの方向性をチームで揃える活動でもあります。
チームで合意するための手法——ユーザーストーリーマッピング
チームでユーザーストーリーの全量を合意するための手法として、ユーザーストーリーマッピングがよく知られています。
ユーザーストーリーマッピングは、Jeff Patton氏が提唱した手法で、ユーザーの行動フローを横軸（時系列）に、詳細度を縦軸に並べたマップを作ることで、チームがプロダクト全体の姿を共有・合意できるようにするものです。
QAの文脈でも、ユーザーストーリーマッピングを活用してテスト対象の全量を決めるアプローチが実践されています。マッピングを通じて「何がリリースに必要か」「どのユーザー行動を検証すべきか」をチームで可視化することで、E2Eテストのカバレッジ計測の基盤となる「合意した全量」が生まれます。
詳しくは、ユーザーストーリーマッピングを扱った書籍（Jeff Patton著『ユーザーストーリーマッピング』）や、QAの文脈での活用事例（参考：ユーザーストーリーマッピングから始めるアジャイルチームと並走するQA）が参考になります。
カバレッジの使い方と「濃淡」のつけ方
合意した全量に対するカバレッジが得られたとして、それをどう使うかについても触れておきます。
まず注意点として、カバレッジが100%に達したとしても、それは「大丈夫」を意味しません。合意した全量の定義自体が不十分だった可能性があるからです。「カバレッジを満たした」という事実は、「合意したストーリーに対するテストが揃った」ことを示すに過ぎず、合意に漏れがあれば、カバーされていないリスクが残ります。
E2Eテストのカバレッジは、高めることを目指す最適化指標というより、低い状態・偏りのある状態を検知するためのツールとして使うのが適切だと考えています。カバレッジが低い領域や、長期間テストが更新されていない領域は、リスクのシグナルになります。また、合意した全量のリスト自体も定期的に見直し、プロダクトの変化や新しいユーザーの使い方に合わせて更新していく運用が重要です。
加えて、実践的な工夫としてテストに「濃淡」をつける考え方があります。合意した全量の中でもさらに優先度や実行頻度を分けるアプローチです。たとえば、プロダクトの根幹となる重要シナリオは毎日実行し、全体のシナリオはリリース前にまとめて実行する、といった運用です。
まとめ
E2Eテストのカバレッジは、突き詰めると「チームが何を全量と決めるか」という問いに行き着きます。コードカバレッジのように客観的な全量が最初から存在するわけではなく、チームの合意によって全量が決まるのがE2Eテストのカバレッジの性質です。
難しさや曖昧さを感じるかもしれませんが、何をテストすべきかをチームで議論し合意するプロセス自体が、プロダクトの品質基準を定める行為であり、その合意があってはじめてカバレッジという指標が意味を持ちます。
「E2Eテストのカバレッジをどう定義するか」という問いに直面したとき、まず取り組むべきはチームで「何をカバーすれば十分か」を話し合うことだと思っています。
