エンドツーエンドテストとは？詳しく解説します

TOP
コラム
エンドツーエンドテストとは？詳しく解

概要

ここでは、エンドツーエンドテストについて説明させていただきます。
根本的な理解として、エンドツーエンドテストを明確に定義しているものは少なく、企業やプロジェクトによって若干理解の違いがある点は注意が必要です。

一般的に、エンドツーエンドテストは、ソフトウェアをエンドツーエンドでテストするソフトウェアテストアプローチです。これには、機能要件と非機能要件の両方のテストが含まれます。
これはブラックボックステストのサブセットと見なすことができますが、個々のコードユニットではなく、システムまたはアプリケーション全体を実行することを目的としています。アプリケーションが期待どおりに動作し、ユーザーのタスクやプロセスの種類を問わずデータフローが適切に機能することを確認する手法として機能し、これらは現在のソフトウェア開発やソフトウェアテストにおいて重要な役割を担います。
さらにエンドツーエンドテストでは、アプリケーションの実際のシナリオを最初から最後まで調べ、できるだけ多くの機能領域とアプリケーションのテクノロジースタックの部分に触れます。
範囲が狭い単体テストと比較して、テスト範囲が広いため、ブロードスタックまたはフルスタックテストと呼ばれることがあります。これらのエンドツーエンドテストは、エンドユーザーの観点からアプリケーションのワークフローを検証することに重点を置いており、管理者や顧客から高く評価され、企業の信頼性を高めるために重要です。

エンドツーエンドテストは通常、テストプロセスの最後に実行され、下位レベルのユニット、統合、およびシステムテストに続きます。
さらに、自動化されたエンドツーエンドテストは、その価値にもかかわらず、構築が複雑で、専門的な知識が必要です。その結果、一般的なアプローチは、テスト自動化ピラミッドに示されているように、単体テストや統合テストよりも少数の高品質なエンドツーエンドテストを計画することです。
これらのテストは、ネットワーク、データベース、サードパーティサービスなどのバックエンドサービスや外部インターフェイスの使用を含め、可能な限り現実的な環境で実施されます。
このため、エンドツーエンドテストでは、ユニットと統合を個別にテストした場合に見逃される可能性のある、実際のタイミングや通信の問題などの問題を特定できます。

メリット

エンドツーエンドテストのメリットと重要性について説明させていただきます。
一点目がユーザーの観点からのテストです。単体テストでは各コンポーネントを個別に検証しますが、エンドツーエンドテストではエンドユーザーの観点からアプリケーションを調べます。これにより、単体テストでは明らかではない欠陥を明らかにすることができます。
二点目がワークフローの検証となります。エンドツーエンドテストは、アプリケーションのビジネスロジックを検証できます。
三点目がテスト範囲の拡大です。エンドツーエンドテストでは、サードパーティコードを含め、アプリケーションのすべての依存関係が正しく連携して動作することを確認できます。
四点目が本番環境で検出されるエラーの数を減らすことができる点です。テストスイートにエンドツーエンドのテストを追加すると、本番環境への展開後に欠陥が見つかる可能性を減らすことができます。

重要性

エンドツーエンドテストが重要視されるのは、ソフトウェアエンジニアやソフトウェアテストエンジニアのみの観点だけでなく、プロジェクトに関連する多くのメンバーにとってメリットがあるからです。
例えば、プロジェクトマネージャーやビジネスアナリスト、エンドユーザーなどです。

ソフトウェアエンジニアとってのメリットは、ソフトウェアに対して専門的な能力を発揮することで、テストと品質保証の関するリソースを削減することができる点です。これによってソフトウェア開発の品質が担保され、プロジェクト全体に効果があります。ソフトウェアエンジニアにとってはユーザーの行動であり、それらの行動はユーザービリティテストで観察してチケットで文書化するなど、効率的にテストを実施することが出来ます。
プロジェクトマネージャーやビジネスアナリストにとっては、ユーザーのワークフローの重要度を把握することができる点がメリットです。これによりサービスやプロジェクト全体を俯瞰してみることができます。さらに、開発バックログのタスクの優先順位を調整することが可能となり、プロジェクト全体の効率化を実施することができます。
エンドユーザーにとってのメリットは、安心して問題のないサービスを利用することができる点です。ユーザー操作が多く必要なWebアプリ、デスクトップアプリ、モバイルアプリでは、テストケースによりユーザーの期待を満たしているかどうかを確かめることができる点も大きいです。

