Web制作のテスト設計

このページで学ぶこと

• テストを「完成後にバグを探す工程」ではなく、要件を確認可能な形へする活動として捉える方法
• 単体、コンポーネント、結合、E2E等のテスト範囲
• Web制作特有のブラウザ・端末・レスポンシブ・API・キャッシュ・外部サービスの確認
• 自動テストと手動テストをリスクに応じて組み合わせる方法
• 不具合管理、回帰テスト、受入、公開判定の進め方

まず全体像

テストは、仕様通り動くかだけでなく、利用者の目的と事業要件を満たし、異常時にも受け入れ可能な動作をするか確認する活動です。

flowchart LR
    R[要件・利用者の目的] --> C[受入条件・テスト条件]
    C --> T[手動・自動テスト]
    T --> B[不具合・リスク]
    B --> F[修正・判断]
    F --> G[公開可否]

テストを公開直前に始めると、要件の曖昧さや設計の問題が大きな手戻りになります。

要件定義時に「どう確認するか」を考えることで、仕様の抜けや解釈差を早く発見できます。

テストの目的

仕様適合

決めた機能・表示・データが仕様通りであること。

利用者の目的達成

予約、検索、問い合わせ、購入等の主要行動を完了できること。

リスク低減

個人情報漏えい、二重決済、公開事故、検索流入消失等の重大問題を防ぐこと。

変更の安全性

改修時に既存機能が壊れていないこと。

判断材料

残っている不具合・制約を把握し、公開可能か責任者が判断できること。

テスト件数を増やすこと自体が目的ではありません。

重要なリスクを優先し、結果を判断へ使えることが重要です。

要件をテスト可能にする

「使いやすい」「高速」「適切に表示」では、合否を判断できません。

テスト可能な形へ具体化します。

曖昧な要件

検索結果を素早く表示する。

確認可能な要件

• 通常条件で検索開始から2秒以内に結果または読み込み状態を表示する
• 0件時に条件変更の案内を表示する
• APIが10秒応答しない場合は再試行可能なエラーを表示する
• 検索条件をURLへ保持し、戻る操作で復元する

数値が必要ない要件でも、利用者の操作と期待結果を記載します。

テスト条件は利用者の流れから作る

flowchart LR
    A[流入] --> B[情報を探す]
    B --> C[比較する]
    C --> D[入力する]
    D --> E[確認する]
    E --> F[完了する]
    F --> G[通知・後続業務]

主要な利用者フローごとに、次を確認します。

• 正常に完了する
• 入力を間違える
• 該当データがない
• 戻る・再読み込み
• 途中離脱・再開
• 二重操作
• 通信が遅い
• 外部サービスが停止
• 権限がない
• 期限・在庫・予約枠が変わる

画面単位だけでテストすると、複数画面・外部システムをまたぐ不具合を見落とします。

テストの主な種類

種類	主な対象	例
静的解析	ソース・設定	型、構文、規約、秘密情報
単体テスト	小さな関数・処理	金額計算、入力変換
コンポーネントテスト	UI部品	ボタン、フォーム、モーダル
結合テスト	複数部品・API・DB	フォーム登録、CMS取得
E2Eテスト	利用者の一連の流れ	検索から予約完了
ビジュアルリグレッション	見た目	共通部品変更による崩れ
クロスブラウザ・実機	環境差	Safari、Chrome、iPhone
性能テスト	速度・負荷	初期表示、API、大量アクセス
アクセシビリティテスト	利用可能性	キーボード、読み上げ、拡大
セキュリティテスト	安全性	権限、依存、設定、診断
コンテンツ・SEO確認	情報・検索	リンク、メタ情報、リダイレクト
計測確認	分析データ	GAイベント、同意、重複発火

一つのテストで他の領域を代替できません。

E2Eテストが通っても、すべての表示・セキュリティ・アクセシビリティが正しいとは限りません。

単体テスト

小さな処理を外部依存から切り離して確認します。

例：

• 日付表示
• 税・割合計算
• 検索条件の変換
• URL生成
• バリデーション
• APIレスポンスの整形

利点

• 高速
• 失敗箇所を特定しやすい
• 多くの入力パターンを試せる
• 改修時に繰り返しやすい

限界

• 実ブラウザ・API・画面の組み合わせは確認しない
• テストの書き方が実装詳細へ依存しすぎる場合がある
• 利用者が目的を達成できる保証にはならない

