自動UIテストのさまざまな種類に関する考察

このブログは「Exploring the Different Types of Automated UI Testing」を翻訳・一部加筆したものです。

ほとんどのチームの自動テストを確認すると、ほぼ確実に自動化されたUIテストが見つかるでしょう。世界中にユニットテストがもっと増えていることを願っていますが、UIテストはそれに次ぐ重要な存在だと考えています！自動化されたUIテストは、チームが顧客が使用するユーザーインターフェースを直接テストできるだけでなく、顧客の操作手順を自動化したり、特定の動作をトリガーしたり、下流の統合をテストしたりすることが可能です。しかし、多くのチームでは自動化されたUIテストがエンドツーエンドテストの同義語として使用されており、これにより、UIテストに自動化を活用する他の多くの方法を見逃しています。エンドツーエンドテストには確かに役割がありますが、特定のリスクをターゲットにしたテストや、よりターゲットを絞ったテストを実施する余地があります。

この記事では、自動化UIテストの5つの一般的な種類について解説します。ビジュアルテスト、エンドツーエンド（E2E）テスト、UIテスト、コンポーネントテスト、クロスブラウザテストを紹介します。

ビジュアルテスト

ビジュアルテストは、アプリケーションがユーザーにどのように表示されるかをテストする手法です。この手法は、アプリケーションが機能するかどうかを検証するものではなく、純粋にアプリケーションの見た目や表示方法に焦点を当てています。フォントが正しいか、余白、色、レイアウトなどが適切かどうかなど、詳細な点を確認します。ビジュアルテストでは、ゴールドマスターアプローチを採用しています。このアプローチでは、基準となる状態をキャプチャし、承認されたものを基準として設定します。以降のテスト実行では、新しいスクリーンショットを撮影し、基準と比較して差異を検出します。

ビジュアルテストは、チームが画面上のテキストを確認する代わりに採用すべき技術です。これは誰もが一度は行ったことがある主張ですが、画面上のテキストを確認するだけでは、そのテキストがどこにあるのかを教えてくれません。正しい色ですか？正しいフォントですか？正しいサイズですか？一部が画像で覆われていませんか？このようなテストは、悪い設計の主張の例です。なぜなら、私たちは画面上のテキストには関心がありますが、そのテキストが正しいことを暗黙の仮定として主張しているに過ぎず、視覚的なテストがない限り、その主張は確実ではありません。

軽減可能なリスク:

• フォント、サイズ、または色の間違い
• レイアウトの不一致
• 画像やアイコンの破損
• ページカラーの間違い
• レスポンシブデザインが正しく機能していない

実施方法

この分野には数多くのツールが存在し、その中にはより高度な機能を備えたものもあります。先ほど述べたように、これらのツールは基準画像を作成し、テスト中にキャプチャした画像と比較する仕組みです。ほとんどのツールはピクセル単位の比較に依存しており、完全な一致は不可能ですが、ツールでは5%の差といった閾値を設定可能です。ただし、その5%が会社のロゴである可能性もあるため、比較対象のページやページの一部を慎重に選択し、リスクを軽減する必要があります。より高度なツールはAIを活用して変更を検出しており、比較対象から除外したい領域を指定する機能も備えています。画像比較を行うため、データ管理の徹底が重要であり、スクリーンショット上のデータが一致していることを確認することで、誤検出を最小限に抑えることができます。

ビジュアルテストはいつ使用すべきか？

ビジュアルテストは実行に時間がかかるため、必要最小限に抑えるべきです。ただし、最も重要な画面には必ずUIテストを実施し、特にユーザーに表示されるエラーには重点を置くべきです。エラーテストでは、画面上のエラーメッセージを確認する方法は一般的ですが、これではエラーが赤色で表示され、画面内に表示され、明確なアイコンが付いていることを確認できません。これこそが実際にテストすべきポイントです。

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

E2Eテストは、UI上で特定の動作をトリガーし、その動作がスタック全体をナビゲートして画面上に結果を表示するまでを検証するように設計されています。これは単一ページ内の操作である場合もあれば、通常はアプリケーション内の複数のページにわたる操作である場合もあります。顧客の操作を完全に自動化することは、E2Eテストのもう1つの一般的なアプローチです。これらはシステム全体を検証する能力を提供します。