デメリット

エンドツーエンドテストのデメリットについても説明させていただきます。
一点目が実行が遅いことです。UIを介してワークフローを検証するテストは、実行に時間がかかる場合があります。
二点目が壊れやすく不安定なテストである点です。エンドツーエンドテストでは、重要なメンテナンスとトラブルシューティングが必要になる場合があります。
三点目が利用可能なテスト環境の欠如です。実際のシナリオに合わせてテスト環境を再作成することは難しい場合があります。
四点目がデバッグがより困難である点です。エンドツーエンドテストが失敗した場合、問題を見つけて修正するには、より詳細な単体テストまたは統合テストよりも多くの調査が必要になる場合があります。
五点目がテスト設計の困難な点です。エンドツーエンドテストは現実世界におけるユーザーの行動をシミュレートするため、テストを設計する際に考慮すべき要素が数多くあり、複雑な設計が必要となります。たとえば、Webアプリケーションであれば、使用されるブラウザーは多数あり、しかもブラウザーごとに仕様が異なります。そのため、ブラウザー別にテストを作成する必要があります。

ポイント

エンドツーエンドテストについて必要なポイントをいくつか紹介させていただきます。
典型的なエンドツーエンドテストは複雑で、手動で行うには時間がかかる複数のステップがあります。この複雑さにより、エンドツーエンドテストの自動化が難しくなり、実行が遅くなる可能性もあります。以下のポイントを抑えることで、エンドツーエンドテストのメリットを享受しながら自動化を実施することが可能です。

一点目がエンドユーザーの視点を保つことです。アプリケーションの実装ではなく機能に重点を置いて、エンドユーザーの観点からエンドツーエンドテストケースを設計します。可能であれば、ユーザーストーリー、受け入れテスト、BDDシナリオなどのドキュメントを使用して、ユーザーの視点を捉えます。

二点目が例外テストを制限することです。エンドツーエンドテストは、典型的な使用シナリオを捉える、使用頻度の高いケースに焦点を当てます。下位レベルの単体テストと統合テストを使用して、ユーザーが現在在庫にあるよりも多くのアイテムを注文しようとしたり、許容される返品日を過ぎてアイテムを返品したりするなど、バッドパス/サッドパスの例外ケースを確認します。

三点目がリスク分析を適用することです。エンドツーエンドテストを手動で実行したり、自動化したりする相対的な費用を考慮して、アプリケーションのリスクの高い機能に集中する必要があります。リスクの高い機能を判断するには、障害が発生する可能性と、それがエンドユーザーに与える潜在的な影響の両方を考慮する必要があります。 リスク評価マトリックスは、リスクを特定するのに役立つツールです。

四点目が正しい順序でテストすることです。単一の単体テストが失敗した場合、欠陥が発生した場所を特定するのは比較的簡単です。テストが複雑になり、アプリケーションのより多くのコンポーネントに触れるにつれて、潜在的な障害点が増加し、障害が発生したときにそれらをデバッグすることが難しくなります。
最初に単体テストと統合テストを実行すると、比較的簡単に解決できるエラーを検出できます。次に、エンドツーエンドテスト中に重要なスモークテストを最初に完了し、次にサニティチェックとその他のリスクの高いテストケースを完了します。

五点目がテスト環境を管理することです。環境のセットアッププロセスを可能な限り効率的かつ一貫性のあるものにします。
テスト環境の要件を文書化し、システム管理者および環境のセットアップに関係する他のすべての人に通知します。テスト環境のオペレーティングシステム、ブラウザー、およびその他のコンポーネントの更新をどのように処理するかをドキュメントに含めて、本番環境とできるだけ同じ状態に保ちます。1つの解決策は、テスト目的で運用環境のイメージバックアップを使用することです。

六点目がテストロジックをUI要素の定義から分離することです。自動化されたエンドツーエンドテストをより安定させるには、テストのロジックをUI要素の定義から分離します。オブジェクトリポジトリまたはページオブジェクトパターンを使用して、テストロジックがユーザーインターフェイスと直接対話することを回避します。これにより、UIの構造の変更によってテストが失敗する可能性が低くなります。

