影響が大きく、労力が最小限のクロスブラウザテスト

クロスブラウザテストは、時間と手間がかかります。 ただし、開発者は本質的に怠惰です。DRYの原則を順守し、サードパーティのライブラリを利用して、手作業で行う必要があることを自動化するスクリプトを作成します。 怠惰であることは私たちを優れた開発者にするものです。

クロスブラウザテストの従来のアプローチは、「適切に」、オーディエンスが使用するすべての主要なブラウザでテストし、テストしたと言うために、古いブラウザまたはよりあいまいなブラウザに徐々に移行することです。 または、時間とリソースが短い場合は、アドホックブラウザーの小さなサブセットをテストし、バグがないことでアプリケーションの整合性に自信が持てることを期待します。 最初のアプローチは「良い」開発を具体化しますが非効率的ですが、2番目のアプローチは怠惰を具体化しますが信頼性がありません。

SmashingMagの詳細：

• ノアのモバイルユーザビリティテストへの移行
• アプリ、ゲーム、モバイルWebのテスト自動化の基本
• 独自のフロントエンドWebサイトテスト計画を作成する方法
• 世界最高のオープンデバイスラボはどこにありますか？

次の15分間で、労働集約的ではないだけでなく、バ​​グを見つけるのにより効果的なテスト戦略を説明することで、無駄な労力の時間を節約したいと思います。 BBC Visual Journalismのテスト開発者としての経験を生かして、単に「すべてをテストする」よりも、より関連性が高く価値のある現実的なテスト戦略を文書化したいと思います。

環境

余談ですが、私たちのチームでは手動テスト以上のことを行っていることを指摘する価値があります。 クロスブラウザーテストは、単体テスト（Jasmine / QUnit）、機能テスト（Cucumber）、および必要に応じて自動視覚回帰テスト（Wraith）に代わるものではありません。 実際、自動テストは長期的には安価であり、アプリケーションが特定のサイズに達したときに不可欠です。

ただし、一部のバグは特定のブラウザーでのみ発生し、テストの自動化はまだブラウザー間のテストの領域に確実に参入していません。 自動スクロールイベントがiPhone4で表示されたときに、タイトルの半分が隠されていることをコンピューターはどのようにして知ることができますか？ それが問題であることをどうやって知るのでしょうか？ 人工知能が、コンピューターがあなたが構築したものを理解し、あなたが実証しようとしている物語や芸術性を理解できるようになるまで、常に手動テストが必要になります。 手動で実行する必要があるものとして、クロスブラウザテストプロセスを可能な限り効率的にするのは私たち自身の責任です。

あなたの目的は何ですか？

クロスブラウザテストに盲目的に飛び込む前に、それから何を得たいかを決めてください。 クロスブラウザテストは、次の2つの主な目的があると要約できます。

1. バグの発見これには、修正するバグを見つけるためにアプリケーションを壊そうとすることが含まれます。
2. 健全性チェックこれには、オーディエンスの大多数が期待されるエクスペリエンスを受け取っていることを確認することが含まれます。

この記事から最初に取り上げてほしいのは、これら2つの目的が互いに矛盾しているということです。

一方では、Chrome（デスクトップ）、Chrome（Android）、Safari（iOS 9）でテストするだけで、英国の視聴者のほぼ50％の体験を確認できることを知っています。 一方、私の目的がバグを見つけることである場合は、積極的にサポートする必要のある最も問題のあるブラウザー（この場合は、IE8とネイティブのAndroidブラウザー2）にWebアプリを配置したいと思います。

これら2つのブラウザーのユーザーは、オーディエンスの減少する割合（現在、約1.5％）を占めています。これにより、健全性チェックを目的とする場合、これらのブラウザーでのテストは時間の無駄になります。 ただし、あいまいなレンダリングエンジンにスローされたときに、適切に設計されたアプリケーションがどのように壊れるかを確認したい場合は、これらのブラウザをテストするのに最適です。

