テスト実行のための戦略

テストするブラウザーと端末の選択

すべてのブラウザーと端末の組み合わせをテストすることはできないので、サイトが最も重要なブラウザーで確実に動作することを確認すれば十分です。実際のアプリケーションでは、「重要な」というのは「対象となるユーザーが一般的に使用している」という意味であることが多いのです。

ブラウザーの対応や 端末の分類は、対応する量によって決めるとよいでしょう。例を挙げます。

1. A グレード: 一般的な／現代のブラウザー - 能力があることが知られている。徹底的にテストし、完全なサポートを提供する。
2. B グレード: 古い/性能の低いブラウザー - 機能がないことが分かっている。テストし、主要な情報とサービスに完全にアクセスできる、より基本的な使い勝手を提供する。
3. C グレード: 稀少なブラウザー、未知のブラウザー - テストはしませんが、動作可能であるとみなします。少なくとも防御的なコーディングによって提供された代替手段を用いて、作業するはずのサイト全体を配信してください。

以下の節では、この形式で対応表を作り上げていきます。

視聴者が最も使用するブラウザーを予測する

これには通常、ユーザーの属性に基づいた推測が必要です。例えば、ユーザーが北米と西ヨーロッパにいるとします。

軽くネット検索してみると、北米と西ヨーロッパではほとんどの人が Windows または Mac のデスクトップ／ラップトップを使用しており、主要なブラウザーは Chrome、Firefox、Safari、Edge であることが分かります。これらのブラウザーは定期的にアップデートを取得しているため、最新版をテストするのがよいでしょう。これらはすべて A グレードに入るはずです。

この層のほとんどの人は、iOS または Android の携帯電話も使用しているので、iOS の Safari の最新バージョン、Android の古い純正ブラウザーの最後の数バージョン、iOS と Android 用の Chrome と Firefox をテストするのがよいでしょう。また、レスポンシブデザインが確実に動作するように、携帯電話とタブレットの両方でテストすることが理想的です。

Opera Mini は複雑な JavaScript を実行する能力がとても低いので、これも B ランクにしましょう。

このように、どのブラウザーでテストを行うかは、ユーザーが使用すると予想されるブラウザーに基づいて決定します。 その結果、対応表は以下のようになります。

1. A グレード: Windows/Mac 用の Chrome と Firefox、Mac 用の Safari、Windows 用の Edge、iPhone/iPad 用の iOS Safari、スマートフォン/タブレット用の Android 内蔵ブラウザー（最新 2 バージョン）、スマートフォン/タブレット用の Chrome と Firefox（最新 2 バージョン）。
2. B グレード: Opera Mini
3. C グレード: なし

もし、対象となるユーザーがほとんど別の場所にいる場合は、一般的なブラウザーや OS が上記とは異なる形になる可能性があります。

ブラウザーの統計

指定された地域でどのブラウザーが人気があるのかを示すウェブサイトもあります。例えば、Statcounterは、北米のトレンドを知ることができます。

Analytics の使用

もっと正確なデータ源は、利用できるのであれば、Google Analytics のような分析アプリで、人々がサイトを閲覧するために使用しているブラウザーを正確に教えてくれます。もちろん、これは既に分析対象のサイトがあることに頼っているので、完全に新しいサイトに適したものではありません。

Open Web Analytics や Matomo のような、オープンソースでプライバシーに重点を置いた分析プラットフォームを使用することも検討できます。これらは、分析プラットフォームをセルフホスティングすることを前提としています。

Google analytics のセットアップ

1. まず、Google のアカウントが必要です。このアカウントを使用して、Google Analytics にログインします。
2. Google Analytics （ウェブ）のオプションを選び、サインアップ ボタンをクリックしてください。
3. サインアップページであなたのウェブサイト/アプリケーションの詳細を入力します。これはかなり直感的に設定することができます。正しく取得するために最も重要なフィールドは、ウェブサイトの URL です。これは、あなたのサイト/アプリのルート URL である必要があります。
4. 入力が完了したら、トラッキング ID を取得 ボタンを押し、表示されるサービスの利用規約に同意してください。
5. 次のページでは、いくつかのコードスニペットとその他の説明を提供します。基本的なウェブサイトの場合、必要なことは Website tracking のコードブロックをコピーして、あなたのサイトで Google Analytics を使用してトラッキングしたい異なるページすべてに貼り付けることです。スニペットは閉じられた </body> タグの下に所有するか、アプリケーションのコードと混同しないような適切な場所に配置してください。
6. 変更内容を開発用サーバー、またはあなたのコードが必要な場所にアップロードしてください。

