Webサイトテストチェックリスト：ユーザビリティテスト、ユーザー受け入れテスト、およびABテストの説明

概要： Webサイトのユーザビリティテスト、ユーザー受け入れテスト（UAT）、およびABテストを組み合わせると、大変な作業のように聞こえるかもしれません。 しかし、機能や経路を立ち上げる前にWebサイトのテストチェックリストを確認しておくと、長期的には時間とお金を節約できます。

あなたの会社が製品のナビゲーション体験を改善する必要があるとしましょう。 上司は、ユーザーがナビゲートできるようにするための新しい重要な方法を開発する予定であり、プロジェクトを推進していると述べています。 多くのマーケターにとって、そのプロセスは次のようになります。

技術的に言えば、サイトで起動できる新機能のすべてのコンポーネントが含まれています。 ただし、これらをコアステップとして使用すると、プロジェクトの成功または失敗が偶然に残ります。 開発の一時的な中断が発生しないと仮定しても、構築している新しいナビゲーションパスは、同じように壊れているか、現在のナビゲーションパスよりもさらに悪い可能性があります。

それをすべて回避するには、テストが必要です。 しかし、どれですか？ そして、いつそれらすべてを適用しますか？

これは、Webサイトのテストチェックリストが役立つ場合があります。

飛び込みましょう。

1.ユーザビリティテストの適用

ユーザビリティテストは、本質的に、何かを使おうとしている人々へのインタビューであり、Webサイトのテストチェックリストに含める必要があります。 君は …

• …競合他社のサイトに対してこれを行うことができます（そしてすべきです！）。
• …新しい機能を構築するときに、これらを設計コンセプトに適用する必要があります。
• …プロトタイプを作成するときにテストし、Webサイトで実際の機能を起動するときに再度テストする必要があります。

競合他社のサイトでのユーザビリティテスト

構築したいサイトと同様の機能を使用する競合サイトがある場合は、数人の人にタスクを実行するように依頼する必要があります（人の数に夢中になりすぎないでください、4〜12人がトリックを実行する必要があります）。それ、そして彼らにプロセスを通して話してもらいます。 それは本質的にそれです。

特定のものが機能する理由と、他のものが期待を裏切る理由についてのコメントを得ることができます。 そのすべてがあなたのデザインコンセプトに反映されるはずです。 そこから、サイトで起動するときに、設計、プロトタイプ、および実際の機能をテストする必要があります。

内部機能のユーザビリティテスト

実際にはこれが複雑になることがあるとしても、原理は単純です。

サイトのデザインコンセプトを完成させたら、12人と話す必要があります。 しかし、一度にすべてではありません。

• まず、4人に、設計コンセプトのみを使用してタスクを実行してもらいます。 4人と話をすると、デザインの最大の問題に気付くでしょう。
• それをデザインに適用してから、別の4人と話します。 彼らは2番目のバージョンで最大の問題をキャッチし、それをコンセプトの3番目のバージョンに適用できます。
• 最終セットが4人の第3バージョンまでに、小さな問題だけが残っているはずです…そして次の段階に進むことができます。

そして、それは基本的にユーザビリティテストです。 プロトタイプができたらもう一度実行し、機能が起動したときにもう一度実行します。

思ったほど時間はかからず、ほとんどの企業にお金をかけるのではなく、実際に節約できます。 これは、設計段階からプロトタイプ段階、またはプロトタイプ段階から打ち上げ段階に移行する場合、物事を変更するのに費用と時間がかかるためです。

このプロセスにより、構築しているものを実際に使用してタスクを効率的に実行できるようになり、プロジェクトの後半でコストのかかる機能の改訂を行う必要がなくなります。 最大のユーザーエクスペリエンスの問題を早期に発見します。

2.ユーザー受け入れテスト（UAT）の適用

もちろん、ユーザーエクスペリエンスについて人々と話をしたからといって、実際の機能にバグがないというわけではありません。 光沢のある新製品のナビゲーションエクスペリエンスは、設計フェーズとプロトタイプフェーズのユーザビリティテストフェーズでは優れている可能性がありますが、サイトに適用したときにショッピングカートが機能しなくなると、ビジネスに悪影響を及ぼします。

そこで、Webサイトのユーザー受け入れテスト（UAT）が登場します。

プロトタイプがユーザビリティテストに合格した後、機能がサイトでリリースされる前に、社内のさまざまな内部リソースがチェックする項目のチェックリストが必要です。 このチェックリストは、Webサイトのテストチェックリストの一部を損なうはずです。

これは、実際に起動する前に行う「実世界」のテストに最も近いものです。 UATは以下のシナリオ以上のものをカバーしますが、少なくとも…

• …計画された機能は仕様に従って実行され、ユーザーが目的のタスクを実行できるようにします。
• …起動するものはかなりうまく機能し、合意されたページ読み込み時間のしきい値の範囲内にあります。
• …計画している微調整は、サイトの他の領域と互換性があり、Webサイトの他の部分で問題を引き起こすことはありません。

ドライバーも必要です。この機能が機能し、サイトの他の機能に干渉しないことをサインオフする必要があることを人々に思い出させる人がいます。

UATを考慮すると、プロセス全体は次のようになります。

一部の機能では、その段階で停止できます。 ただし、構築しているものがトラフィックとコンバージョンの大きな牽引力を獲得するように設計されている場合は、もう1つのテストを追加する必要があります。

3.ABテスト/分割テストの適用

十分な数のユーザーと話し合い、タスクを実行できることを確認したら、テストを実行して機能が何も中断せずに計画どおりに機能することを確認した後、まだいくつかの作業があります。最大の影響を与えるようにページを最適化することです。

ABテストまたは分割テストはプロセスの最後に行われるため、機能の起動は次のようになります。

ABテストまたは分割テストは、別のブログ投稿で話し合ったものです。 利点、テスト期間、避けるべきこと、およびその他のニュアンスに関する詳細な入門書が必要な場合は、ここで分割テストの基本について読むことができます。

ただし、一般的な考え方としては、前のテストの後で起動したばかりのページと、起動したものとは少し異なるチャレンジャーページの2つのバージョンが表示されます。少し調整した可能性があります。召喚状、または製品領域のタイトルが書き直されています。

分割テストでは、トラフィックをこれら2つのページに分割します。やがて、選択した基準に基づいて、どちらのページの方が優れているかを示す統計が表示されます。

Webサイトテストチェックリストの重要性

ユーザビリティテスト、ユーザー受け入れテスト、およびABテストを組み合わせる場合、一般的に使用できるのは、チャンスをほとんど残さないテストフレームワークです。

より多くの作業のように聞こえますが、実際には、ほとんどの作業は、機能しないページのやり直しや、他のものを壊す機能から発生します。 通常、テストを実装しても時間が失われることはありません。 大規模なプロジェクトのほとんどでは、途中でターゲットを変更したり、起動直前に「パニック変更」を行ったりすることがないため、実際に時間を節約できます。

3つのテストは、最小限のやり直しに取り組むことを意味します。 それらは、ユーザーがタスクを実行できるようにします。 そしておそらく最も重要なことは、訪問者を変換する可能性を最大化することです。

この投稿は元々2015年8月に公開され、包括的に更新されています。