自動テストが見逃すビジュアルバグ: ユーザーが見るものをテストする方法

ビジュアルバグとは、背後のコードは問題なさそうなのに、人が画面上で目にする欠陥です: 覆われたボタン、読めないテキスト、誤ったアイコンなどです。自動テストがそれを見逃すのは、画面ではなくページのコードに尋ねるからです。

ビジュアルバグとは?

エンドツーエンドテストは緑です。そこへ顧客がチェックアウトページのスクリーンショットを送ってきます: 注文合計がプロモーションバナーの後ろに隠れています。すべての自動テストが合格したのは、すべての自動テストが画面ではなくページのコードに尋ねたからです。このようなビジュアルバグのためにあるのがビジュアルテストです: ユーザーが実際に見るものを確かめます。

await expect(
  page.getByTestId('order-total')
).toBeVisible();

この記事では、その隙間がどこから生まれるのか、どのバグがそこに落ちるのか、そしてユーザーと同じように画面を見るエンドツーエンドテストをどう作るのかを説明します。

Playwright、Cypress、Selenium にとって「表示されている」とは

コードで書いたエンドツーエンドテストは、セレクターで要素を見つけ、それについて何かをアサートします。ユーザーの体験に最も近いアサーションは「表示されているか?」です。各ツールはそれぞれのやり方でこれに答えますが、どれも画面を見てはいません。

Playwright

Playwright の toBeVisible() は、要素に空でないバウンディングボックスがあり、visibility: hidden のスタイルがなければ合格します。ドキュメントには、opacity: 0 の要素も表示されているものと見なすと書かれています。別の要素がその要素を覆っていないか、テキストが何色かは問いません。

操作はアサーションより厳密です。クリックの前に、Playwright はクリック位置でその要素がヒット対象であることを確かめるので、覆われたボタンに対するクリックはタイムアウトまで待ちます。Playwright には、ビューポートの中になければならない要素のための toBeInViewport() もあり、toHaveText() は既定で要素の textContent を読みます。

Cypress

Cypress 16 以降、既定の可視性の確認はブラウザー自身の Element.checkVisibility() に委ねられています。要素は、幅や高さがない、display: none、visibility: hidden、またはアサーションの場合は opacity: 0 のときに非表示と見なされます。クリックの前に、Cypress は要素の中心が覆われていないことを確かめます。

アサーションは別の話です。Cypress のドキュメントにははっきりこう書かれています: 「新しいアルゴリズムはヒットテストを行わないため、覆われた要素を表示されているものとして報告します。」

Selenium

Selenium のドキュメントの言葉を借りれば「あらゆる条件を網羅することは不可能」なため、Selenium の isDisplayed() は W3C WebDriver 仕様では定義されていません。代わりに Selenium は大きな JavaScript 関数を実行し、要素のスタイル、サイズ、それを切り取る祖先要素を評価します。別の要素がその上に描画されていないか、背景に対してテキストが読めるかは確かめません。

覆われた要素へのクリックは「element click intercepted」エラーで失敗します。テストが読み取るだけの要素は、それでも表示されていると報告されます。

コードで書いた確認を通過する 9 つのビジュアルバグ

これらのバグはどれも、要素をサイズと正しいテキストとともにページのコードの中に残します。要素が存在する、表示されている、そのテキストを持っている、とアサートするコードのテストは合格します。ユーザーが見るものは別物です。

1. 別の要素に覆われた要素

Cookie バナー、チャットウィジェット、固定ヘッダー、閉じ損ねたダイアログが、多くの場合 z-index の変更のあとに、要素の上に重なります。上のどの定義でも、要素は今も表示されています。クリックは拒否されますが、価格、エラーメッセージ、確認文のように読み取るだけのテストは、誰にも見えないのに合格します。

2. 誰にも読めないテキスト

白地に白のテキスト、テーマ変更後の灰色の上の灰色、壊れたアニメーションで透明のまま残ったラベルです。色を読む可視性の確認はありません。Playwright の toBeVisible() は opacity: 0 でも合格します。

3. 途中で切れたテキスト