七点目がUI要素の待機を適切に処理することです。ページが読み込まれるか、UI要素が画面に表示されるのを待っているときに、エンドツーエンドテストが不必要に失敗することを許可しないことが重要なポイントです。指定した期間、UI要素が存在するのを待機するアクションを追加し、その期間を超えると、テストは失敗するなどの設定を事前に組み込むことが重要です。待機時間は、UI要素が表示されるまでの通常の時間と少なくとも同じ長さにする必要がありますが、長くしすぎることは問題が生まれます。
具体的には、過度に長い待機時間はアプリケーション、インターフェイス、または環境に問題があることを示している可能性があり、エンドユーザーにとってのリスクとなります。さらに、自動化されたテストで長い待機時間を許可すると、エンドツーエンドテストの全体的な実行にも影響を与える可能性があります。一般に、UI要素が表示されるまでの通常の時間よりも少しだけ長い待ち時間を設定します。

八点目が物理デバイスとエミュレーターでのモバイルテストの自動化です。モバイルデバイスの場合は、iOSとAndroidの最も一般的なバージョンに物理的なテストを集中させてから、シミュレーター/エミュレーターを使用してあまり一般的でないバージョンをカバーします。

九点目がセットアップ/ティアダウンプロセスを最適化することです。テスト環境の準備が常に整っているように、セットアップおよびダウンプロセスを使用します。自動化されたスクリプトを使用してテストデータを作成し、後でクリーンアップして、テスト環境を元の状態に復元し、次のテストラウンドの準備を整えます。

DevOpsパイプラインでのテストの自動化について

エンドツーエンドテストにおいて関連性の高いDevOpsパイプラインでのテストの自動化について補足で説明させていただきます。
テストの自動化と頻繁なデプロイを組み合わせることで、品質が向上し、リリースが迅速化されます。これらを実現するためにはいくかのポイントを理解することが必要です。

柔軟性

DevOpsパイプラインは、コードが移動し、検査およびテストされるステージに分割され、各ステージには明確な目的があります。
テストは各段階でより厳しくチェックされることで信頼性と品質が向上します。 さらに、ステージの数や工程に関係なく重要なことは、これらが一貫していることと、各ステージの目的が十分に理解され、全社的にサポートされていることです。
開発の初期段階では、コードの変更率が高くなります。アプリケーションが最終リリース段階にエスカレートし、コードがより徹底的にテストされるにつれて、変更率はほぼ停止にまで減少します。展開段階までに、コードは強化され、一般に公開する準備が整います。

DevOpsパイプラインの各ステージの目的はプロセスの各段階の範囲と目的に従って実行されます。さらに、これらはDevOpsパイプラインが通常の展開プロセス以外のコードエスカレーションのエピソードに対応する必要を理解しています。これらの企業は、DevOpsパイプラインに柔軟性を組み込んでいます。実際には、正式なパイプラインが提供する利点を失うことなく、リリースするコードを迅速に追跡するプロセスがあります。
このような迅速な追跡は、通常の展開手順とは別に、ホットフィックスコードが厳しく管理されたテストを受けるサイドステージを作成することを意味します。
次に、ホットフィックスがリリースされた後、柔軟な展開プロセスにより、制御された方法で、迅速に追跡されたコードが通常の段階に下流でマージされます。修正プログラムに対応する制御されたダウンストリームマージは、DevOpsパイプラインに柔軟性を提供するための手段です。
各企業は、通常の展開プロセスから外れる変更に対処するための独自の手法を持っています。これらのポイントは制御された安全な方法で、DevOps展開プロセスに柔軟性を実装できるようにすることです。長持ちするように構築された実行可能な DevOps展開パイプラインの作成に関しては、柔軟なシステムは厳格なシステムよりもうまく機能します。

テスト計画

適切なテスト自動化戦略を持つことは、DevOpsにとって非常に重要です。
これには持続可能で反復可能な継続的なプロセスを構築し、可能な限り迅速なフィードバックメカニズムを組み込む必要があります。さらに、初期段階では自動化のニーズに合わせてプロジェクトのスコープを設定する必要があります。こういったプロセスのすべてを自動化することはできないため、自動化に必要な労力に対して、最大の結果をもたらすテストの種類を優先します。これには、UIレベルでの回帰テストに加えて、テストピラミッドの下位レベルでの単体レベルおよび統合テストが含まれます。他のテストが正常に完了した後に実行されるエンドツーエンドのテストの数は限られているため、ユニットと統合を個別にテストすると見逃される可能性のある通信の問題などを特定できます。これらのテスト計画は、テストの自動化を設計および実装するために必要な専門知識を手に入れるのに役立ちます。
ただし、自動化するテストケースの数に関係なく、探索的テスト、Captchaなどの固有のケース、1回限りのテスト、アドホックテストなど、一部のタイプのテストは自動化が困難または不可能です。これらのテストは、人間が行う方が適切です。そのため、DevOpsでのテストに対する全体的なアプローチには、手動テストの計画も含まれます。

