エンドツーエンド（E2E）テストとは

E2Eテストでは、統合されたコンポーネント（フロントエンド、バックエンド、データベース、サードパーティのサービスなど）がスムーズに連携することを確認します。また、実際のユーザー・シナリオを組み込むようにします。

現在では、ソフトウェア・テストには多様な種類が利用できます。アプリケーション全体の特定領域に絞って関心のある観点を詳細に検証し、最小の増分レベルまで単体テストすることも可能です。ソフトウェアが特定の機能をどれだけ適切に実行できるか、または異なるコンポーネント同士がどのように連携するかをテストしたい場合もあるでしょう。このような場合は、機能テストや結合テストの活用を検討するとよいでしょう。

ですが、あなたの目標はソフトウェア・アプリケーションがどのように動作するか、全体像を完全に把握することだとしましょう。最初から最後まで実際のアプリの動作と、サブシステムと関連する依存関係が効率的に処理されるかを確認します。

これらの手順以外に、ユーザー・インターフェイス（UI）が適切に機能するか、全体を通じて把握するとしましょう。どのUIテストのアプローチを選択したとしても、ユーザー視点でアプリの性能を考慮する必要があります。

E2Eテストは、アプリの動作を最初から最後まで把握し、ユーザー・エクスペリエンス（UX）の品質を評価する手法を備えた包括的なテスト・フレームワークを提供します。

E2Eテストはアプリケーション開発ライフサイクル全体を対象にするほど包括的であるため、通常、より多くのコミットメント、リソース、時間が必要になります。

E2Eテストは、動作を「合格／不合格」に単純化して評価する「ブラックボックス」型のテスト戦略とは大きく異なります。この戦略では、アプリケーションが仕様どおりに動作するかどうかだけが分かります。このため、E2Eが常に最適というわけではありません。一般に時間を要するテスト手法であり、アプリの各段階のパフォーマンスを本当に評価する必要がある場合に最も適しています。

E2Eテストのプロセスは次の手順に基づきます：

まず、実際のユーザーがアプリケーションをどのように操作するかを考えることから始めます。この段階では、アプリで最も重要なユーザー・インタラクションは何か、アプリ内のワークフローをどのように流すかも検討します。

テスト・シナリオは、現実のシナリオやユーザー・ジャーニーを適切に反映する必要があり、各シナリオを文書化し、そこに含まれる各ステップを図示します。

また、テスト・ケースを体系的に整理し、容易にアクセスできるよう、テスト管理システムも必要です。テスト・スイートはこの役割を担い、ユーザー・ジャーニーや特定の機能、モジュールやコンポーネントごとにテスト・ケースをグループ化します。

このステップはテスト環境に関連し、事前の計画が必要なもう1つのステップです。理想としては、テスト担当者は本番環境と類似したステージング環境を開発する必要があります。

テスターは、アプリケーション・プログラミング・インターフェース（API）、データベース、その他の必要な要素など、通常はソフトウェア開発プロセスに統合される個々のコンポーネントを、このステージング環境に配置します。実運用のパフォーマンス・データにアクセスできない場合は、代替として合成データを用いることもあります。

E2Eテストの設計の次のステップは、適切なテスト・ツール、具体的には必要なフレームワークと自動化ツールを選択することです。オートメーション・ツールはテスト・プロセスを合理化し、テストを迅速化するため、E2Eテストの実施に不可欠です。テスト担当者がアプリケーションの性能全体を評価する場合、このような時間の節約は効率化に役立ちます。

使用するツールはアプリケーションの種類によって異なります。Webアプリケーションでは、一般にCypressやSeleniumなどのツールが選ばれます。モバイル・アプリケーションでは、Appiumなどのツールが用いられます。

テスト担当者がフロントエンド、バックエンド、データベース、APIなどのすべての関連コンポーネントに付随する、さまざまな使用シナリオを記述したテスト・スクリプトを作成するステップです。

E2Eテスト中、テスト担当者はワークフロー進行中にアプリケーションの動作を評価し、テスト実行全体を通じてデータの完全性が維持されていることを確認します。テスト・スクリプトを使用しないことをテスト担当者が選択した場合、テスト・シナリオに対して手動テストを実施する必要があります。

テスト手法の有用性は、何を明らかにするかによって決まります。この段階では、テストによって得られたテストデータを注意深く評価する必要があります。テスト担当者は、テスト結果とその関連するメトリクスについて期待される結果と比較し、テストカバレッジから学べること、そしてコード内にどのような欠陥やエラーが依然として存在しているかを確認します。

次に、テスターはテストで明らかになった問題の修正に取り掛かります。失敗の根本原因を突き止めるため、エラー・メッセージやパフォーマンス・ログを調査します。アプリケーションの問題を無事にデバッグできたら、問題が解消され、テスト工程によってパフォーマンスが最適化されたかを確認するためにテストを再実行します。

この段階では、シームレスなデータ品質の確立を目標に、通常の品質保証（QA）作業を実施します。

E2Eテストの最終段階では、自動化の力を活用し、自動テストが定期的に実施される活動として適切に統合されていることを確認します。つまり、オープンソースのフレームワークであるPlaywrightのようなツールによるテスト自動化を、継続的インテグレーション／継続的デリバリー（CI/CD）パイプラインに組み込み、必要なテストを定期的かつ恒常的に実行します。

こうすることで、CI/CDパイプラインを活用するテスターは、ソフトウェア開発プロセスのより早い段階でパフォーマンス問題を検知し、迅速かつ容易に対処できます。