従来のテスト戦略では、当然のことながら、一般的なブラウザでのテストに重点が置かれています。 ただし、不釣り合いな数のバグは、よりあいまいなブラウザにのみ存在します。これは、従来のテストモデルでは、テストが終了するまで明らかになりません。 その後、ジレンマに直面します…

ロングテールテストフェーズの後半でバグを見つけた場合はどうしますか？

1. バグは無視してください。
2. バグを修正し、何も壊れていないことを願っています。
3. バグを修正し、以前にテストしたすべてのブラウザで再テストします。

理想的な世界では、最後のオプションが最適です。これは、すべてのブラウザーが引き続き期待どおりに機能していることを本当に確信できる唯一の方法だからです。 ただし、これは非常に非効率的であり、複数回実行する必要がある可能性があります。 これは、バブルソートに相当する手動テストです。

したがって、Catch-22の状況に陥っています。効率を最大化するために、クロスブラウザーのテストを開始する前にすべてのバグを修正したいのですが、テストを開始するまで、どのバグが存在するかを知ることはできません。

答えは、私たちがどのようにテストするかについて賢明であることです。私が3フェーズ攻撃と呼んでいるもので、段階的にテストすることにより、バグ発見と健全性チェックの目的を達成します。

三相攻撃

あなたが戦争地帯にいると想像してください。 あなたは悪者が街の反対側にある本部に身を寄せていることを知っています。 自由に使えるのは、特別捜査官、戦闘で強化されたゲリラのクラックチーム、そして軽装備の地元民兵の大規模なグループです。 あなたは都市を取り戻すために三相攻撃を開始します：

1. 偵察スパイを敵の本部に送り、悪者がどこに隠れているのか、何人いるのか、戦場の一般的な状態を把握します。
2. レイドクラックチームを敵の真ん中に送り、1回の激しいサプライズアタックで悪者の大多数を排除します。
3. クリアランス地元の民兵を派遣して、残りの悪者をピックし、エリアを確保します。

同じ軍事戦略と規律をクロスブラウザテストに取り入れることができます。

1. 偵察開発マシンの一般的なブラウザで探索テストを実施します。 バグが隠れている可能性のある場所の感触をつかんでください。 発生したバグを修正します。
2. ほとんどのバグを示す可能性が高い、問題のある少数のブラウザで手動でテストします。 発生したバグを修正します。
3. クリアランス正気度チェックにより、オーディエンスの中で最も人気のあるブラウザーがクリアされ、期待されるエクスペリエンスが得られます。

戦場にいる場合でも、デバイスのテストを行っている場合でも、フェーズは最小限の時間で始まり、操作がより安定するにつれて成長します。 できることは非常に多くの偵察だけです。非常に短い時間でいくつかのバグを見つけることができるはずです。 RAIDはより強力で時間がかかりますが、非常に価値のある結果をもたらし、戦場を大幅に安定させます。 クリアランスフェーズはすべての中で最も骨の折れるものであり、発見されていない悪者がどこからともなく出てきてあなたに危害を加えた場合に備えて、あなたはまだあなたについての知恵を保つ必要があります-しかし、戦場が今は安全です。

3フェーズ攻撃の最初の2つのステップは、最初の目的であるバグ発見を実現します。 アプリケーションが堅牢であると確信できる場合は、攻撃のフェーズ3に進み、オーディエンスのブラウジング動作の大部分に一致する最小数のブラウザーでテストし、目的2である健全性チェックを実行する必要があります。 そうすれば、アプリケーションがオーディエンスのX％で機能することを、定量的に裏付けられた自信を持って言うことができます。

セットアップ：敵を知る

軽く戦争に参加しないでください。 テストを開始する前に、ユーザーがコンテンツにどのようにアクセスしているかを確認する必要があります。