プロセス分割

DevOpsパイプラインの重要な部分は、コードが展開プロセスの特定の段階に入ると、コードを自動的にテストする機能です。
自動テストは、手動テストよりも効率的であることは言うまでもありませんが、自動テストが任意の方法で実行されると、効率が低下するリスクについても理解する必要があります。具体的には、DevOpsパイプラインの各ステージの目的から外れるテストを実施することは、時間の無駄に繋がるということです。
これらについて重要な点がプロセス分割です。
開発段階でのテストの目的は、アプリケーションがソースコードレベルで期待どおりに動作することを確認することです。通常、このようなテストは、ソースコードとともに出荷される単体テストを実行することによって実行されます。コンポーネントと機能のテストは、コードがコンポーネントに組み込まれ、コンポーネントが相互に作用するときに行われます。
このようなテストは自動化された作業であるにもかかわらず、通常、単体テストよりも時間がかかります。コンポーネントと機能のテストは通常、DevOps展開パイプラインのステージング部分で実行されます。数百万の仮想ユーザーを作成して、さまざまなネットワーク構成でアプリケーションと比較するパフォーマンステストは、プロセスの後半で実施できます。

パフォーマンステストは、コンポーネントおよび機能テストよりも時間がかかります。そして、パフォーマンステストと同じくらいの時間がかかるセキュリティテストがあります。理解しておくべき重要なことは、どの段階でもすべてのテストを実行できるからといって、必ずしも実行すべきとは限らないということです。
これらのテストには時間がかかります。すべての展開段階ですべてのテストを実行すると、時間のかかる冗長性が生じる可能性がある点について理解する必要があります。ポイントは、DevOpsの担当者と協力して、パイプラインの目的とテストの目的に従って、DevOpsパイプライン内でテストを実施するのに最適な場所を決定することです。さらに、DevOpsパイプラインを成功させるには、徹底的なテストが不可欠です。適切なタイミングで適切な場所でテストすることも同様です。 DevOpsパイプラインに沿って自動化されたテストを適切にセグメント化することは、効率的で信頼性の高い展開プロセスの実装に大きく役立ちます。

本番環境でのテストについて

本番環境でのテストについてのポイントについて説明させていただきます。
投資することで、そのワークフローをソフトウェア開発ライフサイクル (SDLC)の継続的で管理可能な資産にすることができますので紹介させていただきます。
最も重要なことが定義です。本番環境でのテストはWebアプリケーションであり、組み込みソフトウェア、インストール可能なソフトウェアなどは範囲外となります。ほとんどのテストは、SDLCのできるだけ早い段階で行われています。代わりに、TiPは、実稼働環境が実質的にかけがえのないいくつかの状況で、他のすべての形式のテストを補完します。ヒントは、ステージング環境で一致させることが不可能、または非現実的ないくつかの状況をもたらします。極端な規模での配信、エラー回復時の練習、顧客の多様性を表現しつつ、顧客のプライバシーを尊重するデータなどです。優れた投資収益率もそれらに該当します。

さらに詳しく解説させていただきます。
一点目がスケールのヒントです。一部のアプリケーションは単純に大きく、それらの施設や負荷を複製するには大きな費用がかかります。たとえば、複数のグローバルネットワークトポロジを維持することはコスト面において現実的ではありません。原則として、ほとんどの開発組織は、最終的な展開の前に製品を徹底的にテストできるステージング環境を維持しています。しかし、実際には、基本的にすべてのステージング環境は少なくとも1つの次元で本番環境よりも小さくなります。これは、ステージング環境ですべてのテストに合格した場合でも、本番環境にインストールすると新たな課題が発生することを意味します。
1桁以上の協調ノード、より徹底的にキャッシュをシャッフルするための数百時間の連続トラフィック、異常なデータの長いテールなどです。
ステージング環境の倍数のサイズのスレッドプール、まったく異なるクエリの最適化などです。ステージング環境は本番環境のモデルになり、アプリケーションが適度なストレス下で予測どおりに動作することを検証するサイトになります。ただし、本格的な実行は本番環境でのみ行われます。