ボックスに対して長すぎるラベルが省略記号で終わるか、固定の高さが 2 行目を隠します。ページにはすべての単語が残っているので、テキストを読むアサーションは合格します。ユーザーが読むのは「Confirm your or...」です。

4. 画面の外に押し出された要素

幅の広い表や長い見出しが、狭い画面の右端の外へ「購入」ボタンを押し出します。ボタンのサイズは変わらないので、toBeVisible() は合格したままです。テストがこれを捉えるのは、そのボタンについて toBeInViewport() も問うた場合だけです。

5. 誤った画像やアイコン

商品に別の商品の写真が表示される、アイコンフォントが失敗して空の四角が残る、スプライトの更新で 2 つのアイコンが入れ替わる。画像要素とアイコンのクラスは変わっていないので、コードは正しく見えます。

6. CSS の変更で崩れたレイアウト

1 つのルールが余白、flex の方向、グリッドの列を変えます。カードが重なり、列が別の列の下に落ち、フォームの整列が崩れます。すべての要素はテキストとサイズを保ったままコードの中にあるので、すべてのアサーションが合格します。

7. 収まらない翻訳済みラベル

ドイツ語やフランス語の単語は、英語より長くなることがよくあります。ラベルがボタンからはみ出し、2 行目に折り返され、隣のボタンを押しのけます。翻訳自体は正しいので、テキストのアサーションはどの言語でも合格します。

8. 読み込みに失敗したフォント

Web フォントの読み込みに失敗すると、ブラウザーは別のフォントで代用します: 行の折り返しが変わり、フォントで描かれたアイコンは空の四角になります。コードの中のテキストは同じなので、何も失敗しません。

9. 止まらないスピナー

データが届いて行がページに追加されますが、読み込み中のオーバーレイが上に残ったままです。テストはコードの中に行を見つけて合格します。ユーザーはスピナーの前で待ち続けます。

ビジュアルバグの種類: DOM の確認が見逃し、ビジュアルアサーションが捉えるもの

同じバグを種類別に見ます。DOM の確認はページのコードに尋ねます: 要素はあるか、サイズとテキストを持っているか? ビジュアルアサーションは画面を見ます: 要素はあるべき場所で、あるべき見た目をしているか?

スクリーンショットによるビジュアルリグレッションテストで捉えられるか?

はい、それが一般的な答えです。ビジュアルリグレッションテストは、画面の画像を以前に撮った基準画像と比較します。

Playwright には toHaveScreenshot() として組み込まれています。ドキュメントは、ブラウザーの描画がホストの OS、そのバージョンと設定、ハードウェア、ヘッドレスモードによって変わりうると注意しています。そのため、ブラウザーとプラットフォームごとに基準画像を持つことになります。

Cypress はスクリーンショットを撮りますが、ドキュメントには「画像比較自体は行わない」とあります。比較はプラグインやビジュアルテストサービスが追加します。

Percy や Applitools Eyes のようなサービスは、コードで書いたテストに画像のチェックポイントを追加します。Percy はテスト実行中にスクリーンショットを撮って比較します。Applitools Eyes はテストの中に確認の呼び出しを追加します。

これらのツールの比較は比較調査を参照してください。

手動テストでは隙間が埋まらない理由

人なら、これらのバグはどれもひと目で分かります。だからこそ多くのチームは、今もリリース前にアプリケーションをクリックして回ります。しかし、手動テストには限界があります。

ユーザーが見るものを見るエンドツーエンドテストはどう作るか?

どのツールを使うにしても、6 つの原則によって、エンドツーエンドテストはユーザーと同じようにアプリケーションを体験できるようになります。

1. 1

   実際のアプリケーションを操作する

   人と同じように、実際の画面でクリックし、入力します。覆われたボタンを押せないテストは、ユーザーが行き詰まる場所で失敗します。

2. 2

   表示されているものを確かめる

   画面を 3 つの観点で確かめます: 要素の見た目が正しいかを画像で、正しい内容を示しているかを文字で、すべてがあるべき場所にあるかを配置で確かめます。

3. 3

   まず要素を見つけ、それから比較する

   移動したウィンドウやスクロールしたページはバグではありません。テストは要素を今ある場所で見つけてから、その見た目を判断すべきです。