（Google Analytics、または使用しているツールから）オーディエンス統計を調べ、データをスプレッドシートで読み取って理解できる形式で取得します。 各ブラウザとオペレーティングシステムの組み合わせを、市場シェア全体の関連する割合とともに確認できるようにする必要があります。

ブラウザの使用統計は、簡単に利用できる場合にのみ役立ちます。テストする必要のあるブラウザ/ OS /デバイスの組み合わせの長くて気の遠くなるようなリストが表示されたくない場合です。 その上、すべての可能な組み合わせをテストすることは無駄な努力です。 Web開発者の知識を使用して、統計をヒューリスティックに統合できます。

ブラウザの使用統計を簡素化する

Web開発者として、デスクトップブラウザが実行されているOSは特に気にしません。ブラウザのバグが一方のOSに適用され、もう一方のOSには適用されないことは非常にまれです。そのため、すべてのオペレーティングシステムでデスクトップブラウザの統計をマージします。

また、誰かがFirefox40とFirefox39のどちらを使用しているかについても特に気にしません。バージョン間の違いはごくわずかであり、バージョンの更新は無料で、多くの場合自動的に行われます。 ブラウザの統計情報を理解しやすくするために、IEを除くすべてのデスクトップブラウザのバージョンをマージします。 古いバージョンのIEは問題があり、広く普及していることがわかっているため、それらの使用量を追跡する必要があります。

同様の議論がポータブルOSブラウザにも当てはまります。 モバイルChromeまたはFirefoxのバージョンは定期的かつ簡単に更新されるため、特に気にしません。バージョンをマージします。 ただし、ここでも、IEのさまざまなバージョンに関心があるため、それらのバージョンを個別にログに記録します。

Androidについて話している場合、デバイスのOSバージョンは関係ありません。 重要なのは、使用されているネイティブAndroidブラウザーのバージョンです。これは、問題のあるブラウザーとして悪名高いためです。 一方、Safariのバージョンは本質的にOSにリンクされているため、デバイスが実行しているiOSのバージョンは非常に重要です。 次に、他のデバイス用のネイティブブラウザが多数あります。これらは、オーディエンス全体のごくわずかな割合を占めるため、バージョン番号もマージされます。

最後に、ブラウザの人気が急速に高まっている新しい波があります。アプリ内ブラウザで、主にソーシャルメディアプラットフォームに実装されています。 これは私たちにとってまだ新しい分野であるため、すべてのアプリ内ブラウザプラットフォームとそれぞれのOSを一覧表示することに熱心です。

ドメインの専門知識を使用して関連する統計をマージしたら、オーディエンスの0.05％未満を占めるすべてのブラウザーを削除して、リストをさらに絞り込みます（必要に応じてこのしきい値を自由に調整してください）。

デスクトップブラウザ

ポータブルブラウザ

アプリ内ブラウザ

完了すると、スプレッドシートは次のようになります（今のところ「優先度」列は無視してください。後で説明します）。

これで、簡略化されたスプレッドシートが作成され、Web開発者の観点から主要なブラウザーが表示され、それぞれが市場シェアの合計パーセンテージに関連付けられています。 このスプレッドシートを最新の状態に保つ必要があることに注意してください。 月に1回の更新で十分です。

これで、3フェーズ攻撃に着手する準備が整いました。

1.偵察：ブラウザに依存しないバグを見つける

テストするデバイスを作成することを考えるずっと前に、可能な限り最も簡単なことを実行してください。お気に入りのブラウザーでWebアプリを開きます。 あなたが完全なマゾヒストでない限り、これはChromeまたはFirefoxである可能性が高く、どちらも安定していて最新の機能をサポートしています。 この最初の段階の目的は、ブラウザに依存しないバグを見つけることです。