その強みは同時に弱点でもあります。通常、エンドツーエンド（E2E）UIテストでは、スタック全体を複数回往復するフルフローを実行するため、多くのコンポーネントが動的に関与し、テストの不安定性が増加する可能性があります。また、すべてのレイヤーを実行するため、実行速度も遅くなります。具体的には、APIへのデータ送信、APIでのデータ処理、データベースへのデータ送信、そして各ページごとにUIへのデータ返却といったプロセスが繰り返されるためです。

軽減可能なリスク:

• フロントエンドとバックエンドの統合に関する問題
• ページナビゲーションの失敗
• ユーザーの操作フローに関する問題
• ページ上の要素に関する問題

実施方法

エンドツーエンド（E2E）テストには、ユーザー操作をUI上でシミュレートできるツールが必要です。Webサイトの文脈では、クリック、待機、入力、ナビゲーションをシミュレートできるツールが必要です。ツールを調達した後、一般的なアプローチは、まず手動で操作を実行して画面とフローを理解し、その動作をツールで再現することです。

E2Eテストはいつ使用すべきか？

理想的な環境では、E2Eテストは重要なユーザーフローとビジネスプロセスに限定すべきです。これらのフローを検証することで、チームはシステム全体が正しく構成されており、すべてのコンポーネントが正常に通信しているという確信を得ることができます。E2Eテストを過剰に実施することは避けた方が良いでしょう。なぜなら、これらのテストは通常、フルスタックを複数回 traversing するため大規模になりやすく、テストの不安定性（フラッキーネス）のリスクも高まるからです。

UI テスト

UIテストはE2Eテストと非常に似ていますが、主な違いはフルスタックの使用を避ける点です。UIテストでは、インターフェース自体に焦点を当て、システム全体との相互作用には注目しません。UIテストを作成する際はAPIモックを使用します。これにより、2つの大きな利点があります。まず、UIのリスクを直接的にターゲットにできます。次に、モックによりデータへの制御が強化され、これによりUIを適切に検証できます。通常、UIテストはブラウザを使用して実施し、顧客が使用する環境に近い状態を再現するように努めます。

軽減可能なリスク:

• ページの一貫性のない動作/機能
• 各要素のレンダリング
• ページが必要なAPI呼び出しを行っていることを確認
• 正しいページレイアウト
• APIデータがページ上の正しい要素にマッピングされていることを確認

実施方法

UIテストには、UI上でユーザーの行動をシミュレートできるツールが必要です。したがって、Webサイトの文脈では、クリック、待機、入力、ナビゲーションをシミュレートできるツールが必要です。E2Eテストとほぼ同じですが、1つの大きな違いがあります。API呼び出しをモックできるツールも必要です。これにより、UIを隔離し、受け取るデータに完全な制御を保持できます。

UIテストはいつ使用すべきか？

リスクがページ自体の特定の動作や機能に限定されており、システム全体に及ぶものではない場合です。例えば、ページに特定のレイアウトが存在したり、クライアントサイドのJavaScriptがページ上に何かを表示している場合などが該当します。このような状況では、UIテストを使用し、IP呼び出しをモック化することで、特定のリスクをターゲットに絞り、テストをコンパクトに保つことが推奨されます。

コンポーネントテスト

ReactやAngularなどのフレームワークの進化により、UIテストの分野で比較的新しいアプローチとして登場したコンポーネントテスト。コンポーネントテストは、ページのコンポーネントを独立してテストできる手法で、フロントエンドのユニットテストと考えることができます。コンポーネントテストでは、単一のコンポーネントをレンダリングし、Webページ上に表示されたかのように操作できます。特定のデータを注入し、イベントをトリガーし、正しくレンダリングされているかを確認できます。一般的なUIは複数のコンポーネントから構成されており、現代のアプリケーションではこれらのコンポーネントが複数のページで再利用されます。コンポーネントテストでは、コンポーネントを孤立した状態で一度テストすることで、そのコンポーネントが使用されるすべてのページで正常に動作することを確認できます。コンポーネントの例としては、ボタン、アバター、メニュー、カード、モーダルなど、コンポーネントで構築されているページ上のあらゆる要素が該当します。

軽減可能なリスク:

• コンポーネント内の論理的なエラー
• 無効な状態のデータを使用
• イベントへの応答なし
• レンダリングエラー

実施方法

コンポーネントテストを実施するためには、コンポーネントを孤立した状態でレンダリングできるツールが必要です。通常は仮想ブラウザ内で実行されます。コンポーネントテストを仮想ブラウザで行う理由は、ブラウザの最小限の機能のみが必要だからです。これにより、実行速度が大幅に向上し、通常はミリ秒単位で完了します。テスト対象のシナリオに必要なすべての状態（データやプロップスなど）と共にコンポーネントが読み込まれます。外部依存関係をモックする必要がある場合もあります。例えば、コンポーネントがAPI呼び出しでデータを読み書きする場合、コンポーネントを孤立した状態でテストするためです。