エンドツーエンド・テストの実践を極めたいですか?次に挙げるヒントを見て行きましょう。

しばしばユーザー・ジャーニーは大きく異なるため、テストにできるだけ多く含めることも重要ですが、テストの優先順位を決めなければならないこともあります。この方法では、まずは最も重要なユーザー・ジャーニーのテストに全力を注ぐべきです。

「重要」の定義は多少変わることがあります。しかし一般的には、組織にとって継続的に重要であるため定期的に実施されるテスト、たとえばサイトのログインなどを指します。

もう1つ、このステップで行うことは、テストしやすくなるようワークフローを管理しやすいステップに分割することです。

セレクターは、Webページのドキュメント・オブジェクト・モデル（DOM）に存在するインタラクティブ要素を選択するパターンです。セレクターは、インプット欄、テキスト要素、ボタンなどの画面要素を見つける際のフレームワークを支援する位置情報として機能します。

同様に、「data-*」属性やその他の安定した識別子を使用するのが最適です。クラス名のような壊れやすいセレクターは避けるべきです。さらに、DOM構造はさまざまな反復を繰り返すことがあるため、注意して使用した方が良いでしょう。

良いテストの条件成功の形はさまざまですが、優れたテスト事例には共通する特性があります。まず、必要なときにいつでも同じテストを実行できるよう、テストに再現性があることが望ましいです。

同様に、サードパーティーの稼働状況やネットワークのタイミング問題など、外部要因に煩わされずに実行できることも重要です。こうした要因は結果の信頼性を損なう可能性があります。

効果的な管理でスコープ・クリープを抑えないと、E2Eテストは容易に肥大化します。その場合、テストは重くなって実行しづらくなり、パフォーマンスも低下します。

このため、可能な範囲で負荷の高い処理の一部はオフロードするとよいです。主としてロジック検証のような活動は、単体テストや結合テストの一環として実施できます。こうすることで、E2Eテストはユーザー行動の検証やシステム間の連携確認に専念できます。

効率的かつ網羅的なテストを促進するうえで、テスターが取れる最も効果的な方策は、テスト自動化がもたらす高い処理能力を活用することです。これにより、適切な頻度でテストを実施できます。

自動化は繰り返し作業を担うだけでなく、テストに紛れ込むヒューマンエラーを継続的に抑制する主要な手段でもあります。クロスブラウザー対応のアプリケーションやモバイル・アプリケーションでは、クラウド型のテスト・サービスを選ぶテスターも多いです。

テスト環境の作成と保守は、システムテストの重要な部分です。テスト担当者は、迅速にセットアップしすぐにテストできるよう、テスト環境を最適化し、できるだけアジャイルにする必要があります。

また、外部からの過度の干渉からテスト結果を保護するために、テスト環境を完全に分離することは非常に重要です。

関係者全員が足並みをそろえると、E2Eテストは最大限に効果を発揮します。こうすることで、コードの改修時に特に価値を持つ高品質なテスト結果を活用できます。特に、DevOpsチームとQAチームは、最適なソフトウェア品質を確保するために緊密なコミュニケーションと協業を維持する必要があります。

また、QAチームが組織のビジネス要件を明確に理解し、改修の過程でそれらを意図せず損なうことがないよう、教育を行うことも重要です。

最後に、プロジェクトの進捗状況をすべての利害関係者に知らせます。

アプリケーションの運用では、APIが各コンポーネント間の通信を可能にするため、極めて重要です。

APIテストはAPIの機能に焦点を当てており、テスト担当者がUIの機能を評価する前に、ロジックベースの問題を排除できます。

テストを複数実行する場合、システムのマルチタスク機能を活用し、テストを並行して実行するべきです。この方法は、クラウドベースのテスト構成に特に効果的ですが、あらゆるテストで有効な指針です。

テストを並列実行すると、実行時間を短縮でき、フィードバックもより迅速になります。

私たちが常に意識しているとおり、コンピューター領域で長期にわたって同じであることはほとんどありません。物事は変化し、状況は進化し、アプリケーションもまた、進化します。このような絶え間ない変化があるため、テスト担当者の作業が完全に完了することは決してありません。

E2Eテスト・ケースは定期的に見直し、分析上のパフォーマンスに悪影響を及ぼす変更がないかを確認するのが賢明です。

人工知能（AI）は、コンピューティングのほぼあらゆる側面を活性化し、変革しています。E2Eテストでも、AIの主な利点は他のソフトウェア・テスト形態にも共通しています。要するに、AIはE2Eテストの実行を高速化し、プロセスの効率化を促進し、アプリケーションをエラーからより堅牢に保護します。

それ以外にも、アプリケーションの動作とユーザー・フローに基づいてテスト・ケースを生成することで、AIはE2Eテスト・プロセスを支援しています。この方法には、UI変更のシステム認識に基づいて自己修復できる「自己修復」テストが含まれます。

AIは進化し続けるアプリにおけるテストを監視し、検知した大きな変更に応じてテストを適応させることができます。実行時には非常に高速にテストを走らせることができ、さらに、追加の追跡テストが必要となり得る領域を特定できます。

オンプレミスのインフラコストを抑えたい組織に対しては、クラウド上で実行できるAI搭載のテストもあります。ソフトウェアを提供する企業にとっては、必要なテストをより高速に回せるため、製品リリースの迅速化につながります。

最後に、AIが業務を「奪う」という一般的な見方とは対照的に、AIは非技術者でもテスト・プロセスに関わりやすくしています。テスターに求められる前提知識を減らすAI搭載ツールにより、より多くの人がプロセスに参加できるようになります。