ブラウザに依存しないバグは、アプリケーションへのアクセスに使用されるブラウザやハードウェアとは関係のない実装エラーです。 たとえば、Webページが公開され、ランドスケープモードのHTCOneでページがゴミに見えると不満を言う人々からあいまいなバグレポートを受け取り始めたとします。 AndroidのUSBデバッグモードを使用し、StackOverflowでヘルプを検索して、使用されているブラウザのバージョンを判断するのに多くの時間を浪費します。これをどのように修正するのか疑問に思います。 知らないうちに、このバグはデバイスとは関係ありません。むしろ、ページが特定のビューポート幅でバグがあるように見えます。これは、問題のデバイスの画面幅と同じです。

これは、ブラウザに依存しないバグの例であり、ブラウザ固有またはデバイス固有のバグとして誤って現れています。 バグレポートがノイズとして機能し、問題の根本原因をわかりにくくすることで、長く無駄な道をたどってきました。 自分に有利に働き、この種のバグを最初からキャッチします。労力を大幅に減らし、先見性を少し高めます。

クロスブラウザテストを開始する前にブラウザに依存しないバグを修正することで、全体的に発生するバグが少なくなるはずです。 私はこれを溶ける氷山効果と呼ぶのが好きです。 私たちは水面下に隠されている虫を溶かし、海で墜落したり溺れたりするのを防いでいます-そして私たちはそれをしていることにさえ気づいていません。

以下は、ブラウザに依存しないバグを発見するために開発ブラウザで実行できることの短いリストです。

• サイズを変更して、応答性を確認してください。 ファンキーなブレークポイントはどこかにありましたか？
• ズームインおよびズームアウトします。 画像スプライトの背景位置が斜めにノックされていますか？
• JavaScriptをオフにした場合のアプリケーションの動作を確認してください。 あなたはまだコアコンテンツを手に入れていますか？
• CSSをオフにした状態でアプリケーションがどのように表示されるかを確認してください。 マークアップのセマンティクスはまだ意味がありますか？
• JavaScriptとCSSの両方をオフにしてみてください。 許容できる経験を得ていますか？
• キーボードのみを使用してアプリケーションを操作してみてください。 すべてのコンテンツをナビゲートして表示することは可能ですか？
• 接続を調整して、アプリケーションの読み込み速度を確認してください。 ページの読み込みはどのくらい重いですか？

フェーズ2に進む前に、発生したバグを修正する必要があります。 ブラウザに依存しないバグを修正しないと、後で多くの誤ったブラウザ固有のバグが報告されるだけになります。

怠惰になりなさい。 ブラウザに依存しないバグを修正します。 次に、攻撃の第2フェーズに進むことができます。

2. RAID：最初にリスクの高いブラウザでテストする

バグを修正するときは、修正によってバグが追加されないように注意する必要があります。 CSSを調整してSafariのパディングを修正すると、Firefoxのパディングが壊れる可能性があります。 Chromeでよりスムーズに実行されるようにJavaScriptのそのビットを最適化すると、IEで完全に機能しなくなる可能性があります。 私たちが行うすべての変更にはリスクが伴います。

新しい変更によって、すでにテストしたどのブラウザーでもエクスペリエンスが損なわれていないことを本当に確信するには、戻って同じブラウザーで再度テストする必要があります。 したがって、作業の重複を最小限に抑えるには、テスト方法を賢くする必要があります。

バグ分布の統計分析

次の表を検討してください。ここで、十字アイコンはブラウザにバグがあることを意味します。

コンテンツをリスクの昇順でテストするとします：低リスクブラウザ、中リスクブラウザ、高リスクブラウザ。 これを視覚化するのに役立つ場合、これらのブラウザはそれぞれGoogle Chrome、IE 9、IE6にマッピングされる可能性があります。

最初に低リスクブラウザ（Chrome）をテストすると、バグ＃2を見つけて修正します。 中リスクブラウザに移行すると、バグ＃2はすでに修正されていますが、新しいバグ＃4が見つかりました。 バグを修正するためにコードを変更しますが、低リスクブラウザで何かが壊れていないことをどのように確認できますか？ 完全に確信できるわけではないので、戻ってそのブラウザでもう一度テストし、すべてが期待どおりに機能することを確認する必要があります。