これで完了です。これで、あなたのサイトは解析データの報告を始めることができるはずです。

アナリティクスデータの検討

これで、Analytics Web のホームページに戻り、あなたのサイトについて収集したデータを見始めることができるはずです（もちろん、いくつかのデータが実際に収集されるまで、少し時間を空ける必要があります）。

既定では、このようにレポートタブが表示されるはずです。

様々なカテゴリーでカスタマイズされたレポートなど、Google アナリティクスを使用して見ることができるデータは膨大で、そのすべてについて説明する時間はありません。 アナリティクスをはじめようでは、初心者に有益なレポート（など）についてのガイダンスを提供しています。

左側のメニューから ユーザー > テクノロジー > ブラウザーと OS を選択すると、ユーザーが使用するブラウザーや演算子を確認することができます。

その他の考慮事項

アクセシビリティをグレード A のテスト要件に含める必要があります。

また、状況固有のニーズも認識しておく必要があります。例えば、売上数値を管理職に配信するための社内イントラネットを作成していて、管理職全員に Windows Phone が指定されている場合、モバイルIEのサポートを優先させた方が良いでしょう。

最終的な対応表

ですから、最終的な対応表は次のようなものに仕上がります。

1. A グレード: Windows/Mac 版 Chrome と Firefox、Mac 版Safari、Edge（それぞれ最新 2 バージョン）、iPhone/iPad 版 iOS Safari、スマホ/タブレット版 Android 純正ブラウザー（最新 2 バージョン）、スマホタブレット版 Chrome と Android 版 Firefox（最新 2 バージョン）。アクセシビリティは一般的なテストに合格していること。
2. B グレード: Opera Mini。
3. C グレード: Opera などのニッチな現代のブラウザー。

これから何をテストしていくのか？

コードベースに新しい機能を追加してテストする必要がある場合、テストを開始する前に、合格しなければ受け入れられないテスト要件のリストを書き出す必要があります。これらの要件は、視覚的なものであっても機能的なものであってもかまいません。

以下の例のものがあるとします（ソースコードを参照してください。ライブ実行版もあります）。

この機能のテスト基準は、次のように書くことができます。

A および B グレード:

• ボタンは、ユーザーの主な制御機構（マウス、キーボード、タッチなど、それが何であれ）により起動できるようにする必要があります。
• ボタンを押すと、情報ボックスが現れたり消えたりすること。
• テキストは読み取り可能でなければなりません。
• 画面の内側からスクリーンリーダーを使用する視覚障碍を持つユーザーも、テキストにアクセスできること。

A グレード:

• 情報ボックスは、現れたり消えたりするときにスムーズにアニメーションする必要があります。
• グラデーションとテキストの影が現れて、ボックスの見栄えがよくなるようにします。

ボタンがキーボードだけで使用できないことにもお気づきでしょう。これも改善する必要があります。 JavaScript でトグルのキーボード制御を実装するか、他にも全く別のメソッドを使用することができるかもしれません。

これらのテスト基準は、以下の理由で有益なものです。

• テストを実施する際に、以下に従うべき手順の集合を与えます。
• これらは、ユーザーグループがテストを行う際に従うべき指示の集合に簡単に変えることができます（例えば、「マウスを使ってボタンを有効化してみて、次にキーボードを使って...」など） - 下記の ユーザーテスト を参照ください。
• これらはまた、自動化されたテストを書くための基礎となります。何をテストしたいのか、そして成功条件は何なのかを正確に知っていれば、そのようなテストを書くのはより簡単です（このシリーズの後の Selenium を見てください）。

テストラボを用意する

ブラウザーテストを実施するための一つのオプションは、自分自身でテストを行うことです。そのためには、実際の物理的な端末とエミュレートされた環境（エミュレータまたは仮想マシンのいずれかを使用）を組み合わせて使用することになると思います。

物理的な端末

一般的には、テストしたいブラウザーを実行する実機があった方がよいでしょう。この方が、動作や全体的な使い勝手の面で最も高い精度が提供されます。低レベルの機器ラボとしては、おそらく以下のようなものが必要でしょう。

• テストが必要なブラウザーがインストールされた Mac - Firefox、Chrome、Opera、Safari を含めることができます。
• テストに必要なブラウザーがインストールされた Windows PC - Edge（または IE）、Chrome、Firefox、Opera を含めることができます。
• テストに必要なブラウザーがインストールされている高スペックの Android 携帯電話およびタブレット - Android 用の Chrome、Firefox、Opera Mini、Android 純正のブラウザーが含まれます。
• テストに必要なブラウザーがインストールされた、よりハイスペックな iOS 携帯電話およびタブレット - これには、iOS Safari および iOS 用の Chrome、Firefox、Opera Mini を含めることができます。

