• 信頼性：B+（共通のプラットフォームはトラブルシューティングが容易）
• 外観：C-（非常に地味）
• パフォーマンス：B（パフォーマンスに対する期待は低く、アプリケーションは単純）
• 総合評価：中

　将来のWeb2.0エクスペリエンスは素晴らしい可能性を秘めているが、われわれは現在、そこに至るまでの最初の厳しい難関を通過しているところだ。ユーザーは多種多様なブラウザ（IE、Safari、Firefox、Opera、BlackBerryなど）を利用しており、そのベースとなるOSも実にさまざまだ（Windows、Mac OS、Linux、各種モバイルデバイスのOS）。

　ブラウザ内ではかつてなく多くのロジックが動作している。一方、かつてなく多くのコンテンツがホスト企業の管轄外にある――例えば、広告、分析サービス、コンテンツ配信ネットワークなどだ。これは複合的な世界なのだが、これまで企業は一般に、自社で所有していないものをテストする方法を知らなかった。このため、今日のWebエクスペリエンスの成績表は以下のようになる。

今日のWebエクスペリエンス

• 信頼性：F（個別ブラウザ／OSに対するテストが行われていなかったり、あるべきはずのWebサービスが存在しなかったりすることがある）
• 外観：A-（とてもおしゃれだ）
• パフォーマンス：C（期待が高くなる一方で、壊れる可能性がある部品が増えた）
• 総合評価：下

　では、信頼性とパフォーマンスの成績を上げ、コンポーネントが多様化する中で一貫性のあるユーザーエクスペリエンスを提供し、Web2.0の可能性を実現するには、何が必要なのだろうか。

　われわれは今、まったく新しい開発／配信パラダイムを相手にしているため、ソフトウェア開発／テスト戦略もそれに合わせて刷新しなければならない。以下に幾つかのアドバイスを示す。

Webエクスペリエンスの品質を製品に作り込む

　これまでのように、運用中に手直しをすればいいというわけにはいかない（PerlでWebアプリケーションを開発した経験のある人なら、これがどういう意味か分かるだろう）。アプリケーションを発案した最初の時点から、エクスペリエンス全体を考慮に入れておかねばならない。リリース基準には、開発中および開発後に頻繁に測定することができる具体的なパフォーマンスと信頼性の指標を含めること。

顧客のエクスペリエンスに影響する要素を把握（管理）する

　多くの企業はサードパーティーのWebサービスのコンセプトを理解しているが、自社が提供するコンテンツしかテストしていないのが実情だ。ユーザーのエクスペリエンスに影響するすべての要素（サードパーティのデータやサービスも含む）を把握すること。忘れてはならないのは、特定のサードパーティーのWebサービスが一部の顧客にとってきちんと機能するからといって、それがすべての顧客に当てはまるとは限らないということだ。

顧客のプロファイルや利用パターンを把握する

　彼らはどんなタイプのブラウザを利用しているのか、どんなマシンを使っているのか、どんな方法でインターネットに接続しているのか、どの国・地域から接続しているのか、利用パターンはどうか（日中、夜間、週末に利用する、アプリケーションを通じた特定の経路で接続するなど）――これらの要素はすべて顧客のエクスペリエンスに影響する。こういった点を考慮した上で、自社のアプリケーションが顧客にとってきちんと機能するようにすること。また、サードパーティーがある地域できちんとサービスを提供しているからといって、それがすべての地域に当てはまるとは限らない。サードパーティーもあなたの会社と同様に一貫したサービスを提供しているはずだ、という前提に立ってはいけない。

ブラウザ互換性検証ラボを設立する