4. 4

   ノイズは無視し、本当の変化は決して見逃さない

   画面はコンピューターごとにわずかに異なるので、比較は描画のノイズを無視しつつ、人が気づくあらゆる変化を捉えるべきです。

5. 5

   エビデンスを示す

   失敗したときは、期待する画面と検出した画面を並べ、変化に印を付けて、チームの誰もが読めるようにすべきです。

6. 6

   変更のコストを低く保つ

   アプリケーションを意図的に変えたとき、新しい見た目の採用は書き直しではなくワンクリックで済むべきです。

GUI Test Studio がユーザーの見るものをテストする方法

GUI Test Studio は、これらの原則に基づいてエンドツーエンドテストをコードなしで作ります。Web アプリ、Windows デスクトップアプリ、Android スマートフォン、ゲームを、1 種類のテストでテストします。詳しくはビジュアルテストと GUI テストを参照してください。

ワークフローを一度記録する

GUI Test Runner-Recorder で記録をクリックし、いつもどおりにワークフローを行います: マウス、キーボード、画面が記録されます。Claude、ChatGPT、または当社提供もしくは持ち込みのローカル AI モデルにワークフローをプロンプトで説明して、代わりに記録してもらうこともできます。

停止すると、テストが何を検証すべきかを尋ねられます。既定の答えのままなら、クリックした要素や入力した要素には、操作の直前にビジュアルアサーションが付きます。メニュー、ダイアログ、メッセージのように自然に表示されるものには、グループアサーションが付きます。

画面に表示されるもののアサーション

それぞれにガイドがあります: ビジュアルアサーション、テキストアサーション、レイアウトアサーションとグループアサーションです。

要素を見つけてから比較する

すべてのビジュアルアサーションは 2 つのフェーズで判定されます。検索フェーズは要素が画面上にあるかを問い、アサーションのタイムアウトまでそれを待ちます。GTS Engine + AI はまずアクセシビリティ情報やページ自身の要素を通じてアプリケーションに尋ね、アプリケーションが答えない場合は視覚で要素を見つけます。GUI Test Studio がすべての要素を見つける方法を参照してください。

要素が記録時とは別の場所で見つかった場合、その後のクリックは今ある場所に向けられます。また、テストがバナーの上から盲目的にクリックすることはありません: 要素が覆われていれば、クリックの前にそのアサーションが不合格になります。

何が変わったかを読む

実行後、信頼度レポートに各アサーションが表示されます。期待画像と検出画像が並び、変化が強調表示され、判定が平易な一文で示されます。

拡大

AI スマート分析がオンなら、不合格になったアサーションは AI による再確認も受け、何が変わったかが平易な言葉で説明されます。クラウドモデルと自分のキーで、または自分のコンピューター上のローカル AI モデルで実行できます: 当社提供のものか、持ち込みのものです。

意図した変更なら、レポートから新しい見た目を採用すれば、以後テストはそれを期待します。コマンドラインの gtr-cli は、同じテストを任意の CI/CD パイプラインから、ビルドのたびに実行します。

どのアサーションがどのビジュアルバグを捉えるか

9 つのバグを、それぞれを捉える GUI Test Studio のアサーションとともに改めて挙げます。

拡大

コードで書いた確認が今も必要な場所

要点

• 1ビジュアルバグは、コードを正しいまま、画面を誤ったままにします。要素はサイズとテキストを保ってそこにあるのに、誰にも見えません。
• 2コードで書いた表示の確認は、決して画面を見ません。覆われた要素、読めないテキスト、誤ったアイコンは、そのどれも通過します。
• 3スクリーンショットと手動テストは、代償と引き換えに隙間を埋めます: ブラウザーとシステムごとのリファレンス画像か、ビルドのたびに何時間もの注意です。
• 4まず要素を見つけてから比較し、描画のノイズを無視しつつ本当のリグレッションをすべて捉え、エビデンスを示します。
• 5GUI Test Studio はそれをコードなしで行います: ワークフローを一度記録すれば、すべてのビジュアルアサーションがユーザーの見る画面を比較します。

質問

Selenium、Playwright、Cypress、Percy、Applitools Eyes は、それぞれの所有者の商標です。