コンポーネントテスト

ボタン、入力欄、カード、モーダル等を、画面部品として確認します。

• 表示状態
• 操作
• 入力
• エラー
• 読み込み
• キーボード
• イベント発火

デザインシステムや共通UIでは、部品単位のテストが多数ページの品質へ効きます。

ただし、実際のページ内での組み合わせ・レイアウトは別途確認します。

結合テスト

複数の機能・システムを組み合わせて確認します。

例：

• フォームからAPIへ登録
• CMSから記事を取得して表示
• 決済完了後に注文状態を更新
• 会員権限に応じてデータを取得
• Webhookで検索インデックスを更新

外部サービスを実際に使うか、モックを使うかを目的で分けます。

モックだけでは、本番の認証・速度・制限・データ差を確認できません。

E2Eテスト

利用者に近い形で、ブラウザから一連の操作を確認します。

sequenceDiagram
    participant U as テスト利用者
    participant W as Web画面
    participant A as API
    participant D as データ・外部サービス

    U->>W: 条件入力・送信
    W->>A: リクエスト
    A->>D: 処理
    D-->>A: 結果
    A-->>W: レスポンス
    W-->>U: 完了・エラー表示

向いている対象

• 最重要の利用者フロー
• ログイン
• 予約・購入・問い合わせ
• 複数システム連携
• 公開後のスモークテスト

注意点

• 実行時間が長い
• 外部サービス・データへ影響される
• 壊れやすいテストになることがある
• 原因特定が難しい
• すべてをE2Eで網羅すると保守負荷が高い

重要な流れを絞り、下位レベルのテストと組み合わせます。

自動テストと手動テスト

自動化しやすいもの

• 同じ処理を繰り返す
• 明確な合否がある
• 多くの入力パターン
• 主要フロー
• リンク・構文
• 回帰確認
• 複数ブラウザの基本動作

手動確認が必要なもの

• 文章の分かりやすさ
• 視覚的な違和感
• 実機の操作感
• 読み上げ内容の適切さ
• 複雑な例外
• 新機能の探索
• 外部サービスとの業務フロー
• 利用者の迷い

自動テストは高速・反復可能ですが、期待結果が間違っていれば誤った動作を合格にします。

手動テストは柔軟ですが、再現性・網羅性・記録が不足しやすくなります。

両方を組み合わせます。

テスト戦略はリスクから決める

すべての機能を同じ深さでテストしません。

flowchart TD
    A[機能・変更] --> B{失敗時の影響}
    B -->|大きい| C[多層の自動・手動テスト]
    B -->|中| D[重要条件を重点確認]
    B -->|小さい| E[基本・探索的確認]
    C --> F{変更頻度}
    D --> F
    E --> F
    F -->|高い| G[回帰自動化を優先]
    F -->|低い| H[手動・スポット確認も選択]

優先度が高い例：

• 決済
• 個人情報
• ログイン・権限
• 予約枠・在庫
• 公開・削除
• URL・リダイレクト
• 全ページ共通部品
• 大量アクセス箇所
• 法令・契約に関わる表示

Web制作特有の状態

各画面・部品には、正常データ以外の状態があります。

状態	確認例
読み込み中	操作できるか、二重送信しないか
0件	次の行動を案内するか
一部欠損	レイアウト・意味が壊れないか
エラー	技術情報を出さず復旧方法を示すか
遅延	タイムアウト、キャンセル、再試行
権限なし	情報を漏らさず案内するか
期限切れ	予約・リンク・セッション
大量件数	ページング・性能・上限
重複操作	二重登録・二重決済
オフライン・通信切断	入力内容・再送
外部障害	代替表示・旧データ
キャッシュ不整合	更新反映・再検証

デザインカンプで正常状態だけを作ると、実装段階で場当たり的な表示になります。

ブラウザ・端末・レスポンシブ

対応範囲を「主要ブラウザ」と曖昧にせず、バージョン方針を決めます。

• Chrome
• Safari
• Edge
• Firefox
• iOS Safari
• Android Chrome
• アプリ内ブラウザ
• 社内標準端末

端末・画面条件

• 最小・最大幅
• 縦・横
• 高解像度
• 文字拡大
• ズーム
• タッチ
• キーボード
• マウス
• 通信速度
• OS設定
• ダークモード等

実機とエミュレーションは役割が異なります。

