フロントエンドのテスト計画

Smashing Magazineの『How To Create Your Own Front-End Website Testing Plan』という記事を読みました。Webサイトのフロントエンドをテストするための計画を立てよう、といった趣旨の内容ですが、そもそもテスト計画を作成することのメリットとして、著者は

• プロジェクトのスコープの明確化
• 顧客との衝突の回避
• プロジェクトを通じた信用の獲得

の3点を挙げています。技術、プロセス、サービスの3つの品質を重視する当社においても、上記の3点は欠かせないと思いますし、またその目的においては、テストを通じ一定の品質基準を満たしたことを確認するプロセスが重要と考えます。

ちなみに、受諾でWebサイトを構築・運用することの多い当社の場合、お客様からいただく仕様なり要件のなかに満たすべき品質基準が明示されている場合もありますし、逆に当社から基準をご提案することもあります。

また記事の「限度を知る（Know Your Limits）」というセクションにおいては、プロジェクトの

• 予算
• スケジュール
• スコープ

を認識しておくことの必要性が語られていました。確かに、ブラウザーを使ったレイアウトの目視確認ひとつ取っても、それを無制限に（ありとあらゆる種類、バージョンのブラウザーを使って）行うのは金銭的にも時間的にも現実的ではありません。実際のユーザーがどのようなブラウザーを使っているか、事実に基づいた絞り込みが必要でしょう。ことブラウザーとデバイスのサポートについては著者は3つのレベル、すなわち

• レベル1：完全なサポートを提供するブラウザー/デバイス
• レベル2：部分的なサポートを提供するブラウザー/デバイス
• レベル3：サポートを提供しない、またはテストを必要としないブラウザー/デバイス

という分類を提案しています。これらをどこまで明確に定義するかはケースバイケースだと思いますし、特にレベル1とレベル2の線引きが難しいケースもあるように思いますが、どのデバイスのどのブラウザーで何をテストするか定義し、文書化のうえ共有しておくことは重要だと思います。当社の場合、粒度に差はあれどご発注いただく段階からそういった部分にまで「ある程度」踏み込んで定義をしつつ、フロントエンド周りの詳細な仕様についても、プロジェクトの初期段階で文書化するようにしています。

記事では、ほかにもテストを計画するうえで押さえておくべきポイントの数々が記されているほか、後段ではDad Infoという実際のサイト/プロジェクトでのテストが詳しく紹介されていました。個人的に興味深かったのは、パフォーマンスのレポートに関するくだりです。テストにはGoogleのPageSpeed Insightsを使用し、獲得すべきスコアを100点中最低85点に定め、達成の証跡としてスコア表示のスクリーンショットを納めたとのこと。

PageSpeed Insightsは点数による表示がわかりやすいのですが、公開前の（非公開の）コンテンツについてはポリシー的にテストしにくい面があります。当社では、パフォーマンスのより効率的な社内テスト環境を整備すべく、WebPagetestのパーソナルインスタンスの利用に着手していますが、今後WebPagetestの詳細についても、本Blogでご紹介していければと思います。