以下のようなものも、入手できれば良いオプションです。

• Linux 版のブラウザーに固有のバグをテストする必要がある場合に備えて、利用できる Linux PC。Linux ユーザーは、一般的に Firefox、Opera、Chrome を使用します。利用できるマシンが 1 台しかない場合は、別個のパーティションに Linux と Windows をインストールして、デュアルブート環境を作成することを考えてみることができるでしょう。
• 低スペックのモバイル端末をいくつか用意すると、性能の低いプロセッサーでトランジションなどの機能をテストすることができます。

あなたのメインの著作物は、アクセシビリティ監査ツール、スクリーンリーダー、エミュレーター/仮想マシンなど、特定の目的のために他のツールをインストールする場所にもなりえます。

大企業の中には、非常に多くの異なる形の端末を選択できる端末ラボを保有し、開発者がとても特殊なブラウザーと端末の組み合わせでバグを突き止めることを可能にしているところもあります。小規模な企業や個人は、一般的にそのような高度なラボを持つことができないので、小規模なラボ、エミュレータ、仮想マシン、商用テストアプリでやりくりする傾向があります。

下記では、他にも様々なオプションがあることを説明します。

エミュレーター

エミュレーターとは、基本的にコンピューター内で実行され、ある端末や特定の端末の状態をエミュレートするプログラムのことです。テストするハードウェアとソフトウェアの具体的な組み合わせを保有するよりも、より便利にテストの一部を実行できるようになります。

エミュレーターは、機器の状態をテストするような単純なものであるかもしれません。例えば、レスポンシブデザイン用の幅/高さのメディアクエリーをすばやくテストしたい場合、Firefox のレスポンシブデザインモードを使用することができます。Safari にも同様のモードがあり、Safari > Preferences で、Show Develop menu を調べ、Develop > Enter Responsive Design Mode を選べば、このモードを有効にすることができます。Chrome にも同様のものがあります。デバイスモード（デバイスモードでモバイル端末をシミュレートするを参照）。

しかし、多くの場合、何らかのエミュレーターを保有しなければならないでしょう。最も一般的にテストしたい端末/ブラウザーは以下の通りです。

• Android アプリを開発するための公式の Android Studio IDE は、Google Chrome や古い純正 Android ブラウザーでウェブサイトをテストするには少し重いですが、しっかりとしたエミュレーターが実行されています。
• Apple は、XCode 開発環境の上で動作し、iPad/iPhone/Apple Watch/Apple TV をエミュレートする Simulator というアプリを提供されています。これには iOS ネイティブのブラウザー Safari が搭載されています。これは残念ながら Mac 上でしか動作しません。

他にもモバイル端末環境用のシミュレーターなどもよく見つかります。

• Opera Mini をテストしたい場合は、自分自身でエミュレートすることができます。

仮想マシン

仮想マシンは、デスクトップコンピューター上で動作するアプリケーションで、自分自身で仮想ハードディスク（多くはホストマシンのハードディスク上に存在する単一の大きなファイルで表される）に区分されたオペレーティングシステム全体のエミュレーションを実行することができます。 Parallels、VMWare、Virtual Box などの有名な仮想マシンアプリが利用でき、個人的には後者が無料なので気に入っています。

Virtual Box を使用するには、次のことを行う必要があります。

1. エミュレートしたい OS のインストーラーディスクや画像（ISO ファイルなど）を取得します。Virtual Box ではこれらを提供することができません。Windows OS など、ほとんどが商用製品であり、自由に配布することができません。
2. 自分のオペレーティングシステムの適切なインストーラーをダウンロードし、インストールしてください。
3. アプリを開いてください。次のような画面が表示されます。
4. 新しい仮想マシンを作成するには、左上にある New ボタンを押します。
5. 指示に従い、以下のダイアログボックスを適宜埋めてください。
   1. 新しい仮想マシンに名前を付けます
   2. どの OS とバージョンをインストールするかを選びます。
   3. RAM の割り当て量を設定してください（2048MB、または 2GB 程度を推奨）。
   4. 仮想ハードディスクを作成します（Create a virtual hard disk now、VDI (virtual disk image)、Dynamically allocated を含む 3 つのダイアログボックスで既定のオプションを選びます）。
   5. 仮想ハードディスクのファイルの保存場所とサイズを選びます（名前と保存場所は適当なものを選び、サイズは 50GB 程度、または指定しても差し支えない範囲で指定します）。