コンポーネントテストはいつ使用すべきか？

アプリケーションがコンポーネントをサポートするライブラリを使用している場合、コンポーネントテストを活用すべきです。これらのコンポーネントがアプリケーションの複数の部分で使用されている場合、その必要性はさらに高まります。コンポーネントを孤立した状態でテストすることで、テストの規模が小さくなり、問題が発生した際のデバッグが迅速化されます。なぜなら、問題の原因がコンポーネントであり、APIやページ上の他の要素ではないことが明確になるからです。

クロスブラウザ/デバイス/プラットフォーム対応テスト

近年、標準化の共有により、デバイス、プラットフォーム、ブラウザにおける安定性が向上してきました。しかし、クロス-Xテストが必要な状況は依然として多く存在します。クロス-Xテストは、アプリケーションが実行されている環境の異なるバージョン（ブラウザのバージョン、異なるブラウザ、異なるオペレーティングシステムなど）でテストを行うことに焦点を当てています。多くのアプリケーションは、ブラウザAPIやオペレーティングシステムの機能など、環境の機能に依存しています。これらの環境は常に変化しており、通常は更新を制御できません。そのため、顧客が問題に直面しないように、これらのデバイス間でテストを実施することが重要です。

組み合わせの数は無限であり、このようなテストを実施するコストは、仮想マシン、実機、クラウドツール、およびそれらの維持管理コストの面で高額になる可能性があります。したがって、このようなテストは実際の顧客データに基づいて実施することが重要です。顧客が使用していないプラットフォーム/バージョンの組み合わせテストにはほとんど価値がありません。アナリティクスは、この洞察を得るための優れた手段です。

軽減可能なリスク:

• 古いプラットフォームAPIに依存している
• 異なるブラウザ/バージョンで機能が異なる動作をする
• レイアウトやレンダリングの問題
• パフォーマンスの問題
• 特定のバージョンでのテストが法的/契約上の要件となっている

実施方法

通常、このようなテストはUIテストやE2Eテストと同じツールを使用して実施されます。これらのツールの多くは、テストを異なるブラウザ、デバイス、バージョンで実行するように設定可能です。代替手段として、テストの実行先をデバイスクラウド（人気の組み合わせを便利に提供するサービス）に指定する方法があります。顧客の利用状況やビジネス要件に基づいて組み合わせを選択することが推奨されます。すべての組み合わせをテストすることは過剰であり、テストが完了しない可能性が高いです。

これらはいつ使用すべきか？

クロスブラウザテストは、ビジネスが複数のブラウザ、OSバージョン、デバイスをサポートしている場合に実施すべきです。また、実際のブラウザでのテストが法的義務となる場合もあります。契約上の理由や、それらを使用する大規模な顧客基盤を維持する必要があるため、レガシーデバイスへの対応を維持する必要があり、そのビジネスを失いたくない場合もあります。グローバル/多様な顧客基盤を持つ場合も、クロスブラウザテストを実施する正当な理由となります。

結論

UI自動テストは近年、数多くの新しいアプローチが導入され、著しい進化を遂げてきました。アプリケーションのUIを複数のレイヤーに分けて分析し、対象のリスクを軽減するための適切なレイヤーを特定することが重要です。また、実施したいアサーションの種類を考慮することも重要です。なぜなら、その種類が使用する技術を選択する要因となる場合が多いからです。

UIテストにレイヤードアプローチを採用することで、テストを小さくかつ的を絞ったものにすることができ、これにより通常はテストの作成、実行、デバッグがより迅速に行えます。大規模なE2Eテストに依存するだけの戦略はもはや有効ではありません。それらを超えるためのツールと技術は既に存在しており、それらを活用すべきです。

自動テストの連載シリーズについて

当社の自動テストシリーズの第2部にご参加いただき、ありがとうございます。このシリーズは、Richard Bradshaw氏とのコラボレーションによるものです。このシリーズでは、テスト自動化のさまざまな側面とその実装方法について深く探求していきます。

第1部では、マニュアルテストと自動テストのパラドックスについて考察しました。詳細はこちらをご覧ください。

次回の記事は、2025年6月24日に公開予定です。今回は、APIの自動テストのさまざまな種類とその最適な活用事例について解説します。お楽しみに！