🐈
探索的テスト入門 ~構造的な思考プロセスで探索的テストを実施する~
はじめに
「仕様書にはないバグを、どうやって見つけますか？」
テスト経験が 2〜3 年ほどあると、多くの方がぶつかる課題です。
要件書やテストケースを消化するだけでは、ユーザーが直面する“想定外の問題”を発見するのは難しい。
そこで登場するのが 探索的テスト（Exploratory Testing） です。
「自由にやる」活動と思われがちですが、実際には 構造化して実施することで成果が最大化 します。
本記事では書籍『フルスタックテスティング』第 2 章の内容を整理し、実務に落とし込める形でまとめました。
TL;DR
- 探索的テストは 仕様書外の不具合を発見するユーザー視点の活動
- 「8 つのフレームワーク」「4 つの探索パス」「5 つの着眼点」で 属人性を減らし構造化 できる
- 継続的に計画して実施すること が、アジャイル開発での品質フィードバックを強化する
1. 探索的テストとは？
従来のテストは、要件定義書やユーザーストーリーに沿って設計されます。
しかし現実のユーザー行動は、必ずしも仕様通りではありません。
探索的テスト とは、既知の仕様に縛られずユーザー視点でアプリを操作し、未知の不具合や想定外のフローを発見する活動です。
特徴は以下の通りです。
- 分析力・観察力に依存する（属人化しやすい）
- 既知のテスト設計では拾えない不具合を発見できる
- “探索”という言葉の通り、アプリを理解しながらテストを進める
→ だからこそ「フレームワーク」を活用して 構造化する工夫 が欠かせません。
2. 思考を支える「8 つのフレームワーク」
探索的テストは「自由にやる」と属人化し、再現性や網羅性が下がります。
そこで使えるのが 8 つのフレームワーク。本来はテスト設計手法ですが、探索の“思考の道具”として有効です。
1. 同値クラス分割法
- 定義：入力をグループ化し、各グループから代表値を選ぶ
- 例：年齢入力 → 未成年（0〜19）／成人（20〜120）／不正値（負数や 121 以上）
- 適用シーン：入力値が膨大なフォームや検索条件
- 落とし穴：全値を網羅しようとして非効率になる
2. 境界値分析
- 定義：境界条件付近に不具合が集中する
- 例：「6 文字以上」パスワード → 5/6/7 文字を確認
- 適用シーン：文字数制限、数値範囲、閾値判定
- 落とし穴：正常値だけでテストを終える
3. 状態遷移
- 定義：状態によって挙動が変わる点を確認する
- 例：未ログイン → ログイン済み → ログアウト後に再操作
- 適用シーン：認証、購入フロー、マルチステップフォーム
- 落とし穴：状態を図示せず機能単体だけを確認
4. デシジョンテーブル
- 定義：条件と結果を表形式で整理して網羅する
- 例：会員種別 × 在庫有無 × 支払い方法 → 注文可否
- 適用シーン：複雑なビジネスルール
- 落とし穴：文章で整理して抜け漏れが生じる
5. 原因結果グラフ
- 定義：入力と出力の因果関係を図に整理する
- 例：割引条件を複数組み合わせ、どのケースで適用されるか図示
- 適用シーン：複雑な計算式や業務ルール
- 落とし穴：因果関係を明文化せず属人的に理解する
6. ペアワイズ法
- 定義：条件の組合せを「2 つずつ」網羅する
- 例：OS × ブラウザ × 言語設定 → 全組合せは膨大だが、ペア網羅で効率化
- 適用シーン：多環境テスト、設定が多い UI
- 落とし穴：全組合せを網羅しようとして工数過多になる
7. サンプリング
- 定義：全データから代表的なサンプルを選んで検証する
- 例：数千商品から売上上位・下位・特殊カテゴリを選ぶ
- 適用シーン：データ件数が膨大なケース
- 落とし穴：偏ったデータ選定で検証の幅が狭くなる
8. エラー推測
- 定義：経験や直感から「壊れやすい箇所」を狙う
- 例：特殊文字入力、通信遮断、タイムアウト
- 適用シーン：過去に障害が多い領域、新機能直後
- 落とし穴：個人の思いつきで終わり、共有されない
3. アプリを歩く「4 つの探索パス」
フレームワークで観点を広げたら、実際にどこを歩くか を考えます。
1. 機能的ユーザーフロー
- 定義：ユーザーが実際にたどる操作の流れを探索する
-
例：
- 単一ユーザー正常系（まず基本動線を確認）
- 繰り返しフロー（同じ操作を繰り返すと挙動が変化するか）
- 複数ユーザー（同時操作で衝突が起きないか）
- 落とし穴：正常系を 1 回だけ確認して終える
2. 故障とエラーハンドリング
- 定義：アプリが直面し得る故障やエラーを想定し、ハンドリングを確認する
- 例：ネットワーク切断、サービス停止、入力ミス時のエラーメッセージ表示
- 適用シーン：外部連携、通信依存の処理、入力フォーム
- 落とし穴：正常時だけの確認で終える
3. UI のルック＆フィール
- 定義：見た目や操作感を探索する
- 例：ブラウザ間で表示が崩れないか、遅延時にローディングが出るか
- 適用シーン：Web アプリ、UI 依存度が高いサービス
- 落とし穴：「動けばよい」と考え UI 品質を軽視する
4. 機能横断観点
- 定義：特定機能に限らずアプリ全体に対して影響する観点を探索する
- 例：セキュリティ、プライバシー、認証/認可、パフォーマンス、アクセシビリティ、監査
- 適用シーン：大規模 Web アプリ、規制がある業界
- 落とし穴：横断的な影響を無視して単一機能のみ確認
4. 背景を理解する「5 つの着眼点」
テストの精度を高めるには、アプリの背景理解が必須です。
1. ユーザーペルソナ
- 定義：代表的ユーザー像を設定し、その立場で探索する
- 例：若者と高齢者で求めるものは異なるため観点も異なる
- 落とし穴：テスター自身の感覚だけで判断する
2. ドメイン
- 定義：業界特有の知識やワークフローを理解して探索する
- 例：EC → 注文 → 支払い → 納期確定 → 注文確認、金融 → 利息計算や端数処理
- 落とし穴：ドメイン知識を持たず一般的な観点だけで済ませる
3. ビジネスの優先事項
- 定義：事業上重要な要素に沿って探索する
- 例：拡張性が重要なら API 連携やシステム統合に注目
- 落とし穴：事業優先度を気にせず、機能観点のみ重点的に確認する
4. インフラストラクチャと設定
- 定義：環境や制約を理解し探索に活かす
- 例：レート制限超過時の挙動、VPN 下での接続
- 落とし穴：デフォルト環境でしか検証しない
5. アーキテクチャ
- 定義：内部構造や技術選定を理解し探索を広げる
- 例：マイクロサービス間通信、外部サービス障害時の挙動、API エラーの UI 反映
- 落とし穴：内部構造を考慮せず表面操作だけに留まる
5. 分析と継続的探索
探索的テストは 一度きりではありません。
アプリが変われば探索もやり直す必要があります。
マインドマップの活用
- 観点（監査、性能、セキュリティ、入力検証、UI、エラー処理）を整理し、チームに共有することで抜け漏れを防ぐ
フェーズごとの探索戦略
- Dev-box テスト：開発直後、正常系と UI 確認に限定
- ユーザーストーリーテスト：横断的観点やクロスブラウザを追加
- リリーステスト：パフォーマンス、信頼性、スケーラビリティを重点探索
6. 従来テストとの比較
| 項目 | 従来のテスト | 探索的テスト |
|---|---|---|
| 基準 | 要件・仕様書 | ユーザー操作や直感 |
| 特徴 | 再現性が高い | 新しい不具合を発見しやすい |
| 課題 | 想定外に弱い | 属人化しやすい |
| 解決策 | 網羅性を高める設計 | フレームワークと観点で構造化 |
7. 実務への落とし込み
チェックリスト
- 想定外のユーザーフローを探索したか
- エラーメッセージは意味があり解決策を示しているか
- フレームワークを活用して観点を広げたか
- ペルソナやドメイン知識を反映したか
- チームで観点を共有し、属人化を避けているか
- 継続的なフィードバックを前提としてテスト計画を立てたか
8. まとめ
- 探索的テストは「自由」ではなく「構造化」がカギ
- 8 つのフレームワーク・4 つの探索パス・5 つの着眼点で属人性を減らせる
- 継続的に計画して実施することで、アジャイル開発での品質フィードバックが強化できる
Discussion