次に、ハイリスクブラウザに移動して、バグ＃1、＃3、および＃5を見つけ、修正するには大幅な手直しが必要です。 これらが修正されたら、何をする必要がありますか？ 戻って、中リスクおよび低リスクのブラウザをもう一度テストします。 これは多くの努力の重複です。 3つのブラウザを合計6回テストする必要がありました。

次に、リスクの降順でコンテンツをテストした場合に何が起こったかを考えてみましょう。

すぐに、ハイリスクブラウザにバグ＃1、＃3、＃4、＃5が見つかります。 これらのバグを修正した後、中リスクのブラウザに直接移動して、バグ＃2を発見します。 以前と同様に、この修正により間接的に何かが壊れた可能性があるため、ハイリスクブラウザに戻って再テストする必要があります。 最後に、低リスクブラウザでテストし、新しいバグを発見しません。 この場合、合計4つの異なる機会に3つのブラウザーをテストしました。これにより、同じ数のバグを効果的に検出して修正し、同じ数のブラウザーの動作を検証するために必要な時間が大幅に短縮されます。 。

開発者には、最初に最も人気のあるブラウザーでテストし、テストの終わりに向けてあまり使用されていないブラウザーに向かって作業するように圧力がかかる可能性があります。 ただし、人気のあるブラウザはリスクの低いブラウザである可能性があります。

特定のリスクの高いブラウザをサポートする必要があることはわかっているので、最初はそのブラウザを邪魔にならないようにしてください。 バグが発生する可能性が低いブラウザのテストに労力を費やさないでください。バグが発生する可能性が高いブラウザに切り替えると、戻ってリスクの低いブラウザをもう一度確認するだけで済みます。

悪いブラウザのバグを修正すると、良いブラウザでのコードの回復力が高まります

多くの場合、これらの問題のあるブラウザで発生するバグは、コードの質が悪いために予期しない結果であることがわかります。 ボタンのように見えるようにdivのスタイルを不自然にしたり、任意の動作をトリガーする前にsetTimeoutでハッキングしたりした可能性があります。 これらの問題の両方に対して、より良い解決策が存在します。 不正なコードの症状であるバグを修正することにより、他のブラウザのバグを目​​にする前に修正している可能性があります。 その溶ける氷山効果が再びあります。

ブラウザが何かをサポートしていると想定するのではなく、機能のサポートを確認することで、IE8の厄介なバグを修正しますが、コードを他の過酷な環境に対してより堅牢にします。 Opera Miniにその画像フォールバックを提供することで、プログレッシブエンハンスメントの使用を奨励し、副産物として、マスタードをカットしたブラウザーのユーザーに対しても製品を改善しています。 たとえば、モバイルデバイスは、アプリケーションのアセットの半分だけがダウンロードされた状態で3G接続を失う可能性があります。ユーザーは、以前にはなかった有意義なエクスペリエンスを得ることができます。

ただし、注意が必要です。注意しないと、あいまいなブラウザのバグを修正すると、コードが悪化する可能性があります。 たとえば、特定のブラウザにコンテンツを条件付きで配信するために、ユーザーエージェント文字列をスニッフィングする誘惑に抵抗します。 これでバグは修正されるかもしれませんが、完全に持続不可能な方法です。 厄介なブラウザをサポートするために、優れたコードの整合性を妥協しないでください。

問題のあるブラウザの特定

では、リスクの高いブラウザとは何ですか？ 答えは少し厄介で、アプリケーションが使用するブラウザの機能によって異なります。 JavaScriptがindexOfを使用している場合、IE 8で機能しなくなる可能性があります。アプリがposition: fixedを使用している場合は、iOS7のSafariで確認することをお勧めします。