二点目が事業継続性です。 TiPに焦点を当てることの利点の1つは、ビジネス継続性手法の有用なディザスターリカバリー(DR) を実践することです。
優れたTiPチームは、欠陥を迅速に診断し、それらに対する最善の対処法を判断し、状況に応じて既知の良好なリリースに確実に戻す方法を知っています。これらは組織のデジタルレジリエンスを検証するまたとない機会として考えることができます。

三点目が実際のデータを利用することです。 TiPの有用性のもう1つの側面は、テストデータを提供する方法です。従来のテストでは、顧客データに類似したデータを使用していましたが、もちろん、類似しすぎていないデータを使用していました。
これは、個々の顧客のセキュリティとプライバシーを侵害する可能性があるためです。ただし、生産データは目標を近似するだけではありません。彼らはターゲットです。現実的なデータを生成することは、驚くほど費用のかかる作業であり、実際のデータを正しく使用できることは大きな利点になる場合があります。
同時に、データが漏洩しないように厳格な管理を行う必要があります。プログラマーは、「test-password」がテストデータベースにアクセスすることを誤って開示することは有効です。ただし、実際の顧客の個人情報を共有することは重大な問題となるので注意する必要があります。

四点目がROIです。エンジニアリングとは常に選択が必要であり、コストと利益の適切なバランスを見つけることが重要となります。他のテストが不可能な場合にのみTiPを最後の手段と見なすべきではなく、チップが報われる状況の観点から考える必要があります。たとえば、特定の負荷テスト用に顧客データを適切にモデル化するテストデータを作成するなどです。 TiPのようなテストを実行することで、経験豊富なアナリストがデータ合成から解放され、収益を直接高める分析に集中できるようになれば、TiPはすぐに利益を上げます。

五点目が手順です。 TiPへの最初の最も重要なステップは、TiPを柔軟に検討できることです。それが整っていても多くのテクニックが残っています。実際、TiPは非常に大きく有益に成長したため、それ自体が専門となっています。特に、展開、リリース、およびリリース後の3つのフェーズにおけるTiP手法は、従来のすべての本番前ソフトウェアテストと同じくらい洗練され、複雑です。この範囲の方法を包括的に扱うことは、この紹介の範囲をはるかに超えています。ただし、TiPに関するいくつかの一般的なヒントは、記録する価値があります。

六点目が機能です。機能トグルを使用して設計と実装の第二の性質にし、すべてのヒントはTiPの戦略的役割を促進します。機能トグル(開発者はよく「機能フラグ」と呼んでいます) は、分析作業などで便利ですが、それをはるかに超える利点があります。これらは、市場投入までの時間の短縮と俊敏性を促進します。多くの場合、複雑なリンケージを分離します。これらは機能の切り替えにより、展開、テスト、および機能の提供のスケジュールがより独立したものになります。その結果、展開のカレンダーはリスクを最小限に抑えることができ、テストのスケジュールは従業員のスケジュールに適合し、機能の提供は自由に市場機会を最大限に活用できます。信頼できる機能トグルにより、これらの異なるドメイン間のトレードオフの管理がはるかに簡単になります。これらすべての点で、機能トグルは、TiPをリソースの制約に対処するための単なる手法ではなく、機能的なチームワークを強化し、顧客に価値を提供するまでの時間を短縮する戦略にするのに役立ちます。

七点目がSlackです。 Slackリソースをスケジュールして、アプリケーションの負荷が最も少ない時間と場所に最初のTiPの取り組みを集中できるようにします。 TiPにはリスクがありますが、適切な計画を立てれば、ほとんどのリスクを回避できます。これらは顧客の要求が少なく、多くのテストおよびエンジニアリングスタッフが待機しているときに、TiPを慎重にスケジュールします。さらに簡単なヒントを試して、それらから構築する必要があります。

まとめ

いかがでしたでしょうか？
エンドツーエンドテストについて説明させていただきましたので、参考にしていただけましたら幸いです。