【ITニュース解説】Automated Visual Testing with Selenium & Applitools

現代のウェブやモバイルアプリケーションの開発において、機能が正しく動作することと同じくらい、ユーザーが快適に感じる見た目（ユーザーインターフェース、UI）を提供することが非常に重要になっている。伝統的な機能テストは、ボタンが正しく動作するか、フォームが正常に送信されるか、ページが期待通りに読み込まれるかといった機能を検証することに焦点を当てる。しかし、これらのテストは、画面上の「見た目」という非常に重要な側面を見落としがちである。ここで、ビジュアルテストが登場する。

ビジュアルテストは、単に機能が動作するかどうかを確認するだけではない。アプリケーションのUIが開発者の意図した通りに表示されていることを保証する。これは、要素の配置がずれている、文字が重なっている、フォントが間違っている、レイアウトが崩れている、色の不整合があるといった視覚的なバグを発見するのに役立つ。これらは機能テストでは通常見逃されてしまう問題である。

例えば、「送信」ボタンが機能としては完璧に動作するが、CSSの変更によってそのボタンが画像の後ろに隠れてしまったシナリオを想像してみてほしい。機能テストではボタンが技術的に動作するため合格と判断されるだろうが、実際のユーザーは操作できないという問題に直面する。ビジュアルテストは、アプリケーションのスクリーンショットを基準となる期待されるデザインと比較し、ごくわずかな見た目の違いでさえも強調表示することで、このようなUIの不具合を捉える。

現代のアプリケーションは、様々なデバイスや画面サイズに適応する「レスポンシブ」な設計が求められるため、視覚的な検証はさらに不可欠になる。デスクトップ、タブレット、モバイルデバイスなど、あらゆる環境で一貫した洗練された見た目を保証する。ユーザーがピクセル単位で完璧なインターフェースを期待する中、ビジュアルテストをテスト自動化戦略に組み込むことは、見た目の後退（ビジュアルリグレッション）を防ぎ、ソフトウェア全体の品質を高めることにつながる。

ビジュアルテストとは、アプリケーションのユーザーインターフェース（UI）が、異なるブラウザ、デバイス、画面サイズでユーザーに正しく表示されることを保証するためのソフトウェアテストの一種である。アプリケーションのロジックや動作を検証する機能テストとは異なり、ビジュアルテストは、要素のずれ、フォントの不整合、レイアウトの崩れ、色の不一致といった視覚的な欠陥の特定に焦点を当てる。たとえば、CSSの変更によってボタンがわずかにずれた場合、機能テストは合格するかもしれないが、ビジュアルテストはそのずれを検出する。

なぜ伝統的な機能テストがビジュアルなバグを見逃すのかというと、Selenium、Cypress、Playwrightといった機能テストツールは、ボタンが動作するか、フォームが正しく送信されるか、計算が期待通りの結果を返すかといった機能を検証するのに優れているが、画面上で要素がどのように表示されているかまでは確認しないからである。ピクセルレベルのUIの問題（例えば、文字の重なり、不正確なフォントサイズ）は気づかれずに終わる。ブラウザ間の見た目の不整合（例えば、Safariではレイアウトが崩れるがChromeでは問題ない）も捉えられない。広告やポップアップなどの動的なコンテンツの変化がレイアウトを乱すことがあるが、機能テストはこれらの微妙な変化を検出しない。また、より小さい画面でのメニューの表示崩れなど、レスポンシブデザインの問題も、テストコードに明示的に記述されていない限り無視される。機能テストツールは、ウェブページの構造要素やユーザーとのインタラクションの検証に焦点を当てるため、ユーザー体験を損なう可能性のある視覚的な欠陥を見逃してしまうのである。

ビジュアルテストがUIの一貫性とユーザー体験をどのように向上させるかというと、Applitoolsのようなビジュアルテストツールは、AIを活用した視覚検証を取り入れることで、すべてのUIコンポーネントで一貫した見た目と操作感を維持するのに役立つ。これにより、意図しないUIの変更を様々な画面、ブラウザ、デバイス間で検出できる。隠れた要素、重なり合ったセクション、崩れたグリッドなどの問題が本番環境に到達する前に見つけることができる。デザイナー、開発者、テスターに素早いフィードバックを提供し、開発サイクルを短縮する。そして、洗練された、視覚的に正確なUIは、顧客の信頼とエンゲージメントを高め、ブランドイメージを向上させる。

Applitools Eyesは、AIを活用したビジュアルテストプラットフォームであり、Seleniumの機能を拡張してインテリジェントな画像ベースの比較を行う。従来のピクセル単位の比較ツールとは異なり、ApplitoolsはコンピュータビジョンとAIを使用して、アンチエイリアシングや軽微なレンダリングの差異など、重要でない違いを無視しながら、真のUIの欠陥を識別する。Applitoolsの主な機能には、AIを活用した視覚比較があり、ごくわずかなUIの違いでも検出するが、無関係なレンダリングの差異は無視する。ベースライン画像マッチングでは、参照となるスナップショット（ベースライン）を保存し、新しいテスト実行とそれらを比較して予期せぬUIの変更を検出する。クロスブラウザおよびクロスデバイステストにより、Chrome、Firefox、Edge、Safari、モバイルブラウザ、ネイティブアプリ全体でUIの外観の一貫性を保証する。スマート領域マッチングでは、テスターがタイムスタンプ、広告、回転バナーなどの動的なコンテンツを無視できるようにし、不必要なテスト失敗を避ける。自動メンテナンスとスマートテスト管理は、AIを使用して変更を（意図的か意図的でないかに）分類し、手動でのテストメンテナンスを減らす。CI/CDおよびクラウド統合により、Jenkins、GitHub Actions、Azure DevOpsなどのCI/CDツールとシームレスに統合し、パイプラインで自動化されたビジュアルテストを可能にする。