Can I Useは非常に貴重なリソースであり、開始するのに適した場所ですが、これも経験と開発者の直感から生まれた分野の1つです。 Webアプリを定期的に展開すると、どのブラウザーが問題を何度も報告するかがわかり、これに対応するためにテスト戦略を改善できます。

問題のあるブラウザで見つけたバグについて役立つのは、バグが頻繁に伝播することです。 IE9にバグがある場合は、IE8にもバグが存在する可能性があります。 iOS 7のSafariで何かがファンキーに見える場合は、iOS6ではさらに顕著に見える可能性があります。ここにパターンがありますか？ 古いブラウザは問題のあるブラウザになる傾向があります。 それはあなたが問題のあるブラウザのかなり良いリストを思い付くのを助けるはずです。

そうは言っても、使用統計を使用してこれらをバックアップしてください。 たとえば、IE 6は非常に問題のあるブラウザーですが、市場シェアの合計が低すぎるため、わざわざテストすることはありません。 IE6固有のバグの修正に費やした時間は、エクスペリエンスが向上する少数のユーザーにとっては努力する価値がありません。

襲撃段階でテストしたいのは、必ずしも古いブラウザとは限りません。 たとえば、画像フォールバックを使用した実験的な3D WebGLキャンバスプロジェクトがある場合、古いブラウザはフォールバックイメージを取得するだけなので、多くのバグが見つかる可能性はほとんどありません。 代わりに、手元のアプリケーションに基づいて問題のあるブラウザの選択を変更したいと思います。 この場合、IE9はキャンバスをサポートするIEの最初のバージョンであるため、テストに適したブラウザーである可能性があります。

アプリケーションでグラデーションや境界線半径などのCSS3機能を使用している場合は、最新のプロキシブラウザ（Opera Miniなど）もRAIDテストに適しています。 一般的なエラーは、サポートされていないグラデーションで白いテキストをレンダリングすると、白地に白のテキストが判読できなくなることです。

問題のあるブラウザを選択するときは、直感を使って、バグが隠れている可能性のある場所を先取りしてみてください。

問題のあるブラウザを多様化する

ブラウザとブラウザのバージョンは方程式の一部にすぎません。ハードウェアも重要な考慮事項です。 さまざまな画面サイズとさまざまなピクセル密度でアプリケーションをテストし、縦向きモードと横向きモードを切り替えてみてください。

労力のコストに割引が認識されているため、関連するブラウザをグループ化するのは魅力的です。 すでにVirtualBoxを開いてIE8をテストしている場合は、IE9、IE10、およびIE11でもテストするのに良い時期のように思われるかもしれません。 ただし、Webアプリのテストの初期段階にある場合は、この誘惑に対抗し、代わりに、全体でできるだけ多くのカバレッジを取得するために、互いに著しく異なる3つまたは4つのブラウザーとハードウェアの組み合わせを選択することをお勧めします。可能な限りバグスペース。

これらはプロジェクトごとに異なる可能性がありますが、現在問題のあるブラウザを選択します。

• Windows XPVM上のIE8;
• ミッドレンジのAndroidタブレット上のネイティブAndroidブラウザ2。
• iOS6を実行しているiPhone4のSafari。
• Opera mini（datapicsなどのJavaScriptなしで動作するはずのコンテンツでテストする価値があるだけです）。

怠惰になりなさい。 サポートされている最も問題のあるブラウザやデバイスにアプリをスローして、できるだけ多くのバグを見つけます。 これらのバグが修正されると、攻撃の最終段階に進むことができます。

3.クリアランス：健全性チェック

これで、サポートする必要のある最も過酷なブラウザーでアプリをテストし、バグの大部分を検出できるようになりました。 しかし、アプリケーションはまだ完全にバグがないわけではありません。 ChromeとFirefoxの最新バージョンでさえ同じコンテンツをレンダリングする方法がどれほど違うかに常に驚いています。 あなたはまだいくつかのテストを行う必要があります。