これで、Virtual Box UI のメインウィンドウの左側のメニューに新しい仮想ボックスが表示されるはずです。この点で、ダブルクリックして開くことができます。仮想マシンの起動が始まりますが、まだオペレーティングシステム (OS) はインストールされていません。この時点でダイアログボックスをインストーラー画像/ディスクに向ける必要があり、物理マシンと同じように OS をインストールする手順が実行されます。

処理が完全に終了すると、ホストコンピューター上のウィンドウ内で OS を実行している仮想マシンがあるはずです。

この仮想 OS のインストールは、実際のインストールと同じように扱う必要があります。例えば、テストするブラウザーと同様に、ウイルスから保護するためにアンチウイルスプログラムをインストールします。

複数の仮想マシンを持つことは、特に Windows IE/Edge のテストに非常に有効です。Windows では、複数のバージョンの既定ブラウザーを同時にインストールすることができないため、必要に応じて異なるテストを行うするために仮想マシンのライブラリーを構築するとよいでしょう。

• Windows 10 と Edge 14
• Windows 10 と Edge 13

自動化と商用アプリ

前の章で述べたように、ある種の自動化システムを使用することで、ブラウザーテストの苦労を軽減することができます。自分自身でテスト自動化システム（Seleniumはよく選ばれるアプリです）を設定することができます。多少のセットアップが必要ですが、うまく作業を進めるととてもやりがいのあるものになるでしょう。

Sauce Labs や Browser Stack のような商用ツールもあり、テストにお金をかけたい場合は、設定を気にせずにこのようなことを行うことも可能です。

もう一つの選択肢は、Endtest のようなノーコードのテスト自動化ツールを使用することです。

このモジュールの後のほうで、そのようなツールを使用する方法を見ていきます。

ユーザーテスト

次に進む前に、ユーザーテストについて少し話して、この記事を締めくくります。これは、新しい機能をテストする意欲的なユーザーグループがある場合に有効なオプションです。ユーザーグループは、テストに費やすお金があるかどうかにもよりますが、友人のグループ、同僚のグループ、あるいは無給または有給のボランティアのグループでもかまいません。

一般的には、ある種の開発サーバーにある新しい機能を含むページやビューをユーザーに見てもらうことになるので、最終的なサイトや変更が完了するまで本稼働させることはありません。ユーザーにいくつかの手順を踏んでもらい、取得した結果を報告してもらう必要があります。あなたがテストしようとしたことに関連する、より信頼性の高い結果を取得するために、一連の手順（スクリプトと呼ばれることもあります）を提供することは有益です。このことは、上記の これから何をテストしていくのか？の節で述べました。そこで詳述したテスト基準を、従うべき手順に変えるのは簡単です。例えば、以下のようにすれば、目の見えるユーザーに対して作業することができます。

• デスクトップコンピューターでマウスを使用してクエスチョンマークボタンを数回クリックする。ブラウザーウィンドウを更新する。
• デスクトップコンピューターで、キーボードを使用してクエスチョンマークボタンをいくつか選択し、アクティブにする。
• タッチ画面の機器へ、クエスチョンマークボタンをいくつかタップする。
• ボタンをトグルすると、情報ボックスが現れたり消えたりするはずである。上記の 3 つのケースで、それぞれこのように表示されるか？
• テキストは読み取り可能か？
• 情報ボックスが現れたり消えたりするときに、スムーズにアニメーションするか？

テストを実行する際にも、よいアイディアになります。

• 可能であれば、ブラウザーの拡張機能などを無効にして、別のブラウザープロファイルを設定し、そのプロファイルでテストを実行しましょう（例えば、プロファイルマネージャーを使用して、Firefox のプロファイルを作成または削除する や複数のプロフィールで Chrome を使用するなどを参照してください）。
• テストを実行する際には、ブラウザーのプライベートモード機能が利用できる場合はそれを使用し（例：Firefox の Private Browsing 、Chrome の Incognito Mode ）、クッキーや一時ファイルといったものは保存しないようにします。

これらの手順は、テストするブラウザーが可能な限り「純粋」であること、つまり、テスト結果に影響を与えるようなものがインストールされていないことを確認するためのものです。

まとめ

この記事を読んで、ターゲット顧客/ブラウザーの表を特定して、その表に載っているブラウザー横断テストを効率的に実行することが良くわかったでしょう。

次には HTML と CSS から始めて、テストで見つけにくいコードの問題に注目していきましょう。

• 前のページ
• Overview: テスト
• 次のページ