ApplitoolsとSeleniumを統合することで、テスターはSeleniumの機能テストを拡張して視覚的な検証を含めることができ、動作とUIの外観の両方が検証されることを保証する。この統合は、Seleniumがユーザーのアクション（ウェブページを開く、ボタンをクリックする、フォームを送信するなど）を自動化し、Applitoolsが各重要なステップの後でページ全体または特定の要素のスクリーンショットをキャプチャすることで機能する。Applitoolsは、新しい画像を以前のテスト実行から保存されたベースラインスナップショットと自動的に比較し、AIを活用した分析によって予期せぬUIの変更が検出された場合、ApplitoolsはそれらをTest Managerダッシュボードでレビューのためにマークする。

Applitools Eyesとは、ウェブサイト、ウェブアプリケーション、ネイティブモバイルアプリ、ドキュメント、メディアなど、様々なユーザーインターフェースをテストするための高度なAI搭載プラットフォームである。テストシナリオを機械的に検証する従来の自動化ツールとは異なり、Applitoolsは人工知能を活用して、何千ものUI要素とシナリオを瞬時に分析し、人間のような視覚的認識を模倣して、より正確なテストを可能にする。

Applitoolsにおける「ベースライン」とは、アプリケーションのUIの参照スナップショットのことである。これはアプリケーションの期待される外観として機能し、将来のすべてのテスト実行は、視覚的な違いを検出するためにこれと比較される。機能の正確性のみをチェックする伝統的なアサーションベースのテストとは異なり、Applitoolsはピクセル単位の比較を実行して、レイアウトのずれ、色の不一致、要素の欠落、レスポンシブデザインの問題など、視覚的な欠陥を検出する。

ベースラインが重要である理由は、UIの一貫性を検証し、アプリケーションが異なるバージョン間で統一された見た目を維持しているかを確認できるからである。要素のずれや欠落など、意図しないUIの変更を捉えることで、視覚的なバグを検出する。異なるブラウザやデバイス間でのUIレンダリングの違いを特定することで、クロスブラウザの互換性を保証する。新しい変更が既存のUIを壊さないことを保証することで、回帰テストに役立つ。

Applitoolsにおけるベースラインのライフサイクルは主に3つの段階からなる。まず「初回テスト実行」でベースラインが作成される。Applitoolsテストを初めて実行すると、UIのスクリーンショットをキャプチャし、この画像をApplitoolsダッシュボードにベースラインとして保存する。将来の実行で正確な比較を保証するために、ビューポートサイズ、ブラウザ、OS、テスト名などのメタデータも保存される。例えば、eコマースウェブサイトで「カートに追加」ボタンが緑色であるテストを行う場合、最初のテスト実行中にApplitoolsはこのデザインをベースラインとしてキャプチャし保存する。次に「その後の実行」では、スクリーンショットとベースラインが比較される。後続のテスト実行では、ウェブページの新しいスクリーンショットをキャプチャし、保存されたベースラインとピクセル単位で比較し、色変更、要素の欠落、レイアウトのずれなど、あらゆる違いを強調表示する。例えば、CSSの更新によって「カートに追加」ボタンが赤色に変わった場合、Applitoolsはその違いを検出してレビューのためにフラグを立てる。最後に「違いの処理」として、変更の承認または却下がある。Applitoolsが視覚的な変更を検出した場合、テスターには3つの選択肢がある。変更が予想されるものであれば、新しいスクリーンショットをベースラインとして承認する。今後のテスト実行はこの更新されたバージョンと比較されるようになる。変更が予想外であれば、UIバグとして報告する。開発者は変更を本番環境にプッシュする前に問題を修正できる。タイムスタンプや広告、ユーザーが生成したコンテンツなど、頻繁に変わる要素がある場合、それらを動的な領域としてマークすることで、誤検知を避けることができる。例えば、「カートに追加」ボタンがデザインの更新により緑色から赤色に変わった場合、テスターはこの変更を新しいベースラインとして承認できる。しかし、ボタンが完全に消えてしまった場合、テスターはその変更をバグとして却下することになる。

各ベースラインは、複数の属性を使用して一意に識別される。一つは「テスト名」で、各ビジュアルテストにはApplitoolsで割り当てられた一意の名前がある。例えば「ホームページビジュアルテスト」といった具合である。もう一つは「アプリケーション名」で、Applitoolsはプロジェクト間の混同を避けるために、ベースラインを特定のアプリケーションに関連付ける。例えば「Eコマースアプリ」といったものがある。これらの情報によって、Applitoolsは複数のテストやアプリケーションにわたる膨大な数のベースラインを正確に管理し、適切な比較を確実に行うことができる。