ビジュアルリグレッションテスト：その概要と必要なタイミング
Yunhao Jiao
機能テストが確実に見逃すソフトウェアバグのカテゴリがあります。アプリケーションは正しく動作しているのに、見た目がおかしいというケースです。CSSの競合によって画面外に押し出されたボタン。正常に送信できるフォームが、モバイルではラベルが重なって表示される場合。依存関係の更新後に正しいデータを読み込むが、レイアウトが崩れた状態で表示されるダッシュボードなどがその例です。
ビジュアルリグレッションテストは、こうしたバグを自動的に検出するための手法です。このガイドでは、その概要、仕組み、および完全なテスト戦略における位置づけについて解説します。
ビジュアルリグレッションテストとは？
ビジュアルリグレッションテストとは、アプリケーションのスクリーンショットを自動的にベースライン——正常な状態の基準——と比較し、バグを示す可能性のある視覚的な変化を検出する手法です。
新しいコード変更によってベースラインとの視覚的な差異が生じると、ビジュアルリグレッションテストがそれをフラグとして立てます。その後、人間のレビュアーがその変更が意図的なもの（デザインの更新や新機能）なのか、バグ（無関係な変更によって引き起こされたレイアウトの崩れ）なのかを判断します。
ビジュアルリグレッションテストが答える問いは「この変更の前と同じようにUIが表示されているか？」です。機能テストが答えるのは「UIは正しく動作しているか？」です。どちらの問いも重要です。最初の問いに答えられるのは、ビジュアルリグレッションテストだけです。
機能テストだけでは不十分な理由
機能テストは動作を検証します。フォームが送信されたか、APIが正しいデータを返したか、ユーザーが正しいページにリダイレクトされたか、といったことです。見た目については検証しません。
これが生み出すギャップ：
- モバイルユーザーにボタンが見えなくなるCSSの変更は、すべての機能テストをパスします（ボタンはDOMに存在しているため）
- テキストが読めなくなるフォントサイズの変更は、すべての機能テストをパスします（テキストはまだ存在しているため）
- サードパーティのウィジェットの読み込みによって発生するレイアウトのずれは、すべての機能テストをパスします（すべての要素が存在しているため）
- 重要なUI要素を覆ってしまうz-indexの変更は、すべての機能テストをパスします（その要素は技術的にはまだクリック可能なため）
これらは実際のユーザー体験上の問題です。機能テストではこれらを検出できません。手動QAであれば明らかなものは発見できるかもしれませんが、ビジュアルリグレッションテストであればすべてを体系的に検出できます。
ビジュアルリグレッションテストの仕組み
ベースラインのキャプチャ
初回実行時（または指定した基準実行時）に、各ページやコンポーネントのスクリーンショットをキャプチャしてベースラインとして保存します。このベースライン画像が「正常な状態」を表します。
比較
その後の実行では、新しいスクリーンショットをベースラインとピクセル単位で比較します（またはわずかなレンダリング差異を考慮した知覚的差分アルゴリズムを使用します）。閾値を超える差異はすべてフラグが立てられます。
人によるレビュー
フラグが立てられた差異は、人間のレビュアーに提示されます。レビュアーは意図的な変更を承認（ベースラインを更新）するか、意図しない変更を却下（バグ修正をトリガー）します。このレビューステップは避けられません——完全自動化されたビジュアルリグレッションは、正当なデザイン変更による誤検知が多すぎるためです。
ベースラインの更新
デザインの更新や新機能追加など、ビジュアルの変更が意図的なものである場合、ベースラインは新しい意図した状態を反映するように更新されます。
ビジュアルリグレッションテストのツール
Percy（BrowserStack）——最も広く採用されているビジュアルリグレッションツールです。ほとんどのCI/CDシステムおよびブラウザ自動化フレームワークと統合できます。ビジュアル差分の承認・却下を行うレビューインターフェイスを提供します。料金はスクリーンショットの数に応じてスケールします。
Chromatic——Storybookコンポーネントライブラリ専用に構築されています。各コンポーネントのビジュアルスナップショットを独立してキャプチャし、変更をフラグで通知します。デザインシステムチームに特に有用です。
Playwrightのビジュアル比較——Playwrightにはスクリーンショット比較機能が組み込まれています。専用ツールほど洗練されていませんが、すでにPlaywrightを使用しているチームには追加ツールが不要です。
TestSprite のビジュアルアサーション——TestSprite はエージェント型テストカバレッジの一環として、ビジュアル状態の検証機能を備えています。わずかなレンダリング差異でノイズが生じるピクセル単位の比較ではなく、TestSprite はビジュアルの意図を検証します。「チェックアウトボタンが表示されている」「エラーメッセージが表示されている」「モバイルでナビゲーションが折りたたまれている」といった検証です。このアプローチにより、ピクセル差分よりも誤検知率を低く抑えながら、実際のビジュアルバグを検出できます。
ビジュアルリグレッションテストが必要な場面
ビジュアルリグレッションテストは、次のような状況で最も高い効果を発揮します。
多くのコンシューマーを持つデザインシステム。共有コンポーネントライブラリが多数のアプリケーションで使用されている場合、ライブラリのビジュアル変更がすべてのコンシューマーに影響する可能性があります。ライブラリへのビジュアルリグレッションテストにより、変更が伝播する前にキャッチできます。
急速なUI開発。UIコンポーネントを頻繁にリファクタリングするAIコーディングツールを使用しているチームは、意図しないビジュアル変更が特に発生しやすい環境にあります。ビジュアルリグレッションテストは、機能テストでは見逃される外観の崩れを検出します。
複雑なレイアウトを持つアプリケーション。ダッシュボード、データテーブル、マルチカラムレイアウト、レスポンシブデザインは、ビジュアルバグが発生する面積が広くなります。レイアウトが複雑になるほど、ビジュアルリグレッションテストの価値は高まります。
メジャーリリース前。ビジュアルリグレッションテストを継続的に実施していないチームでも、開発サイクル中に蓄積されたビジュアル上の問題を発見するために、メジャーリリース前に実施すべきです。
テスト戦略におけるビジュアルリグレッションテストの位置づけ
ビジュアルリグレッションテストは機能テストの補完であり、代替ではありません。完全なテスト戦略には複数のレイヤーがあります。
- ユニットテスト：ロジックの正確性
- インテグレーションテスト：コンポーネント連携の正確性
- E2Eテスト（機能的）：フローと動作の正確性——TestSprite が自動的にカバー
- ビジュアルリグレッションテスト：外観の正確性
- パフォーマンステスト：速度と信頼性
ほとんどのチームにとって、最も効果的な順序は、まずE2E機能カバレッジを確立し（TestSprite を使用）、次に最もビジュアル的に複雑なフローやユーザー向けフローにビジュアルリグレッションテストを追加することです。
機能的なE2Eカバレッジから始める →