「Chrome、Safari、Firefox、Edge、それぞれの最新版と一つ前、さらに iOS と Android の実機で全画面を確認する」。これを毎リリースで回せるチームはほとんどありません。この記事は、テスト工程でクロスブラウザ・実機検証の範囲を現実的に決める方法と、対象外の環境で起きた問題を拾う仕組みの作り方を整理します。

全組み合わせを諦めるところから始める

ブラウザ・OS・端末・画面サイズの組み合わせは数百通りになります。全部を検証対象にすると、結局どれも浅くなります。先に「検証する範囲」と「報告で拾う範囲」を分けます。

対象マトリクスをシェアとリスクで決める

手順

アクセス解析から、ブラウザ×OS の利用割合を直近3か月分で出す
累計で利用者の9割に届くところまでを「必須環境」とする
残りのうち、業務上重要な利用者（主要顧客・社内利用）が使う環境を「準必須」に足す
それ以外は「対象外」と明記する

マトリクスの例

区分	環境	検証の深さ
必須	Chrome 最新 / Windows・macOS、Safari 最新 / iOS	全シナリオを毎リリース
準必須	Edge 最新、Android Chrome	主要シナリオのみ
対象外	古い OS・マイナーブラウザ	検証しない（報告で拾う）

リスクで重みを変える

同じ環境でも、画面ごとに重みを変えます。決済・ログイン・ファイルアップロードは環境差が出やすく、被害も大きいので必須環境すべてで確認します。静的な説明ページは Chrome だけで十分なことも多いです。

環境差が出やすい箇所を先に疑う

日付入力・ファイル選択など、ブラウザ標準部品を使う箇所
CSS の新しい機能（:has()、dvh など）を使った箇所
iOS Safari の画面下部バーやキーボード表示でのレイアウト
動画・音声の自動再生、クリップボード、通知など権限が絡む API

使う前に、機能ごとの対応状況を caniuse.com などで確認し、未対応の環境ではどう振る舞うかを実装時に決めておきます。後から対応するより安く済みます。

対象外の環境は「報告経路」でカバーする

対象外にした環境でも、利用者は存在します。そこで問題が出たときに気づけるよう、次の3点を用意します。

報告に環境情報が必ず付く導線：ブラウザ名・OS・画面サイズが自動で付けば、再現環境の聞き返しが要らなくなります
対象外環境からの報告の扱いを決めておく：「直す」「回避策を案内する」「対象外と伝える」のどれにするか、判断基準を1行で書いておく
月次で環境別の報告件数を見る：対象外環境の報告が増えていたら、マトリクスの見直し時期です

失敗例

「Safari は対象外」としていたところ、特定の iPhone でだけ送信ボタンが画面外に隠れる報告が複数届きました。利用者の1割強が iOS Safari だと、解析を見て初めて気づいた例です。マトリクスを決めたら、解析の数字で定期的に見直すところまでを運用に含めます。

リリース前の確認チェックリスト

必須環境の一覧が最新の解析データで更新されているか
決済・ログイン・アップロードを必須環境すべてで通したか
新しく使った CSS や API の対応状況を確認したか
対象外環境からの報告をどう扱うか、チームで共有されているか

Bugoon での実践

Bugoon のウィジェットはサイトにタグを埋め込むだけで使え、QA 担当者や非エンジニアがブラウザ上から報告できます。報告にはスクリーンショットとアノテーション、操作ステップに加えて、ブラウザや画面サイズなどの環境情報が自動で付きます。「対象外の環境で起きた問題を報告で拾う」という上の仕組みを、そのまま実践できます。報告は GitHub Issue に連携でき、カンバンボードで状況も追えます。

報告に含まれる環境情報を集計して、実際の利用環境がランキングで見えるようになれば、対象環境を選ぶ根拠としてさらに扱いやすくなります。

クロスブラウザ検証は全部やらず絞って拾う