この記事は、ウェブアプリとモバイルアプリをとことんシンプルにモニタリングするサービス「New Relic」に提供してもらった。
ユーザーが、ウェブアプリ、そして、デスクトップアプリから、出来るだけ多くの機能、信頼性、そして、柔軟性を望む時代が到来している。データは、徐々に、しかし、確実にクラウド化へ向かい、企業は、– 会計ソフトであれ、CRMであれ、あるいは、在庫管理ソフトであれ — 容易に実装し、展開することが可能なソフトウェアを求めてウェブを探し回っている。このトレンドにより、開発者達はプレッシャーを感じている。ユーザーが仕事と遊びを心から依存することが出来る、優れたウェブアプリを求めているためだ。
そのため、ローンチする前にウェブアプリをテストする必要がある。頑丈で、効率的に動作し、ユーザーを笑顔にする良質なアプリを提示すると、企業と顧客との間の信頼関係は自然に構築されていく。すると、顧客は、今まで以上に頻繁に利用し、仲間に紹介するようになる。おまけに、カスタマーサポートの問題は大幅に減り、コストと人材を節約することが出来るようになる。
それでは、ウェブアプリをテストして、初日に向けて、順調に進んでいる点を確認する方法を検証していこう。。
目次
写真の編集を助けるアプリであれ、請求書の送信を簡素化するアプリであれ、友達との連絡を手助けするアプリであれ、あるいは、ソーシャルメディアでの影響力を計測するアプリであれ、アプリをテストする際は、これから紹介する4つの主な領域に注意する必要がある:
ユーザーは、正確に、早く、そして、一貫してアプリが動くことを期待する。つまり、ユーザーが何らかの成果を出す上で貢献する機能を全てテストする必要がある。徹底したテストを必要とする一般的な機能の要素を挙げていく:
フォーム: フィードバック、新しいto-doリストの作成、そして、ニュースレターの購読 — 投稿機能が正しく動く点、適切にデータベースに接続する点、そして、必要に応じて、全てのフィールドが入力を受け入れる点を確認する。
ファイルの操作と計算: 画像や文書のアップロード、編集、そして、計算機能と修正出力 — ユーザーが、アプリを試すシナリオを考え、出来るだけ多くのシナリオをテストし、可能な限り対応する。また、アプリが、効率良く計算を行い、結果を表示しているかどうかを確認し、スムーズなユーザー体験を可能にする。
検索: コンテンツ、ファイル、あるいは、文書の検索を認めているなら、検索エンジンが、当該の情報を完全にインデックスしている点、定期的に更新している点、そして、素早く調べ、適切な結果を提供している点を確認する。
メディア: オーディオや動画の再生、アニメーションやインタラクティブエージェンシーメディア（ゲームやグラフィックツール）がスムーズ且つシームレスに実施されるかどうかをテストする。このような要素は、期待通りに動き、ローディング中、または、再生中にその他の機能を妨げることがあってはならない。
スクリプトとライブラリ: スクリプト（例えば、画像表示やAjaxのページの読み込み）が、オーディエンスがアプリにアクセスするために利用する可能性のある各種のブラウザと互換性がある点を確かめ、ローディングにかかる時間を計測して、パフォーマンスを最適化する。スクリプトが特定のブラウザにしか対応していない場合、その他のブラウザでの処理の低下を最低限にとどめ、すべてのユーザーに対して、出来る限り最高のユーザー体験を提供する。
その他に機能が完璧に動く点を確認したい要素として、通知システム、ユーザーのプロフィール、そして、管理用のダッシュボードが挙げられる。
ウェブアプリが、十分に油を差した機械のように動くだけでなく、良質なフロントエンドの体験をすべてのユーザーに提供しなければならない。そのためには、ユーザーが遭遇する視覚およびテキストの要素を考慮し、正しく、そして、効率良く表示されることを確認する必要がある。それでは、具体的に何に注意すればいいのだろうか？
ナビゲーション: ホームページへ行き来するリンクは、すべて目立っている点、そして、適切な目的地のページに向かっている点を確認する。
<strongアクセシビリティ: 出来るだけ、視覚や運動機能の障害を持つユーザーでも容易に利用することが出来るように工夫する。W3Cのウェブコンテンツのアクセシビリティ入門は、アプリを普遍的にユーザーフレンドリーにするための手法を特定し、アプローチする上で役に立つ。
クロスブラウザテスト: ユーザーは、複数のブラウザやOSを組み合わせて、サイトにアクセスしている可能性が高い。したがって、アプリは、すべての組み合わせで同じように表示されるとは限らない。出来るだけ多くの組み合わせを試して、出来るだけ大勢のユーザーに対して、意図したとおりにアプリが動くことを確認する。
エラーメッセージと警告: アプリは、自分のせいではなくても、いつか故障する。ユーザーが404ページやアップロードの失敗等の問題に遭遇した際に、分かりやすく、有益な情報を提供している点を確認する。
ヘルプと文書: 全てのユーザーが同じように快適にアプリを使いこなすわけではない。ユーザーによっては、使い始めたばかりの頃は手助けを必要とする場合もあれば、製品を熟知していても、問題に遭遇する場合もある。アプリを一通り試し、文書やサポートのチャンネルを容易に見つけられる点、そして、全てのモジュールやページから簡単にアクセスすることが出来る点をチェックする。
レイアウト: アプリをテストして、出来るだけ多くのブラウザおよびビューポートのサイズで、正しく表示されることを確認する。
また、すべてのアニメーション、インタラクション（ドラッグ & ドロップ機能やモーダルウィンドウ等）、フォントやグリフ（特にウェブフォント）、そして、勿論、フロントエンドのパフォーマンス（ページの表示の早さ、画像やスクリプトの表示の早さ）もついでに検査してもらいたい。
大半のウェブアプリは、個人情報、請求情報、そして、作業/個人のファイルを含む、データをユーザーから取得し、保存している — ユーザーは、信頼して、データを預けている。そのため、次の取り組みが求められる:
いつ何時、そして、あらゆる場所から、ハッカーのターゲットにされるか分からないため、ハッカーの手法、そして、ハッカーが探す脆弱性を熟知しておくと良い。ウェブサイトとアプリに対して行われる攻撃の中で、特に目立つものを挙げていく:
クロスサイトスクリプティング: ウェブサイトが騙されて、悪意のあるコードを受け入れてしまい、ビジターに拡散する。
SQL インジェクション: ユーザーの入力の脆弱性を悪用して、アプリのデータベース上でSQLのコマンドを実行し、ユーザーデータの破壊や盗難を導く。SQL インジェクションは、通常、SQLのコマンドやOSのコマンドで用いられる特別な要素に対する不適切な中立化が原因で発生する。
DDoS（Distributed Denial of Service）攻撃: ターゲットのサーバーに対して、大量のリクエストを出すことで、クロールが遅くなったり、反応が不可能になったりする。その結果、アプリをユーザーに表示することが出来なくなる。
このような攻撃にアプリを晒すような、一般的なプログラミングのエラーをテストする必要がある。例えば、ソースコードでハッカーが見つけることが可能な認証チェックの欠如、ハードコードの認証情報の利用、機密データの暗号化を忘れるミス、ウェブサーバーのディレクトリへのアクセスの固定化を忘れるミス等が挙げられる。
正統派のセキュリティの専門家、または、自動的にセキュリティチェックやテストを行うウェブツールを介して、このようなエラーをテストすることが出来る。
獲得したユーザーの人数に関係なく、ユーザーは、初めてアプリを試した日に、アプリが出来るだけ早く動くことを期待する。また、特定の時間、月、または、年、プロモーションがバイラル化した時、もしくは、有名なメディアで取り上げられた時など、トラフィックが急激に増える可能性もある。
どれだけ多くのユーザーがログインしていようが（限度はあるが）、製品が問題なく動くように、アプリとサーバーの環境をテストしておくべきである。大半の質の高いウェブホストは、トラフィックが増加した際に、リアルタイムで処理するためのソリューションを提供している。そのため、ホスティング会社を探す際は、この点を考慮すると良い。
テストは、あらゆるウェブプロジェクトのビルドにおいて重要であり、限られた時間と人材/資金を使って、出来るだけ広い範囲をカバーするためには、体系的なアプローチが必要になる。以下に、典型的なウェブアプリをテストする際の手順を紹介する。
大方、テストは期限を決めたプロセスだと言える（特にローンチに向けたテストにおいては）。だからこそ、アプリをリリースする前に、優先して、徹底的にテストする機能を決めることが重要になる。例えば、オンラインストアを開設するためのアプリを開発しているなら、テキストのアライメントよりも、支払いゲートウェイの接続を優先したいところだ。
このように優先順位をつけると、アプリの重要な機能が、スムーズに動く点を確認し、さらに、切羽詰まった状況で、チーム全体（テスター、開発者、管理者）に対する明確な目標を定めることが出来る。その結果、スムーズなローンチを実現するために、スタッフを正しい方向に導くことが出来るようになる。小さな問題やユーザーが報告した問題には、アプリをリリースした後、いつでもテスト & 対応することが出来る。
アプリをテストする前に、どのようにプロセス全体に取り掛かるかを明確に規定する必要がある。利用可能な文書を全て集め（マーケティング用のコンテンツやユーザー向けの説明書）、テスターとシェアすることから着手してもらいたい。次に、ユーザーがアプリで遭遇する可能性のあるシナリオの原因となる、考えられる使用事例、さらには、ありそうもない使用事例を挙げていく。製品が支障をきたすかどうかを確認するためだ。
また、テスターが問題を報告し、ディベロッパーとデザイナーが、バグを特定し、再現し、修正することが可能な、バグ追跡ツールを用意してもらいたい。
テストの用意が整ったら、意図する通常のサーバーとそっくりな、アクセスを制限したサーバー環境で展開していく。こうすることで、実際にリリースした際と同じような状況で、アプリを試運転し、ローカルサーバーでアプリを開発し、テストしていた時には気づかなった問題を特定することが出来るようになる。
例えば、位置を認識するアプリでは、地図の大きなSVG画像は、読み込むのに時間がかかり、タイムアウトを引き起こしてしまう可能性がある。その結果、モバイルユーザーを困らせ、また、どのように手順を進めばいいのか、あるいは、戻ればいいのか分からず、不安にさせてしまうことが考えられる。
アプリの性能を本格的に試す手順を整え、実際に試す段階だ。
オンラインタスク管理およびコラボレーションアプリのFlowでQAを担当する、ジェレミー・ペッター氏は、「ウェブアプリの大半のテストプロセスは、午後に — あるいは、午後を一週間合わせたとしても — 手っ取り早く片付けることが出来るほど楽ではない。そのため、対応可能な塊に分ける必要がある」と指摘している。
「Flowでは、リストを使って、ユーザーインタラクションの各ポイントをアプリ内のロケーション、さらには、当該のポイントの通常のフォームと機能にタグ付けしている。また、このようなウィジェットをタグ付けして、動くかどうか、許可に反応するかどうか、あるいは、特定の機能に関連しているかどうかを表している。
リストはモジュール式であり、開発中のソフトウェアの変化に応じて、あるいは、バグの再発が起きそうなポイントに応じて、アイテムやタグをを加えることも削除することも出来る。細かい作業を忘れることがないように、このような計画を策定するわけだが、現在最も優先しなければいけない目標、テスターからの報告、そして、カスタマーサポート経由のユーザーからの報告に応じて、焦点は特定の領域に移っていく。」
容易に管理することが可能な、クリーンで、エラーのないユーザー体験を提供するため、コードを検証し、定着したウェブの標準に従っていることを確認する。すると、ブラウザの互換性を高めるだけでなく、パフォーマンスを改善する効果も見込める。
アプリと環境をテストして、トラフィックの急増に対応することが出来るかどうか、また、帯域幅の要件を確認し、アプリのパフォーマンスを妨げている可能性のある障害を探す。併せて、オンラインサービスを活用して、ユーザートラフィック、サーバーの利用状況、そして、不完全なコードや読み込みの遅いスクリプトによってもたらされる問題を監視し、調整を加えて、アプリの早さと効率をアップすることも検討してもらいたい。
最後に、基本的なアプリの利用状況やアップタイム、そして、ユーザーのデータの整合性に至るまで、堅牢なセキュリティを実現し、悪意を持つハッカーから安全を確保するためのテストを行う。
あまり大きな違いはない（とりわけ、モバイルアプリとウェブアプリが同じような機能を提供している場合）。先程も言及したペッター氏は、このように述べている。「同じ原則をウェブアプリとモバイルアプリに双方に当てはめ、モバイルアプリを、ネイティブアプリと同じぐらい、ユーザーを夢中にさせ、そして、ユーザーのリクエストに素早く反応させることを目指している。要するに、多数のブラウザやデバイス、デスクトップ、モバイル、そして、タブレットの設定でテストを行い、出来るだけ優れたユーザー体験を与えることを心掛ければよい。
また、フォントの制限等、モバイルとウェブの一般的なブラウザの機能、そして、広告ブロッカーやパスワードマネージャー等の補足ツールに対して、ソフトウェアがどのように作用するのか予測する必要もある。 この手の機能は、急速に進化しており、テストを行う際は、サポートと内部のアルファテストチームから直接フィードバックを受け、情報を得る必要がある。」
高度なテストを行う際は、ユーザーの気持ちになる必要がある。現在、マーケッター向けのプロジェクト管理アプリ「Brightpod」の開発を行っているサヒル・パリク氏は、「綿密なテストを始める前に、各機能をユーザーがどのように使うのか考える必要がある」と指摘している。ユーザーの気持ちになることで、現実的な使用事例とシナリオを考案し、エラーを事前に防ぐことが出来るようになるだろう。
ジェレミー・ペッター氏は、現場のテスターに対して、次のようなアドバイスを贈っている — テストは、細部を重視するため、高度な集中力が必要とされる。大方、1時間目または2時間目までが最も効率が良いため、私は、数時間おきにプロジェクトを切り替えて、集中力と生産性を出来るだけ高める努力をしている。
「インターネットエクスプローラに切り換えて、互換性のテストを現在進行形の別のテストに組み込むだけでも、集中力を維持する効果が見込める。例えるなら、チェスは戦略がものを言うゲームだが、集中力を一瞬欠くことで、勝敗が決することもある。特定の細かい点や戦略に焦点を絞る代わりに、異なるプロジェクトを同時進行で進め、リラックスした気分を保ち、先入観を持たないように努め、そして、燃え尽き症候群を避けることを私は薦める。」
イメージ: Oleksiy Mark/Shutterstock
この記事は、The Next Webに掲載された「A comprehensive guide to testing your Web app: How to get the most out of your sessions 」を翻訳した内容です。
確かにどれも基本といえば基本なんですけど、こうしてみると、ホント色々ありますね。。。少し前にテレビなどでもやっていた「個人がアプリで一獲千金！」みたいな話が今でも生きているのか（そもそもあったのか）謎ですけど、アイデアを具現化して作るまでは第一歩、もしかすると次の？！大ヒットアプリになる前にきちんとテストしてからリリースしたいものです。 — SEO Japan [G+]
2002年設立から、20年以上に渡りSEOサービスを展開。支援会社は延べ2,000社を超える。SEO/CRO（コンバージョン最適化）を強みとするWebコンサルティング会社。日本初のSEO情報サイトであるSEO Japanを通じて、日本におけるSEOの普及に大きく貢献。
SEO最新情報やセミナー開催のお知らせなど、お役立ち情報を無料でお届けします。
