2019年7月5日 / 最終更新日時 : 2022年1月7日 user 事例・ソリューション

テスト自動化における 10 のベストプラクティス #9: E2E テストの計画

エンドツーエンドテストとは

エンドツーエンド (E2E) テストは、テスト対象のアプリケーションで利用されるテクノロジーや各機能を繋ぎ、フロントエンドからバックエンドまでの一連のシナリオを検証します。

テスト範囲が狭い単体テストと比べ、E2Eテストはテスト範囲が広いため、「ブロードスタック (広範なスタック) テスト」あるいは「フルスタックテスト」と呼ばれることもあります。また、エンドユーザーの視点からアプリケーションのワークフローを検証することを重視するため、経営者と顧客にとって非常に有益なテストであると言えます。

E2Eテストは、通常、上流工程で実行されます。しかし、自動化されたE2Eテストはビルドが複雑で、脆弱であり、保守が困難な場合があります。そのため、単体テストや、統合テストよりもE2Eテストを縮小する傾向にあります。また、E2Eテストは、可能な限り本番に近い環境で実施されます。このため、単体テストや統合テストだけでは見逃しかねない本番環境でのタイミングや通信などの問題をE2Eテストは特定できるのです。

E2Eの例

たとえば、Webショッピングのアプリケーションのテストにおいて、支払いの詳細を検証するために外部のサービスを必要とする場合、以下のようなE2Eテストが考えられます。

ユーザーがログイン後、商品を検索し、商品をカートに入れ、支払い方法と配送方法を選択し、支払いを行い、ログオフする。
ユーザーがログイン後、出荷済みの注文を検索し、追跡情報を確認し、注文の配達についての情報を受け取り、ログオフする。
ユーザーがログイン後、出荷済みの注文を検索し、注文の取り消しを行い、商品を返却するための送付先ラベルを受け取り、ログオフする。
ユーザーがログイン後、アカウント情報を開き、新しい支払い方法を追加し、新しい支払い方法が有効であるという確認を受け取り、ログオフする。

これらのテストは、支払いの確認や出荷の追跡といった外部のサービスにアクセスするだけでなく、顧客情報、在庫、注文などの 1 つ以上のデータベースにもアクセスします。

E2Eテストのベストプラクティス

E2Eテストは、複雑で複数のステップが含まれるため、打鍵テストでは時間が掛かります。また、その複雑さが、E2Eテストの自動化を困難にし、実行速度が低下することもあります。
以下のベストプラクティスは、E2Eテストの自動化のメリットを生かしつつ、コストを抑えるのに役立つでしょう。

エンドユーザーの視点を保つ

アプリケーションの機能に焦点を当て、エンドユーザーの視点からテストケースを設計します。可能であれば、ユーザーストーリー、受け入れテスト、BDDシナリオといったドキュメントを利用してユーザーの視点を捉えます。

例外のテストを制限する

E2Eテストでは、使用頻度の高い操作を行う一般的なシナリオを集中的にテストします。
たとえば、上記のWebショッピングのアプリケーションの例で挙げた操作などです。
また、下流工程のテストでは、例外的なケースをテストします。たとえば、在庫数より多く商品を注文する操作や、返却可能期間を過ぎてから商品を返却する操作などです。

リスク分析を行う

E2Eテストを手動で実行した場合と自動化した場合のメリット・デメリットを考えつつ、アプリケーションのハイリスクな機能を集中的にテストします。ハイリスクな機能を特定するには、「失敗が起こる可能性」と「失敗がエンドユーザーに与える影響」の両方を考えます。

正しい順序でテストする

1つの単体テストが失敗した場合、欠陥の発生個所を特定するのは比較的簡単です。テストが複雑になり、繋がるアプリケーションのコンポーネントが増えるにつれ、潜在的な欠陥も増えます。その結果として、欠陥が見つかったときにデバッグするのが困難になります。

E2Eテストの前に単体テストや、統合テストを行うことで、比較的解決しやすい段階で問題を見つけることができます。そして、E2Eテストでは、初めに重要なスモークテストを行い、次にサニティチェックと他のハイリスクなテストケースを実行します。

テスト環境を管理する

環境のセットアップのプロセスは、できる限り効率的なものにし、一貫性を持たせます。テスト環境の要件を文書化し、テスト環境のセットアップに関わるシステム管理者やその他の担当者に要件を明確に伝えましょう。

文書には、テスト環境のOS、ブラウザー、他のコンポーネントの更新に対応する方法を含めます。理由は、テスト環境と本番環境をできる限り同じ状態にするためです。対応策のひとつとして、テスト目的で本番環境のイメージバックアップを使用する方法があります。

UI 要素の定義からテストロジックを分離する

自動化したE2Eテストをより安定したものにするために、UI要素の定義からテストロジックを分離します。オブジェクトリポジトリまたはページオブジェクトパターンを使用して、テストロジックがユーザーインターフェイスと直接やり取りしないようにします。そうすることで、UI構造の変化のためにテストが失敗する可能性が低下します。

※Ranorex（Ranorex Studio）のオブジェクトリポジトリは、UI要素の定義から自動化テストを分離します。

UI要素の待機時間を適切に処理する

テスト対象のアプリケーションにおいて、画面のロードや、UI要素の表示の待ち時間にE2Eテストを失敗させてはいけません。

※Ranorex（Ranorex Studio）では、「UI要素が出現するまで、指定の時間だけ待機するアクション」を追加できます。指定した待機時間を過ぎると、待機が解除され、テストは失敗します。待機時間は、最短でも「UI 要素の表示に通常かかる時間」に設定するべきですが、長過ぎてもいけません。待機時間が長過ぎることは、アプリケーション、インターフェイス、環境の問題を示している場合があります。また、エンドユーザーをイライラさせます。さらに自動化テストにおいて、長過ぎる待機時間は、E2Eテストの実行全般に影響する場合もあります。一般的に、待機時間には、「UI要素の表示に通常かかる時間」より少しだけ長い時間を設定します。

正しいデバイスを選択する

モバイルテストでは、最も利用されているiOSとAndroidのバージョンを実機上でテストします。それほど利用されていないバージョンは、シミュレーター/エミュレーターを使用します。また、Wi-Fi 接続とモバイル接続 (3GからLTEまでさまざまな速度) の両方をテストします。

セットアップ/ティアダウンのプロセスを最適化する

セットアップ/ティアダウンのプロセスを使って、テスト環境の使用準備を常に整えておくことです。自動化スクリプトを使用し、テスト実行前にテストデータを作成し、テスト実行後に消去します。そうすることで、テスト環境を初期化して、次のテストに備えることができます。

まとめ

ユーザビリティやユーザーエクスペリエンスといった自動化が難しい部分に対応するには、E2Eテストの一部として、打鍵テストと探索的テストを計画することが重要です。また、完全でバランスの取れたテストにするには、自動化されたパフォーマンステストと負荷テストを含めることです。これらのテストについては、本シリーズ「テスト自動化における 10 のベストプラクティス」の最終回でご紹介します。

（この記事は、開発元 Ranorex 社 Blog 「10 Best Practices in Test Automation #9: Plan E2E Testing」2018年6月27日の記事を元にしています。）