Web アプリテストチェックリスト（無料テンプレート付き）

Web アプリテスト（Web application testing）とは、ブラウザー上で動作するアプリ（SaaS 管理画面、EC システム、オンラインツールなど）に対して、機能ロジック・フォームバリデーション・クロスブラウザー互換・レスポンシブ・パフォーマンス・セキュリティ・アクセシビリティの 8 つの観点で体系的に検証することです。本記事では、リリース前の受け入れ検証・バージョン回帰・新バージョンのスモークテストにそのまま使える 40 項目以上のチェックリストを紹介します。

Web アプリテスト ≠ Web サイトテスト

観点	Web サイトテスト	Web アプリテスト
典型的な対象	コーポレートサイト、ランディングページ、ブログ	SaaS、管理画面、オンラインエディター
インタラクションの深さ	閲覧とフォーム送信が中心	ログイン状態、複雑な状態遷移、権限、同時実行
テストの重点	コンテンツ、SEO、ビジュアル、コンバージョン導線	ビジネスロジック、データの正確性、エラー処理
状態の複雑さ	低い（ほぼステートレス）	高い（セッション、キャッシュ、複数ロール）

対象がマーケティングサイトであれば、このチェックリストは過剰です。Website QA Checklist を使ってください。本記事は、ログイン状態とビジネスロジックを持つ「アプリ」向けです。

テスト前の準備

テスト範囲とバージョンを明確にする（コミットハッシュまたはビルド番号を記録）
環境マトリクスを用意する：ステージング環境 1 つ以上 + 本番前チェック環境
アカウントマトリクスを用意する：一般ユーザー / 管理者 / 未ログイン、それぞれ 1 つ以上
テストデータを用意する：正常値 + 境界値（超長文字列、特殊文字、空値、大容量ファイル）
記録ツールと記録ルールを決める（バグテンプレートは test case template）

チェックリスト

A. 機能テスト（コア業務フロー）

登録 → メール認証 → ログインの一連の流れを通しで確認する
パスワード再設定から新しいパスワードでのログインまで確認する
各コアフロー（注文・作成・保存など）の正常系を 1 周通す
各コアフローの異常系を確認する：途中キャンセル、重複送信、通信断からの復帰
権限分離を確認する：一般ユーザーは管理者機能にアクセスできない（URL 直打ちでも）
データ整合性を確認する：操作後に一覧・詳細・集計数が同期して更新される
ログアウト後に保護ページへ直接アクセスできないことを確認する（戻るボタンで認証を回避できない）

B. フォームと入力バリデーション

必須項目が空のときに明確なエラーを表示し、送信を阻止する
フォーマットを検証する：メールアドレス、電話番号、日付、数値範囲
境界値をテストする：最大長、最小値、0、負数、超長入力（1000+ 文字）
特殊文字やスクリプト入力（<script>、絵文字、SQL 断片）が安全に処理されることを確認する
重複送信を防止する：送信ボタンの高速ダブルクリックでもレコードは 1 件のみ
ファイルアップロードをテストする：タイプ制限、超大容量、0 バイト、中断
ブラウザーの戻る/進む操作後もフォーム状態が妥当であることを確認する

C. クロスブラウザー互換

Chrome（最新版）
Firefox（最新版）
Safari（macOS + iOS）
Edge（最新版）
差異が出やすい点を確認する：日付ピッカー、ファイルダウンロード、スクロール挙動、CSS レイアウト

D. レスポンシブとモバイル

ブレークポイントを確認する：1920 / 1366 / 768 / 375 幅
スマホでナビゲーション・モーダル・テーブルを操作する（横スクロールのはみ出しなし）
タッチターゲットを十分大きくし、hover 前提の機能にタッチ代替を用意する
縦横の回転を確認する（該当する場合）
ソフトウェアキーボード表示時に入力欄が隠れないことを確認する

E. API とエラー処理

DevTools の Console と Network パネルを開き、コアフローを通して赤いエラーがないことを確認する
通信失敗（オフライン/500）時に白画面やフリーズではなく分かりやすいメッセージを表示する
遅いリクエストにローディング状態を表示し、重複リクエストはデバウンス/キャンセルする
セッション失効時に明確な導線を示す（サイレント失敗ではなくログインへ誘導）
コンソールに未捕捉の例外（Uncaught Error）がないことを確認する