　このラボでは、ユーザーが使用する可能性があるブラウザとOSのすべての可能な組み合わせをテストできるようにする。これには、携帯電話用のブラウザ（筆者は早速、iPhoneのSafariを使おうと思っている）やBlackBerryも含めること。オープンソースのテストツール「Selenium」は、任意のブラウザとOSの組み合わせのテストを自動化するのに有効な手段である。「Selenium Remote Control」を利用すれば、任意の言語でコードをテストし、各種のブラウザとOSの組み合わせをリモートで動作させることが可能だ。Seleniumと同様の機能を提供するツールとしては「Watir」がある。両ツールともOpenQA.org上で提供されている。また「Firebug」（オープンソースのFirefoxの拡張機能）は多彩な機能を備え、Web2.0開発者や品質保証技術者にとってはスイス製アーミーナイフのように重宝する。

実際に行ったテストのスクリーンショットと動画を取り込む

　これにより、問題の真の原因を把握し、その影響と対策を検討することができる。この機能を提供しているのは、まだごく一部の商用製品だけだが、自動テストが失敗したときにその理由を特定するのに大きな効果がある。

自動テストおよび実運用時のブラウザの動作を記録したログを取得する

　ブラウザには多数のアプリケーションロジックが含まれており、これらを無視することはできない。Firebugは、Firefox用にこの機能をサポートしており、Safariではこの機能が組み込まれている。IEやそのほかのブラウザ用には「Firebug Lite」を検討するといいだろう。最も苦労するのは、ブラウザのログを永続的ストレージに変換することだが、その見返りは十分に苦労に値するものである。

パフォーマンスと認識の関係を理解する

　ユーザーのブラウザで、すべての部分が表示されてはいるが、画面に入りきらないWebページの部分が読み込まれていないという場合でも、ユーザー側の認識という点では、そのページは完全なのである。つまり、テスターはHTTPの応答時間のデータだけに目を向けるのではなく（それだけなら簡単なのだが）、個々のJavaScript機能、Ajaxコール、各種オブジェクト（画像、CSSなど）、HTML固有のイベントなどに関する情報も把握することにより、認識上のパフォーマンスを正確に把握する必要がある。ユーザーにとって重要なのは、認識されたパフォーマンスなのである。

継続的インテグレーション（CI）プロセスにブラウザを含める

　CIのインプリメンテーションの多くは通常、サーバコードのテストを行うだけで、ブラウザ内で増えている処理を考慮に入れていない。ブラウザをCIプロセスに含めることで、時間とリソースは少し余計にかかるが、エンドユーザーの実際のエクスペリエンス（最近ではこれが非常に重視されるようになってきた）をテストすることが可能になる。

「オンデマンド」テストを検討する

　複数のブラウザ／OSの実際の組み合わせをテストし、何Gバイトものパフォーマンスデータを取得しようとすれば、大抵の企業が投資をためらうようなテストインフラが必要になる。オンデマンドテスト（SaaS）を利用すれば、社外のテストリソース、アーキテクチャ、セットアップ投資を利用することができる。つまり、必要に応じてブラウザラボをレンタルするだけでいいのだ。

Webアプリケーションの進化に合わせてテストのリファクタリングを行う

　AjaxがWebアプリケーションの開発方法を変えた結果、Webアプリケーションの自動テストはコードと密接に結び付くようになった。結び付きが密接になれば、データの一貫性とテストツールにいっそう注意を払うことが求められる。以前は、Webアプリケーション上で自動テストを定義するのは簡単だった――ユースケースのあらゆるステップ（例えば、ジョーというユーザーがwww.xyz.comを訪れ、ログインリンクをクリックするなど）が新しいページビューに対応していた。しかしAjaxを使用すると事情がもっと複雑になるため、リファクタリングが不可欠になるのだ。

　上記の戦略を採用すれば、Web2.0の複雑化に十分に対応できる高度で徹底したQAテストを迅速に実施することができる。信頼性が高く、優れたパフォーマンスを提供するクリーンで優れたコードは、Web2.0の大きな可能性を現実のものとし、インターネットの価値を高める上で重要な役割を果たすだろう。

本稿筆者のパトリック・ライトボディ氏は、オンデマンド型Webアプリケーションエクスペリエンス管理サービス提供企業のGomezにおいて、QAソリューションのプロダクトマネジャーおよびオープンソースのチーフエバンジェリストを務める。