エミュレーションだけでは、Safari固有挙動、ソフトウェアキーボード、スクロール、カメラ・ファイル選択等を完全に再現できません。

ビジュアルリグレッション

基準画像と新しい表示を比較し、意図しない見た目の変化を検出します。

共通CSS・コンポーネント変更による広範囲な崩れを見つけやすくなります。

注意点

• 動的日時・広告・画像で差分が増える
• 1pxの差をすべて不具合にすると運用不能
• 見た目が同じでも意味構造・操作は確認できない
• 基準画像自体が正しい必要がある
• レスポンシブ条件を選ぶ

差分を自動検出し、人間が意図した変更か判断する運用が必要です。

性能テスト

性能は公開直前だけでなく、設計・実装中に継続確認します。

主な対象

• 初期表示
• 主要コンテンツの表示
• 操作反応
• レイアウト変動
• API応答
• 画像・動画
• JavaScript
• 外部タグ
• 大量アクセス
• ビルド時間

ラボ環境の測定と、実利用者データは異なります。

目標値、測定ページ、端末・通信条件、公開後の監視を決めます。

外部サービスのテスト

本番では次の外部要素へ依存します。

• CMS
• API
• 検索
• 地図
• 決済
• メール
• CRM
• 認証
• 動画
• 計測タグ
• 広告
• Cookie同意

確認する状態：

• 正常
• 遅延
• 停止
• 認証期限切れ
• 利用制限
• 不正レスポンス
• 部分成功
• 仕様変更
• 本番・検証の差

外部サービス自体を修正できなくても、Web側の代替表示・タイムアウト・連絡は設計できます。

テスト環境とデータ

環境

• ローカル
• 開発
• Pull Requestプレビュー
• ステージング
• 本番

各環境で、CMS、API、認証、メール、計測、個人情報の接続先を確認します。

テストデータ

• 最小・最大文字数
• 長い名前・住所
• 絵文字・多言語
• 0件
• 大量件数
• 期限境界
• 欠損
• 権限別
• 重複
• 不正形式
• 画像の縦横比
• 実在しない個人情報

本番個人情報を安易に検証環境へコピーしません。

テストデータの作成・削除担当も決めます。

不具合の重大度と優先度

重大度

システム・利用者への影響です。

• 致命的：漏えい、決済誤り、全体停止
• 重大：主要フロー不可、広範囲の表示不能
• 中：回避策はあるが利用へ影響
• 軽微：限定的な表示・文言問題

優先度

いつ直すかの事業判断です。

公開日、影響人数、代替手段、修正リスク等を加味します。

重大度と優先度は同じではありません。

軽微でも全ページ共通でブランド影響が大きい場合や、公開初日に必須の文言は優先度が高くなることがあります。

不具合チケット

最低限、次を記録します。

• タイトル
• 発生環境
• URL・画面
• 前提条件
• 操作手順
• 実際の結果
• 期待結果
• 画面・動画・ログ
• 再現率
• 重大度・優先度
• 担当・期限
• 原因
• 修正版
• 再確認結果
• 類似箇所への影響

「崩れています」だけでは、再現・修正・確認ができません。

回帰テスト

修正や追加によって、既存機能が壊れていないか確認します。

• 共通ヘッダー
• フォーム部品
• API共通処理
• 認証
• CSS
• CMSモデル
• URL生成
• 計測
• 多言語

変更影響の大きい部分を自動化すると、反復確認しやすくなります。

不具合修正時には、同じ問題を再発させないテスト追加を検討します。

受入テスト

発注側・業務側が、要件と業務フローを満たすか確認します。

制作会社の内部テストとは目的が異なります。

受入前に必要なもの

• 対象範囲
• 環境
• アカウント
• テストシナリオ
• 期待結果
• 既知制約
• 不具合登録方法
• 期間
• 判断者
• 再確認期間

受入期間を「自由に触ってください」だけにすると、確認範囲と完了条件が曖昧になります。

公開判定

公開時点ですべての不具合がゼロとは限りません。

公開判定では次を確認します。

• 重大不具合の残数
• 主要フローの結果
• セキュリティ指摘
• アクセシビリティ要件
• 性能目標
• 対応ブラウザ
• コンテンツ
• リダイレクト
• 計測
• バックアップ・切戻し
• 既知制約
• 公開後対応計画
• 責任者承認

残課題は、内容、影響、回避策、対応予定を記録します。

実案件ではどう考えるか

コーポレートサイト