それはその古い80:20の法則です。 比喩的に言えば、20％のブラウザーをテストした後、80％のバグを修正しました。 次に、別の20％のブラウザーをテストして、80％のオーディエンスのエクスペリエンスを検証します。

ブラウザの優先順位付け

シンプルで明白なアプローチは、市場シェアの降順で各ブラウザに取り組むことにより、「従来の」クロスブラウザテストに戻すことです。 Chromeデスクトップがオーディエンスのブラウザシェアの中で最も高い割合を占めている場合、iOS 8のSafari、IE11の順でテストするのは理にかなっていますよね？

これはおおむね公平なシステムであり、リソースがすでに拡張されている場合は、このステップを過度に複雑にしたくありません。 ただし、実際のところ、すべてのブラウザが同じように作成されているわけではありません。 私のチームでは、ブラウザーの使用状況、アップグレードの容易さ、およびブラウザーがOSのデフォルトであるかどうかを考慮した決定木に従って、ブラウザーをグループ化します。

これまで、スプレッドシートにはブラウザ用の列と市場シェア用の列が必要です。 ここで、ブラウザがどの優先度に該当するかを指定する3番目の列が必要です。 正直なところ、この優先順位付け作業は3フェーズ攻撃を開始する前に行う必要がありましたが、この記事では、クリアランスフェーズまで優先順位は実際には必要ないため、ここで説明する方が理にかなっています。

これが私たちの決定木です：

P1ブラウザがオーディエンスの約70％をカバーするように、デシジョンツリーを設計しました。 P1ブラウザとP2ブラウザを合わせると、オーディエンスの約90％をカバーします。 最後に、P1、P2、およびP3ブラウザーは、ほぼ完全なオーディエンスカバレッジを提供します。 市場シェアの高い順に、すべてのP1ブラウザー、次にP2、次にP3でテストすることを目指しています。

この記事の前半のスプレッドシートでわかるように、P1ブラウザーはほんの一握りです。 オーディエンスの70％以上のエクスペリエンスを非常に迅速に検証できるという事実は、コードベースが変更された場合にそれらのブラウザーで再テストしないという言い訳がほとんどないことを意味します。 P2およびP3ブラウザーに移行するにつれて、オーディエンスのサイズが減少し続けるエクスペリエンスの検証にますます多くの労力を費やす必要があるため、優先度の低いブラウザーに対してより現実的なテストの理想を設定する必要があります。 ガイドラインとして：

• P1 。 アプリケーションにサインオフする前に、これらのブラウザーで健全性チェックを行う必要があります。 コードに小さな変更を加えた場合は、これらのブラウザで再度健全性チェックを行う必要があります。
• P2 。 アプリケーションにサインオフする前に、これらのブラウザーで健全性チェックを行う必要があります。 コードに大幅な変更を加えた場合は、これらのブラウザで再度健全性チェックを行う必要があります。
• P3 。 これらのブラウザを一度健全性チェックする必要がありますが、時間がある場合に限ります。

ハードウェアを多様化する必要があることを忘れないでください。 このリストに従って、さまざまな画面サイズやさまざまなハードウェア機能を備えたデバイスでテストできる場合は、そうしてください。

要約：三相攻撃

敵を知る努力（オーディエンス統計を簡素化し、ブラウザを優先順位にグループ化する）を行うと、次の3つのステップで攻撃できるようになります。

1. 偵察：ブラウザに依存しないバグを見つけるための、お気に入りのブラウザでの探索的テスト。
2. RAID ：さまざまなハードウェアでサポートされている最も問題のあるブラウザでテストし、バグの大部分を見つけます。
3. クリアランス：最も広く使用され、戦略的に重要なブラウザーでのアプリケーションのエクスペリエンスを検証し、アプリケーションが機能することを定量的に裏付けられた自信を持って言います。