はじめに
概要
本ドキュメントは、Webサイト公開前に実施すべきテスト項目を体系的にまとめたガイドです。テストサイトの役割やチェックリスト、CMS導入時の注意点、異常値や自動化の観点まで幅広く扱います。制作担当者やエンジニアが実務でそのまま使えることを目指します。
対象読者
- Web制作・運用に関わる方
- テスト設計を担当するエンジニア
- 品質チェックを行うディレクター
専門用語は必要最小限にし、具体例で補足します。
本書の構成と使い方
全7章で構成し、順に読み進めれば公開前の準備が整います。まず第2章でテストサイトの目的を明確にし、第3章で具体的なチェック項目を提示します。作業時は本書のチェックリストをコピーして実際のテストシートに落とし込んでください。
テスト時の基本方針
- ユーザーの主な操作を優先して検証します。重要な操作を先に確認すると効率が上がります。
- 本番環境に影響を与えないよう、テスト用環境を分けて実行します。
- 再現性を意識し、手順を明確に残します。
この章は全体の入口です。次章でテストサイトの役割と準備事項を詳しく説明します。
テストサイトとは何か
定義
テストサイトは、本番公開前にWebサイトの見た目や動作を確認するための環境です。公開直前に実際の閲覧者が遭遇する問題を事前に見つける役割を持ちます。例：レイアウト崩れ、リンク切れ、フォーム送信の失敗、画像表示の誤り。
目的
主な目的は「ユーザーに問題を出さない」ことです。細かな文言ミスや動作の不整合を修正し、公開後のトラブルを減らします。デザイン確認、動作確認、性能チェックの三点が中心です。
本番環境との関係
本番とほぼ同じ条件で動作させることが重要です。サーバー設定、SSL、データベースの構成を合わせると再現性が高まります。環境差があると本番でだけ発生する不具合を見落とす恐れがあります。
実例と注意点
・フォーム：必須チェックやエラーメッセージを実際に送信して確認する。
・リンク：内部と外部の両方を自動チェックと手動確認で確認する。
・コンテンツ：誤字や表示崩れはブラウザや画面サイズで検証する。
運用のコツ
定期的にテストサイトを更新し、公開前のチェックリストを運用するとミスを減らせます。
Webサイトのテスト項目一覧
レイアウト・デザイン
- ヘッダー・フッターが正しく表示されるか。ロゴや連絡先の位置を確認します。
- レスポンシブ対応：画面幅ごとの崩れや見切れをチェックします。
- 文字・色・フォントサイズ：可読性やコントラストを確認します。
- 画像表示・アイコン：欠損や拡大縮小の崩れを確認します。
- 誤字脱字・文言：表記ゆれやリンク文言の整合性を確認します。
機能・フォーム
- 入力バリデーション：必須チェック、形式（メール・電話）、最大長を検証します。
- ボタン動作：クリックで期待通り動くか、連打時や無効時の挙動を確認します。
- ファイルアップロード・送信：許容形式やサイズエラーの扱いを確認します。
- メール送信や通知：送信先・内容・送信可否を検証します。
リンク・ナビゲーション
- リンク切れ（内部・外部）を確認します。
- パンくずやメニューの遷移が正しいか確認します。
- 新規ウィンドウ・ターゲット指定の挙動をチェックします。
CMS・権限管理
- ユーザー権限（閲覧・編集・公開）の設定を確認します。
- 下書き・公開のフロー、承認ワークフローを検証します。
- 編集履歴や差し戻しが機能するか確認します。
表示・互換性
- 主要ブラウザ（Chrome/Firefox/Safari/Edge）で表示確認します。
- モバイル・タブレットでの表示と操作性をチェックします。
- 画像形式やフォント読み込みの互換性を確認します。
SEO・メタ情報
- title・meta description・見出しタグの適正を確認します。
- canonicalやrobotsの設定、解析タグの設置を確認します。
パフォーマンス・セキュリティ
- 表示速度の計測と画像やスクリプト最適化を行います。
- HTTPSや入力値のサニタイズ、基本的な脆弱性対策を確認します。
エラー・異常値
- 404・500ページの表示と導線を確認します。
- 異常入力やタイムアウト時の挙動・メッセージを検証します。
その他
- SNSシェア時のOGP表示、公開情報の正確性を確認します。
- 簡易的なアクセシビリティ（alt属性、フォーカス順）をチェックします。
第4章: テストケース作成時のポイント
目的を明確にする
テストで何を確かめたいかを最初に書きます。例えば「会員登録が正しく完了するか」「フォーム送信時に誤った入力でエラーが出るか」など、目的を短く記載します。目的がぶれると無駄なケースが増えます。
項目は小さく分ける（粒度）
1つのケースで複数の動作を確認しないでください。例：ログイン→プロフィール更新を分けて作成します。こうすることで失敗箇所の特定が早くなります。
前提条件とテストデータを具体的に書く
テスト開始前の状態（ログイン済み、特定のアカウント有無など）と、使うデータ（メールアドレス、パスワード例）を明記します。誰が見ても同じ手順で再現できます。
手順は誰でも再現できるように
操作は順番に番号で書きます。画面遷移やボタン名、期待する表示も書くと良いです。例：「1. トップページのログインをクリック 2. メールを入力 3. 送信ボタンを押す」
期待結果は正常系・異常系で分ける
正常系は成功時の画面やメッセージを正確に記載します。異常系は入力ミスや想定外の状態での応答（エラーメッセージ、フォームのブロック）を具体的に示します。こうして合否判定が明確になります。
優先度とメンテ性を付ける
重要な機能は高優先度にし、よく使う手順はテンプレ化して再利用します。テストが増えたときの保守が楽になります。
備考（実行時の注意）
実行環境（ブラウザ、端末）、テスト日時のメモを残してください。環境差で結果が変わることがあるためです。したがって、同じ条件で繰り返せるようにすることが大切です。
CMS導入時の追加項目
投稿・編集・削除・プレビュー・承認フロー
投稿は下書き保存、公開、予約公開、下書き復元などを必ず確認します。プレビューは公開状態と同じ見た目になるか、権限の違う閲覧で表示崩れがないかを検証します。承認フローは差戻しやコメント付き承認が正しく機能するか、メール通知が届くかも確認します。
ユーザー権限ごとの動作確認
管理者・編集者・投稿者・寄稿者などの役割でできる操作を一覧化して検証します。たとえば投稿者が公開できない、編集者が他者の記事を編集できる、メニュー項目が表示されない等をチェックします。
メディアとファイル管理
画像や添付ファイルのアップロード制限、サムネイル生成、ファイル名の衝突、パスの正当性、外部CDNとの連携を確認します。アップロード時のウイルスチェックや拡張子制限もテストします。
バックアップ・リストア
データベースとファイル両方のバックアップ手順を検証し、復元テストを行います。復元後にIDや参照パスが壊れていないか、シリアライズされたデータ（設定やウィジェット等）が正しく復元されるか確認します。
プラグイン・テーマ・同時編集の組合せ
複数のプラグインやテーマを入れた状態での表示・動作確認をします。複数ユーザーが同時に編集した場合の競合（ロック機能や上書き防止）が働くかを確かめます。
検索・インデックス・パフォーマンス
内部検索や外部検索連携でインデックスの反映遅延がないか、サイトマップやメタ情報が正しく出力されるか、キャッシュをクリアした際の整合性も確認します。
監査ログと通知
誰がいつ何をしたかを記録する監査ログ、権限変更や公開イベントの通知（メールや管理画面内通知）が正しく届くかをチェックします。
テスト環境とデータ管理
本番と同じ設定のステージング環境で検証し、テストデータは個人情報を含まないようにサニタイズします。復元手順やロールバック手順も文書化しておきます。
異常値・組み合わせ・自動化の観点
異常値入力テスト
入力欄には想定外の値を入れて挙動を確認します。具体例として、文字列フィールドに長い文字列（例：10万文字）、特殊文字（例：<>%$@）、改行や制御文字、全角スペースのみ、空文字、NULL相当の送信などを試します。数値では極端な値（マイナス、非常に大きい値、小数）、日付では不正な形式や未来日・過去日を入力します。ファイルアップロードは巨大ファイル、拡張子偽装、ウイルス署名ファイルの模擬を確認します。これらでエラーメッセージの分かりやすさと処理の安定性を検証します。
組み合わせテスト
複数機能や設定の組み合わせで発生する不具合を探します。例として、ログイン状態（管理者/一般）×言語設定×機能フラグ、またはカート内クーポン×配送方法×支払方法の組み合わせを確認します。優先度の高い組み合わせから絞り込み、表やマトリクスで管理すると効率的です。データベースや外部APIの状態変化も組み合わせに含めます。
自動化のポイント
SeleniumやPlaywrightでの自動化は省力化に役立ちます。優先度の高いシナリオ（ログイン、購入フロー、入力検証）を自動化し、CIに組み込みます。安定性確保のために明確なセレクター、待機処理、スクリーンショット取得、リトライ戦略を実装してください。テストデータのセットアップと後始末を自動化して環境汚染を防ぎます。定期実行で回帰を早期に検出できます。
実務的な注意点
異常値は本番データで試すべきではありません。ステージング環境や専用アカウントを使い、ログやメトリクスを確認して副作用を把握します。また、自動化は万能でないため、組み合わせの探索や微妙な見た目の不具合は人手での確認を続けてください。
まとめと運用への示唆
要点の振り返り
Webサイトのテストはデザイン、機能、SEO、性能、セキュリティなど多面的に行う必要があります。テストサイト（ステージング）での確認と本番での監視を組み合わせると、トラブルを早期に発見できます。
運用で意識すること
- リリース前チェックリストを作る：ブラウザ表示、フォーム送信、リンク切れ、画像表示、レスポンスなど実例を含めて項目化します。
- ロールバック手順を用意する：問題が出たときに元に戻す手順を短時間で実行できるようにします。
日常の監視と対応
- モニタリングを設定する：ページ表示速度やエラー率を自動で通知する仕組みを入れます（例：メールやチャット通知）。
- 定期的な安全点検：プラグインやライブラリの更新、脆弱性スキャンを定期的に行います。
自動化とチーム運用
テストの自動化で繰り返し作業を減らします。回帰テストや重要なユーザーフローは自動化し、手動テストは感覚や見た目の確認に集中します。チームでの共有ドキュメントや手順書を整備すると属人化を防げます。
実務への示唆
小さな変更でもテストと監視を怠らないことが最も重要です。日々の運用にテストと観察を組み込み、ユーザーにとって信頼できるサイト運営を目指してください。