F. パフォーマンス

初期表示の目標を達成する（推奨 < 3s、LCP < 2.5s）
大量データのページでもカクつかない（実データ量でテストする）
画像を圧縮し、遅延読み込みを入れる
メモリリークの兆候を確認する（長時間利用後に明確に遅くなるなど）

G. セキュリティの基本

未ログイン/低権限では URL や API から保護リソースに直接アクセスできない
機密データの通信をサイト全体で HTTPS にする
パスワード入力欄に平文を表示し返さない
ページ URL に機密トークンを載せない（またはマスクと期限切れを徹底する）
エラー表示でスタックトレースや技術的詳細をエンドユーザーに見せない

H. アクセシビリティと細部

キーボードだけで主要操作を完了できる（Tab 順序、Enter で送信）
画像に alt テキストを付け、フォームコントロールに label を関連付ける
カラーコントラストを WCAG AA（4.5:1）以上に保つ
空状態・読み込み中・エラー状態の 3 状態をデザインする（白画面のままにしない）

テスト結果の記録と追跡方法

実践	内容
不具合ごとに証拠を添える	スクリーンショットに注釈を付けて再現箇所を示す。操作系の問題は録画する
技術的コンテキストを自動取得する	Console/Network エラーをツールで自動取得し（例：BugCapturer）、手写メの漏れを防ぐ
構造化してアーカイブする	不具合リストを Excel にエクスポート（番号/モジュール/手順/期待/実際/重要度/状態）
結果を共有しやすくする	チーム間で確認が必要なときはファイルではなく共有リンクを発行する

BugCapturer の診断機能はこの中間の 3 つを一度に解決します。スクリーンショットや録画の取得と同時に Console と Network のエラーを自動でキャプチャし、ワンクリックで 12 列の Excel をエクスポートでき、インストール不要の共有リンクを開発者やクライアントに発行することもできます。詳細は診断機能の製品ページをご覧ください。レポート構造の詳細は How to Export Bug Reports to Excel を参照してください。

リリース前の最終確認では、UAT Complete Guide に沿ってユーザー受け入れテストを 1 ラウンド行い、本チェックリストを実行シートとして使うのがおすすめです。

FAQ

Web アプリテストにはどのくらいの期間がかかりますか？

範囲によります。新バージョンのスモークテストは 0.5〜1 日、完全な回帰テストは 2〜5 日。大型リリースでは通常 1〜2 週間を見ておきます（修正の再検証を含む）。本チェックリストの 8 グループを一通り回すには約 1〜2 人日です。

手動テストと自動テストはどう分担すべきですか？

経験則では、まず A/B/C/D を手動でカバーし（特に初回リリース）、安定したら頻繁な回帰パス（ログイン、コアフロー）を自動化します。E（Console/Network の確認）はツールで収集できます。G のセキュリティは専門のスキャナーとコード監査で補完するのがおすすめです。

このチェックリストとテスト計画の関係は何ですか？

チェックリストは「何をテストするか」に答え、Test Plan Template は「誰が・どの環境で・いつテストし、合否基準は何か」に答えます。先に計画を定めてからチェックリストを実行し、2 つのドキュメントをセットで使いましょう。

QA のいないチームはこのチェックリストをどう使えばよいですか？

分担します。開発者は A/B/E（技術周り）をセルフテストし、プロダクト担当は A/D（ビジネスと体験）を受け入れ確認し、リリース前には全員で 2 時間のバグバッシュを行います（進め方は Bug Bash Guide）。記録はスクリーンショットと診断情報付きのテンプレートに統一し、コミュニケーションコストを下げましょう。

まとめ

Web アプリテストの鍵は「どれだけ頑張ってテストするか」ではなく、観点をフルカバーし、結果をすべて追跡可能にすることです。機能・フォーム・互換性・レスポンシブ・エラー処理・パフォーマンス・セキュリティ・アクセシビリティの 8 観点をチェックリストに沿って進め、見つけた問題は「注釈付きスクリーンショット + Console/Network 診断 + 構造化された記録」として統一してアーカイブします。このチェックリストはそのままテスト計画にコピーして実行シートとして使えます。