E2Eテスト（エンドツーエンドテスト）とは
E2Eテスト（エンドツーエンドテスト）とは、システムを利用者と同じ立場で操作し、画面での入力から、裏側の処理、データベースへの保存、メール送信などの最終的な結果まで、端から端までの一連の流れが正しく動くかを確かめるテストです。
平易に言えば「部品ごとの検査ではなく、完成した車に実際に乗って、エンジンをかけて走って止まるまでを試す」テストです。部品が一つひとつ正しくても、組み合わせたときに動かないことはあります。E2Eテストはその全体の動きを確かめます。
End to End（端から端まで）の略で、「イーツーイー」と読みます。人が手で行う場合もありますが、現在はブラウザを自動で操作するツールを使って自動化することが多くなっています。
仕組み・ポイント
テストには範囲の違いによっていくつかの種類があり、E2Eテストは最も広い範囲を扱います。
| テストの種類 | 確かめる範囲 | 例 |
|---|---|---|
| 単体テスト | 一つの関数や部品 | 消費税の計算関数が正しい値を返すか |
| 結合テスト | 部品同士のつながり | 注文登録の処理がデータベースに正しく保存するか |
| E2Eテスト | 利用者の操作から結果まで | ログインして商品をカートに入れ、購入し、確認メールが届くか |
自動化されたE2Eテストは、次のような流れで動きます。
- テスト用のブラウザを起動する
- 決められた手順で画面を操作する（ボタンを押す、文字を入力する）
- 画面に表示された内容や、保存されたデータが期待どおりかを確かめる
- 結果を記録し、失敗した場合は画面の様子を画像や動画で残す
代表的なツールとして、Playwright、Cypress、Seleniumなどがあります。どれを使うかは、開発に使っている技術やチームの慣れで選びます。
E2Eテストは信頼性の高い確認ができる一方で、実行に時間がかかり、画面の小さな変更でも壊れやすいという弱点があります。そのため、すべての画面をE2Eテストで確認するのではなく、最も重要な流れに絞って使うのが基本です。
実務での使い方・具体例
ある会社の予約サービスで、リリースのたびに「予約ができなくなっていないか」を担当者が手で確かめている場面を考えます。
E2Eテストの対象を選ぶ手順の例です。
- 止まると売上や信用に直結する流れを挙げる（会員登録、ログイン、予約、決済、キャンセル）
- その中から、最も利用者が多く、壊れたときの影響が大きい流れを選ぶ
- 「ログインして空き枠を選び、予約を確定し、予約一覧に表示される」という一本の流れを自動化する
- 決済は外部サービスの試験用の環境を使い、本物の請求が発生しないようにする
- ステージング環境へ反映するたびに自動で実行する
社内向けの業務システムでも考え方は同じです。たとえば経費精算のシステムなら「申請者が申請を出し、上長が承認し、経理の画面に表示される」という、複数の利用者をまたぐ流れが最重要になります。ロールの異なる利用者でログインし直しながら一連の流れを確かめるテストは、手作業だと時間がかかるため、自動化の効果が大きい対象です。
この一本があるだけで、「リリースしたら予約ができなくなっていた」という最悪の事態を、本番反映の前に防げる可能性が高まります。
壊れにくいE2Eテストにする工夫
- 画面の見た目（文言や位置）ではなく、テスト用の目印を手がかりに要素を探す
- テストごとに必要なデータを用意し、前のテストの結果に依存させない
- 待ち時間を固定せず、「表示されるまで待つ」形で書く
- 失敗したときに原因が分かるよう、画面の記録を残す
よくある誤解と注意点
- E2Eテストを増やせば安心、ではない：数が増えるほど実行時間と保守の手間が膨らみます。細かな条件の確認は単体テストに任せ、E2Eは主要な流れに絞ります。
- ときどき失敗するテストを放置する：通信のタイミングなどで結果が揺れるテストを放置すると、失敗しても無視されるようになります。原因を調べて安定させます。
- 実行に時間がかかりすぎる：E2Eテストの実行が長いと、変更のたびに待たされて開発が滞ります。並列で実行する、毎回は主要な流れだけにして全体は夜間に回すなど、実行の仕方も工夫します。
- 本番環境で実行する危険：本番で試験の予約や決済を行うと、実際のデータや請求が発生します。実行環境と使うデータを明確に分けます。
- 手動の確認がゼロになるわけではない：見た目の崩れや使い勝手は、自動テストでは十分に確かめられません。人の目による確認と組み合わせます。
関連用語
- テスト自動化：E2Eテストを含む、確認作業を自動で行う取り組み
- 回帰テスト（リグレッションテスト）：E2Eテストが担うことの多い、既存機能の確認
- 開発環境・ステージング環境・本番環境：E2Eテストを実行する環境の区分
- 負荷テスト：機能ではなく、大量アクセスへの耐性を確かめるテスト
- 実践記事：受入テストの進め方：発注側が用意するテストケースと検収の基準
Otsumuに相談できること
リリースのたびに手作業で主要な機能を確認している、確認漏れで重要な機能が止まったことがある、といった課題に対して、E2Eテストの対象選びから自動化、実行の仕組みづくりまで支援しています。詳しくはシステム開発をご覧ください。
30分の無料相談で、現在の確認方法と守りたい機能を伺います。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01