• 共通テンプレート
• CMS一覧・詳細
• リンク
• フォーム
• 検索
• レスポンシブ
• アクセシビリティ
• SEO
• 計測
• リダイレクト

を組み合わせます。

全ページを同じ深さで目視せず、テンプレート全件・コンテンツ自動検査・代表ページ目視を分けます。

予約サイト

• ログイン
• 枠の変化
• 二重操作
• タイムアウト
• 決済
• 確認メール
• 管理画面
• 取消
• 外部障害

等の業務シナリオを重点化します。

大量記事移行

• 件数一致
• URL
• 本文
• 画像・PDF
• カテゴリ
• 公開日
• 文字化け
• リンク
• リダイレクト
• サイトマップ

は自動検査し、代表・異常データを目視します。

PMチェックリスト

• 要件ごとに確認方法・合否条件を定義している
• 主要な利用者フローからテストシナリオを作っている
• 正常、0件、エラー、遅延、重複、権限状態を用意している
• 単体・結合・E2Eの役割を分けている
• 自動化する対象を変更頻度とリスクで選んでいる
• 対応ブラウザ、OS、端末、画面幅を明記している
• 実機確認とエミュレーションを使い分けている
• API・CMS・外部サービス停止時をテストしている
• 本番相当のデータ件数・画像・通信で性能を確認している
• アクセシビリティ・セキュリティ・SEO・計測を別観点で確認している
• テスト環境と本番の差を把握している
• 個人情報を使わないテストデータを準備している
• 不具合の重大度・優先度・再確認を管理している
• 受入範囲、期間、判断者、完了条件を合意している
• 公開判定に残課題・切戻し・公開後対応を含めている

よくある誤解・失敗

「テストは実装が終わってから始める」

受入条件、異常状態、テストデータは要件・設計へ影響します。早い段階から設計します。

「E2Eテストを増やせば品質を保証できる」

E2Eは重要ですが、遅く不安定になりやすく、原因特定も難しいため、単体・結合・手動確認と組み合わせます。

「自動テストが通れば目視確認は不要」

文章、操作感、視覚、読み上げ、実機、探索的な問題は手動確認が必要です。

「ステージングで動けば本番も同じ」

環境変数、ドメイン、CORS、権限、データ量、外部サービス、キャッシュ等が異なることがあります。

「不具合ゼロになるまで公開できない」

ゼロを目指すだけでなく、残存リスクを可視化し、重大度・回避策・対応計画を責任者が判断します。重大な安全・業務問題は妥協しません。

理解度チェック

Q1. テストを要件定義時から考える利点は何ですか。

回答と解説

合否条件を考えることで曖昧な仕様、異常状態、必要データ、責任範囲を早期に発見でき、公開直前の大きな手戻りを減らせます。

Q2. 単体テストとE2Eテストの主な違いは何ですか。

回答と解説

単体テストは小さな処理を高速・独立して確認し、E2Eはブラウザから複数システムをまたぐ利用者フローを確認します。範囲・速度・原因特定のしやすさが異なります。

Q3. 外部APIを使う画面で、正常応答以外に何を確認しますか。

回答と解説

遅延、タイムアウト、0件、認証切れ、利用制限、エラー形式、部分成功、再試行、古いデータ・代替表示等を確認します。

Q4. 自動テストへ向く対象を挙げてください。

回答と解説

明確な合否があり、繰り返し実行し、変更頻度・事業影響が高い処理です。計算、主要フロー、共通部品、回帰確認等が候補です。

Q5. 公開判定で不具合件数以外に確認することは何ですか。

回答と解説

重大度、主要フロー、セキュリティ、アクセシビリティ、性能、対応環境、既知制約、切戻し、公開後対応、責任者承認等です。

参考資料

• web.dev「Learn Testing」
  https://web.dev/learn/testing
  テストの目的、実行場所、環境、種類、自動化等を体系的に学ぶ公式コース。
• web.dev「Types of automated testing」
  https://web.dev/learn/testing/get-started/test-types
  単体・コンポーネント・結合・E2E等の範囲を理解するための公式解説。
• web.dev「What to test and your approach」
  https://web.dev/learn/testing/get-started/what-to-test
  主要な利用事例・重要部品からテスト対象を選ぶ考え方。
• Playwright「Best Practices」
  https://playwright.dev/docs/best-practices
  利用者から見える挙動を検証し、回復力のあるブラウザテストを書くための公式ガイド。