3.4 経験ベースのテスト技法 (Experience-Based Testing)

「経験ベースのテスト技法（Experience-Based Testing）」 は、テストアナリスト（TA）自身の専門知識、直感、および過去に遭遇したバグや障害の経験を活用してテストを導出するアプローチです。

仕様書などのドキュメントが不十分な場合や、時間的制約が厳しいプロジェクトにおいて特に有効であり、ブラックボックステスト技法を補完する形で使用されます。また、受け入れテスト駆動開発（ATDD）のようなコラボレーションベースのテストでも広く適用されます。

シラバス（v4.0）では、TAが実務で活用すべき「セッションベースドテスト」「チェックリストベースドテスト」、および外部リソースを活用する「クラウドテスティング」について詳しく解説しています。

1. セッションベースドテストを支援する「テストチャーター」

探索的テストを構造化し、管理しやすくする手法がセッションベースドテストです。このセッションに方向性を与えるための計画書・指示書が 「テストチャーター（Test Charter）」 です。

テストチャーターは、テストのスコープや目的を示すロードマップとして機能し、TAが特定の機能やリスクに集中しつつも、自由に探索できる柔軟性を提供します。

ミッションの定義フォーマット

テストチャーターの中核となる「ミッション」は、以下のような軽量フォーマットで記述されることが一般的です。

Explore [ターゲット: 探索する対象エリア、機能、リスク] With [リソース: 使用するテストデータ、ツール、制約] To discover [情報: 見つけたい欠陥の種類、品質評価]

テストチャーターに含まれる主な情報

ミッションに加えて、チャーターには以下のような情報が含まれます。

テストのスコープ: テスト対象領域、使用する技法、終了基準（逆に「テストしないこと」も明記します）。
過去の履歴情報: 過去に見つかった欠陥（互換性の問題など）や、過去の障害パターン。
制約とリスク: 遵守すべき法規制やルール、システムが「絶対にやってはいけないこと（制限事項）」。
セットアップ要件: テスト環境や、開始するための前提条件（開始基準）。

テストセッション中、TAは発見したバグや疑問点、次のテストアイデアなどを 「セッションシート」 に記録（ロギング）し、セッション終了後に報告します。チャーターの記述が詳細すぎるとTAの探索の自由度を奪ってしまいますが、逆に「絶対にやってはいけないこと」を明確にしておくことで、誤検知（フォールスポジティブ）の報告を減らす効果があります。

2. 経験ベースのテストを支援する「チェックリスト」

チェックリストベースドテストは、その適応性の高さとシンプルさから非常に広く使われている技法です。過去の失敗や経験を「チェックリスト」として記録しておくことで、重要な観点の見落としを防ぎ、複数のTA間でテスト品質のばらつき（一貫性）を保つことができます。

チェックリストの種類

リード・ドゥ (Read-do) チェックリスト: 特定のプロセスに対して「確認すべき具体的な要素」を記載したもの。（例：入力フィールドに対する具体的な無効値のリストなど）
ドゥ・コンファーム (Do-confirm) チェックリスト: TAの思考プロセスをガイドし、探索のヒントを与えるもの。（例：「検索結果はユーザーの意図に関連しているか？」といった問いかけ）

チェックリスト作成のステップ

TAが効果的なチェックリストを作成・維持するためには、以下のステップを踏むことが推奨されます。

スコープと目的の決定: テスト対象の深さや詳細度を決定します。
情報の収集: 熟練者からのヒアリング、欠陥ライブラリやバグタクソノミー（分類体系）の参照、過去のテストケースの分析から項目を洗い出します。
項目の定式化: 各項目は明確で曖昧さがなく、「はい」「いいえ」「該当なし」で答えられる質問形式にします。また、リスクレベルに基づいて優先順位を付けます。（※チェックリストは手取り足取り教えるマニュアルではなく、専門家のための簡潔なツールであるべきです）
構造化と整理: 項目数が多くなる場合は、機能エリアやユーザーロールごとに論理的にグループ分けします。
継続的なレビューと洗練: チェックリストは一度作って終わりではありません。新たなバグの発見や環境の変化に合わせて、常にアップデートし続ける必要があります。

3. クラウドテスティング (Crowd Testing)

クラウドテスティングは、社内外の多様なバックグラウンドを持つ多数のテスター（群衆）にテストを分散させるアプローチです。機能テストだけでなく、非機能テスト（特にユーザビリティテスト）の妥当性確認において費用対効果の高い方法として注目されています。

クラウドテスティングのメリット

多様なテスト環境: 世界中のテスターが、様々なデバイス、OS、ブラウザ、ネットワーク環境でテストを行うため、社内だけでは網羅しきれないカバレッジを確保できます。
実際のユーザー視点: テスターが実際のターゲットユーザー層と一致する場合、優れたユーザーエクスペリエンス（UX）や使用性に関するリアルな洞察を得られます。
迅速なフィードバックと柔軟性: 短期間に大量のテストを実行でき、スケールアップが容易です。

クラウドテスティングの課題と限界

テスト品質のばらつき: テスターのスキルに依存するため、報告されるバグの質が一定ではありません。
コミュニケーションの難しさ: タイムゾーンや言語、文化の異なる多数のテスターを調整・管理する労力がかかります。
セキュリティリスク: 外部のテスターにリリース前のソフトウェアを共有するため、機密情報の漏洩リスクに対する適切な対策（NDAなど）が必須です。
報告の管理: 大量の重複バグ報告や、誤検知（フォールスポジティブ）を整理するドキュメンテーションの負担が増加します。

クラウドテスティングは、TAによる専門的なテスト技法を「置き換える」ものではなく、多様な環境カバレッジやユーザーフィードバックを「補完・拡張する」ための手段として位置づけられます。