経験ベースのテスト技法とは｜3分類と勘の再現手順

テストケース数は前回より増やしました。レビューも通しました。それでもリリース後、クライアントから「この操作をするとエラーになる」と連絡が届く。その操作は、テスト項目表のどこにも書かれていませんでした。

こうした経験を重ねると、ケースを増やす努力が頭打ちになると気づきます。増えているのは仕様書の確認漏れを防ぐケースだからです。

一方で、ベテランのテスターが短時間で重大なバグを引き当てる場面を見たことがあるかもしれません。あれは属人的なセンスではありません。経験ベースのテスト技法とは、テスト担当者の知識と経験を情報源にテストを設計する技法です。

ベテランの勘は、JSTQBが正式に技法として認めた再現可能なスキルです。訓練とドキュメント化によって、経験の浅いメンバーにも一定の水準まで移せます。

本記事では、3分類での位置づけ、エラー推測・探索的テスト・チェックリストベースドテストの実践手順、そして体制も予算も変えずに試せる最小単位の始め方をお伝えします。

テストケースを増やしても本番バグが減らないのはなぜか

ケース数は品質の代理指標にならない

「全1,200件のうち980件消化、不具合42件」。この数字が答えているのは「予定した作業がどれだけ進んだか」であって、「製品にどれだけ欠陥が残っているか」ではありません。

ケース数を増やすとある点から検出欠陥数の伸びが鈍ります。追加分の多くが確認済み領域の細分化だからです。見ていない場所の欠陥は、いくら細かく見直しても出てきません。

仕様書に書かれていない期待値は誰も検証していない

仕様書からケースを起こす作業は、記述をケースへ変換する作業です。だから書かれていない事柄はケースになりようがありません。問題になるのは、たいてい次のような領域です。

• 暗黙の期待値（明記されていないが、ユーザーが当然そう動くと思っている挙動）
• 異常系の網羅（通信断、二重送信、セッション切れ、想定外の入力）
• 操作順序の組み合わせ（画面Aで登録してから画面Bに戻り、ブラウザバックする、など）
• 既存機能との干渉（後から追加した機能が、古い機能の前提を壊す）

これらは仕様書に「書かれていない」ため、レビューでも検出されにくい性質があります。仕様書レビューが確認するのは、書かれた内容の正しさだからです。

仕様書から機械的に導出したテストケースは、原理的には仕様書に書かれた期待値までしか判定基準（オラクル）を持ちません。

「20の扉」で全問を事前に用意する非効率

Lee Copeland『はじめて学ぶソフトウェアのテスト技法』では、事前に設計を固めるテスト（スクリプトテスト）の限界が「20の扉」の比喩で説明されています。

「20の扉」は、Yes／Noで答えられる質問を20回だけ使って正解を当てるゲームです。回数に上限があるからこそ、前の答えを見てから次の質問を決めることが効きます。

20問を最初に全部作れば、前の回答を活かせません。テスト分析→設計→実行を順番どおりに進めるやり方が、まさにこれにあたるとJames Bachは指摘します。

スクリプトテストが抱える3つの難点

同書は、スクリプトテストの難点を次の3つに整理しています。

• 要件の品質に依存する：要件の品質が低ければ、そこから作ったテストの品質も低くなる
• 柔軟性に欠ける：事前に決めたシナリオに従うため、途中で見つけた興味深い現象を追跡できない
• テストスキルを低下させる：手順をなぞる作業が続くと、担当者が自分で考える機会を失う

2つ目は現場感覚として分かりやすいはずです。実行中に「今の表示、少しおかしくないか」と感じても、項目表の消化が優先されて次に進んでしまいます。

テスト設計を早い段階で固めるほど、後から得た理解をテストに反映できなくなります。

体制面から改善したい場合は、リリース後のバグを減らすテスト体制の作り方を確認すると全体像がつかみやすくなります。

経験ベースのテスト技法とは｜JSTQB3分類での位置づけ

テスト技法は大きく3つに分類される

テスト技法は、「何を拠り所にテストケースを導き出すか」によって3つに分類されます。この分類を押さえると、自社のテストがどこに偏っているかが分かります。

1つ目はブラックボックステスト技法（仕様ベース）、2つ目はホワイトボックステスト技法（構造ベース）、3つ目が経験ベースの技法です。多くの受託開発の現場では、1つ目に大きく偏っているのが実情ではないでしょうか。

分類	拠り所となる情報源	得意な欠陥	限界
ブラックボックス（仕様ベース）	仕様書・要件定義	仕様どおりに動かない機能欠陥	仕様書にない領域は対象外
ホワイトボックス（構造ベース）	ソースコード・内部構造	未実行パス・条件漏れ	実装が仕様と違う場合の妥当性は判定できない
経験ベース	担当者の知識・過去の欠陥経験	暗黙の期待値・異常系・想定外の操作	品質が担当者のスキルに左右される

分類の正確な記述は、JSTQBのシラバスでテスト技法の定義を確認することができます。前二者の守備範囲を先に整理したい方は、ホワイトボックスとブラックボックスの使い分けを整理すると、経験ベースの位置がより明確になります。

拠り所にするのは担当者の知識と経験

経験ベースの技法が情報源とするのは、過去の欠陥に関する知識、利用実態に関する知識、そして「この実装方式ならここが弱点になりやすい」という技術的な知識の3種類です。いずれも仕様書には書かれていません。

つまり経験ベースの技法とは、仕様書という単一の情報源への依存を意図的に外すための技法です。仕様書ベースが「書かれたことが正しく実装されているか」を問うのに対し、経験ベースは「書かれていないところで何が起きるか」を問います。両者は競合しません。

経験ベースに含まれる3つの代表的な技法

• エラー推測：起こりそうな欠陥を先に列挙し、そこを狙い撃ちする技法
• 探索的テスト：テストの設計と実行を同時並行で進め、結果から次のテストを決める技法
• チェックリストベースドテスト：過去の欠陥や観点を列挙したリストを拠り所にテストする技法

3つは排他的ではありません。エラー推測で作ったリストがチェックリストの原型になり、それを持って探索的テストに臨む、という形で連続しています。

技法全体の位置関係を広く押さえたい場合は、テスト設計技法の全体像を体系的に整理した解説を読むことをおすすめします。

エラー推測｜ベテランの「勘」の正体を3つに分解する

「ベテランは勘でバグを見つける」と言われますが、勘という一語で片づけると再現も継承もできません。実際には、少なくとも3つの能力が重なっています。

メカニズム1：過去の欠陥パターンが内在化している

1つ目は、過去に見た欠陥のパターンが頭の中に蓄積されていることです。日付処理でうるう年が抜ける、権限まわりで一段階下の権限に穴が空く、一覧の絞り込み条件がページ遷移で消える。

こうしたパターンは、システムの種類が違っても繰り返し現れます。実装者が変わっても同じ勘違いが同じ場所で起きるので、ベテランは初めて見るシステムでも当たりをつけられます。これは天賦の才ではなく、欠陥を言語化して覚えているかどうかの差です。

勘とは、過去の欠陥パターン・偏在の知識・暗黙の期待値の推測という3つの積み重ねです。

メカニズム2：欠陥が偏在する場所を経験的に知っている

2つ目は、壊れやすい場所を構造的に見抜く力です。JSTQBの「テストの7原則」の第5原則「欠陥の偏在（Defects cluster together）」は、欠陥が全体に均等に分布せず少数のモジュールに集中すると述べています。

ベテランが優先的に確認しにいくのは、次のような場所です。

• 分岐が多く、条件の組み合わせが爆発している処理
• リリース直前や後追いで追加された機能（設計の一貫性が崩れやすい）
• 境界（日付の月末月初、数値の上下限、文字数制限、権限の境目）
• 外部サービスやバッチとの連携部分（責任の境界があいまいになりやすい）
• 複数人で分担して実装した機能のつなぎ目

仕様書ベースの設計は「機能の数」に比例してケースを配分しがちです。均等配分をやめる根拠を与えるのが、経験という情報源です。

メカニズム3：仕様書に書かれない暗黙の期待値を推測できる

3つ目は、ユーザーの立場で「何をおかしいと感じるか」を想像する力です。仕様どおりに動いていても、不便や不安を覚えるなら報告すべき事象になります。

たとえば送信ボタンを二度押して何も起きないのは仕様どおりかもしれません。しかし利用者には「送信できたのか分からない」状態です。ここから二重登録の検証や、通信が遅い環境での挙動確認へ発想が広がります。異常系のケースは、誰かが想像しない限り存在しません。

エラー推測の実務手順と「攻撃」リストの作り方

手順は単純で、「起こりうる欠陥のリストを先に作り、そのリストを狙ってテストを設計する」という順番になります。

下敷きになるのが、James Whittaker『How to Break Software』の攻撃（アタック）という整理です。不具合のタイプと、それを引き出す操作をペアで記述する点に特徴があります。「フォールトアタック」はJSTQB旧シラバス由来の呼称で、以下は原著の攻撃リストに基づく整理です。

操作レベルで示されるため、経験の浅いメンバーでも着手点が持てます。ただし、どの攻撃を選ぶかの判断には別途レビューが要ります。

狙う欠陥タイプ	具体的な攻撃操作
エラー処理の不備	エラーメッセージを強制的に表示させる操作を試す
初期値の扱い	デフォルト値のまま固定して各機能を通す
入力処理の脆さ	入力バッファをオーバーフローさせる長さのデータを入れる
データ構造の想定違反	過少・過多な件数のデータを与える（0件、上限超え）
計算処理の限界	計算結果が過大・過小になる入力を与える

このリストを自社の製品向けに書き換えれば、次章のチェックリストの原型になります。

探索的テスト｜「手当たり次第」との決定的な違い

定義：設計と実行の同時並行的な学習

探索的テストは、Cem Kaner『Testing Computer Software』で提唱されました。Copelandの前掲書では、James Bachによる定義が紹介されています。

「探索的テストとは、テスト設計とテスト実行の同時並行的な学習行為である」

ポイントは「学習」です。実行のたびに理解が深まり、それが次のテストの設計に反映されます。

Bachは「次に行うテストがその前のテストの結果に何かしら依存するのであれば、ある程度の探索的テストを行っていると言える」とも述べています。次のテストを前の結果から決めているなら、すでに探索の要素が入っています。

「規律のない探索」と「規律ある探索」の違い

上司に「行き当たりばったりではないのか」と問われたときに答えるべきが、この区別です。ただし技法どうしの対立ではありません。

JSTQBの用語集では、アドホックテストは「テスト設計技法を用いず、非公式に、事前の期待結果の定義なしに行うテスト」と定義されます。「ずさん」「スキル不要」といった評価はここに含まれません。

Copelandが場当たり的テストを「ずさん・注意不十分・焦点不明確」と評したのは、規律を欠いた実践態様への評価であって定義ではありません。Bach自身も、テストを「完全にスクリプト化された状態」と「完全に探索的な状態」のあいだの連続体として捉えています。分けるべきは技法の名前ではなく、探索に規律があるかどうかです。

比較軸	規律のない探索	規律ある探索（セッションベースドテストマネジメント）
計画性	事前の狙いがない	対象と狙い（チャーター）を事前に決める
時間管理	区切りがない	セッション単位でタイムボックスを設定する
記録	残らない、または断片的	発見と気づきをその場で記録する
再現性	何をしたか説明できない	記録から操作と条件を再現できる
説明責任	成果を報告しづらい	実施時間・範囲・成果を数値で報告できる

高橋寿一『知識ゼロから学ぶソフトウェアテスト』の「あきらかにバグを見つける活動で、バグを見つけられる」という指摘も、この文脈で腑に落ちます。

探索を管理可能にする4点セット

探索を管理可能にする仕組みが、Jonathan BachとJames Bachが提唱したセッションベースドテストマネジメントです。実質は4点セットです。

• チャーター：この探索で何を、どういう狙いで見るのかを1枚に書いたもの
• タイムボックス：1セッションを60分程度に区切る。時間が来たら終える
• 記録：見つけた事象、試した操作、気づいた疑問をその場でメモする
• デブリーフィング：終了後10〜15分で「何を見たか」「何が未確認か」を共有する

4つ目のデブリーフィングが、後述する「終了後15分の振り返り」にあたります。未確認の範囲を言葉にしておけば、次のチャーターがそのまま決まります。この4点があれば、「本日はセッション3本、対象は決済まわり、事象8件、うち要調査3件」と進捗を報告できます。

探索的テストは自由な作業ではなく、時間と範囲を区切った規律ある活動です。

テストチャーターの記述例

チャーターはテキスト数行で十分です。

` 【対象】受注承認の差し戻し後の再申請フローのみ（一覧・検索・新規登録は対象外） 【狙い】再申請時に、ステータスと権限の整合が崩れないかを確認する 【使うデータ】差し戻し済み2件／権限は申請者・承認者・閲覧のみの3種 【事前準備】データ投入・環境設定は時間枠外（別途15分） 【時間枠】60分（45〜90分の範囲で調整可）／延長せず、残件は次セッションのチャーターに送る 【残すもの】発見事象の一覧、再現手順、判断に迷った点、追加で確認したい観点 `

対象を1フローまで絞り込めるかが分かれ目です。絞れなければ、まず偵察セッションから始めます。

探索の切り口を増やしたいときは、探索の切り口になるテスト観点の洗い出し方を確認すると、チャーターの「狙い」が書きやすくなります。原典に当たりたい方は、James Bachによる探索的テストの解説を読む（英語）のもおすすめです。

チェックリストベースドテスト｜経験をチームの資産に変える

チェックリストベースドテストとは

チェックリストベースドテストは、過去の欠陥・確認観点・リスクを列挙したリストを拠り所にテストを設計・実行する技法です。3つのなかで最も形式知化に向いています。

特徴は、テストケースより粒度が粗いことです。「取消後に再登録できるか」という観点レベルで書き、操作や入力値は実行者が決めます。細かすぎると硬直し、粗いと解釈がぶれます。

自社の欠陥分類（タキソノミー）を作る

チェックリストの原材料が、欠陥分類（タキソノミー）です。過去のバグ票を分類し、自社で繰り返し起きている欠陥タイプを抽出します。

CopelandはBinderの整理を引きながら、テストケースの作り方には2つのアプローチがあると述べています。要件・仕様からケースを作る非特定不具合モデルと、欠陥分類をベースに過去の欠陥と似たものを探せるようケースを作る特定不具合モデルです。後者が、チェックリストの考え方そのものです。

欠陥分類はテスト実行だけでなく、設計の方向性を決める材料、カバレッジ監査、開発プロセスの改善、新人の教育教材としても使えます。

大切なのは、既製の分類をそのまま使わないことです。Copelandが述べるとおり、「一番役に立つのは自分自身の分類、つまり自分で作成した分類である」からです。

他社の完璧なチェックリストより、自社の流出バグから作った不完全なリストのほうが機能します。

分類をチェックリストに落とす4ステップ

実際の作業は次の手順で進みます。半日程度で初版が作れる分量です。

ステップ	作業内容	アウトプット	所要目安
1. 集める	直近1〜2年のバグ票を集める（本番流出分を優先）	バグ票の一覧	60分
2. 分類する	入力検証／権限／状態遷移／データ整合／性能／表示で束ねる	分類済みの束	60分
3. 抽出する	件数の多い上位数タイプに絞る	頻出欠陥タイプ5〜7件	30分
4. 言語化する	「権限変更後に既存セッションの権限が更新されるか」など確認できる文に直す	観点リスト初版	60分

そのうえで、テスト設計時にリストを開くことを手順に組み込みます。ここが最も重要です。レビュー観点に「各項目への対応を説明したか」を加えるだけで運用に乗ります。

リストは育てるもの｜流出バグごとに追記する運用

完璧なリストを作ろうとすると着手できないまま終わります。10項目でも構いません。本番に流出したバグが出るたびに「事前に見つけるにはどんな観点が必要だったか」を1行で追記します。

この運用を続けると、リストは自社の弱点を映した資産になります。属人化を体系的に進めたい場合は、テスト業務の属人化を4層に分けて解消する方法を読むと、リスト化以外の打ち手も検討できます。

3つの技法の使い分けと工数配分の考え方

対立させず併用する｜道具箱の発想

経験ベースの技法を知ると、「スクリプトテストをやめるべきか」という二択に見えることがあります。しかしこれは不毛な問いです。

Copelandが引くRex Blackの言葉に、こうあります。「賢明なテスト担当者は、必要ならば自分の道具箱の中にある道具を何でも使う。ねじ回しとハンマーのどちらが優れているかといった議論は無用だ」

経験ベースの技法はスクリプトテストの置き換えではなく、その隙間を埋める補完手段です。

仕様書ベースのテストは証跡が残り、第三者が同じ手順を再現でき、クライアントへの説明にも使えます。この価値は失われません。

局面別の使い分け早見

• 仕様が安定している：スクリプトテストを主軸に、エラー推測で異常系を補う
• 仕様が不安定・変更が続く：探索的テストの比率を上げる。事前設計が無駄になりにくい
• 新規開発の機能：エラー推測＋探索的テスト。既知のパターンが効きやすい
• 既存機能の改修：チェックリストで影響範囲の観点を漏らさず拾う
• リグレッション：スクリプト化・自動化が向く。判断より反復が中心のため
• 時間が切迫している：探索的テストとチェックリスト

最後の項目には補足が要ります。探索的テストでも設計工数は消えず、設計は実行中に発生します。消えるのは設計成果物の作成と承認に費やす前倒しの工数で、着手までのリードタイムが短くなる代わりに、実行者のスキル依存度は上がります。

限られた工数をどう割り振るか

現実的な始め方は、既存のテスト工数の一部を探索に振り替えることです。全量をスクリプトテストに充てていたなら、数セッション分（1セッション60分）を探索に回します。

2回目以降は、投入工数あたりの検出欠陥数を物差しにできます。初回は分母も分子も未知なので使えません。2〜3回のリリースを経てから比率を調整すれば、説明も実データで行えます。

技法	向く局面	必要スキル	残る成果物	向かない局面
エラー推測	新規機能・異常系の補強	過去欠陥の知識	攻撃リスト・追加ケース	網羅性の証明が求められる場面
探索的テスト	仕様変更が続く／時間切迫	対象理解と設計スキル	セッション記録・発見事象	同一手順の反復実行が必要な場面
チェックリスト	改修・リグレッションの観点漏れ防止	自社欠陥の整理力	観点リスト	未経験の新技術領域

経験ベースのテスト技法を導入する手順と3つの落とし穴

最初の一歩は「1時間＋チャーター1枚」

体制変更も予算承認も新しいツールも要りません。既存のテスト工数から1時間を切り出すだけで始められます。

• 誰が：その機能に一番詳しい開発担当者以外のメンバー1名（作った本人は思い込みが働くため）
• いつ：テスト実行期間の中盤。ある程度動く状態になってから
• 何を：直近で改修が入った機能、または過去にバグが多かった機能を1つ
• 何を残すか：チャーター1枚と、発見事象のメモ

少人数の受託開発では、その機能を触っているのが実質1〜2名で「作った本人以外」を出せないこともあります。その場合は次で代替します。

• 他案件のメンバーと1時間だけ相互に交換し、互いのシステムを探索する
• 実装から1週間以上空けて本人が実施する（記憶の減衰を利用する）
• チャーターの「狙い」だけ別の人に書いてもらい、実行は本人が行う

上司への初回説明では、追加予算がゼロである点を前面に出してください。「既存のテスト工数の一部（60分×2セッション）を振り替える試行です。追加コストは発生せず、効果は検出件数と流出バグ件数で次回報告します」と伝えれば、承認の論点が費用対効果から実験の可否へ移ります。

終了後15分だけ振り返り、見つけた事象を観点リストに1〜2行追記すれば1サイクルです。

落とし穴1：偵察を飛ばしていきなり欠陥を探す

最も多い失敗が、対象の構造を掴まないまま欠陥探しを始めることです。弊社が支援したテスト代行の案件でも、開始時に全体像を把握しきれておらず、本来1回で確認できることに何度も画面を行き来し、余計な時間を費やしました。

有効なのは、セッションを2種類に分けることです。

• 偵察セッション：対象の構造・データの流れ・業務上の位置づけを掴むのが目的。欠陥検出の件数を成果指標にしない
• 欠陥探索セッション：偵察で得た理解をもとに、狙いを定めて欠陥を探す

対象への理解が浅いうちは、欠陥を数えるより構造を掴むことをセッションの目的にします。

偵察セッションの長さは対象規模で決めます。画面数が10前後なら30分、20を超えるなら60分が目安です。外部委託では開発の経緯や裏仕様が自然に伝わらないため、この説明時間も同じ枠で確保します。

落とし穴2：記録を残さず「見つけた／見つけない」で終わる

2つ目は、記録を残さないことです。結果が担当者の頭の中だけに残ると、次のリリースでも同じ人が同じ探索を繰り返し、属人化を強化します。

新しいツールは要りません。テスト項目表と同じブックに「探索セッション」シートを1枚追加し、日付・対象・チャーター・事象・追加観点の5列で運用すれば十分です。

検出ゼロのセッションも成果です。対象範囲を規律をもって確認した記録が残り、そのエリアのリスク評価を「未確認」から「確認済み」に更新できるからです。次回どこに時間を寄せるかの判断材料になります。

落とし穴3：優先順位づけをせずに列挙で終える

3つ目は、観点を列挙した時点で「設計が終わった」と考えることです。列挙は材料集めにすぎず、重要度・リスク・確認のしやすさの3軸で順位をつけて初めて設計になります。

導入初回は、次のチェックリストをそのまま使ってください。

• 対象範囲を1機能・1フローに絞り、偵察セッションを先に置く
• チャーターを1枚書き、60分で区切って延長しない
• 事象・気になった挙動をその場で記録する
• 終了後10〜15分でデブリーフィングし、観点リストへ追記する

経験ベースのテスト技法に関するよくある質問

経験ベースのテスト技法とは何ですか

経験ベースの技法とは、担当者の知識と経験を情報源にテストを設計する技法の総称です。仕様書やソースコードではなく、過去の欠陥・利用実態・技術的な弱点の知識を拠り所にします。エラー推測、探索的テスト、チェックリストベースドテストが代表例です。

探索的テストとアドホックテストの違いは何ですか

探索的テストは狙い・時間枠・記録を定めて行う探索であり、アドホックテストは技法を用いず非公式に行うテストです。両者は別物ではなく、規律の量による連続体と捉えるのが正確です。次の3点を入れれば、同じ活動が説明可能な作業に変わります。

• チャーター（対象と狙い）を事前に決める
• タイムボックスで時間を区切る
• 発見と気づきをその場で記録する

エラー推測は経験の浅いメンバーでもできますか

攻撃リストという形で先人の経験を借りれば、経験の浅いメンバーでも着手点を持てます。ただし、どの攻撃を優先するかの判断には経験が要るため、選定結果は経験者がレビューしてください。

JSTQBの3分類ではどこに位置づけられますか

JSTQBのテスト技法は仕様ベース・構造ベース・経験ベースの3つに分類され、その3つ目にあたります。ブラックボックス技法やホワイトボックス技法と並列に置かれた正式な技法群です。

まとめ｜勘を仕組みに変えるために

• 3分類での位置づけ：技法は仕様ベース・構造ベース・経験ベースに分かれ、経験ベースは担当者の知識と経験を情報源とする正式な技法群です
• 勘の3メカニズム：欠陥パターンの蓄積・偏在する場所の知識・暗黙の期待値の推測に分解できます
• 規律の有無が分かれ目：チャーター・タイムボックス・記録・デブリーフィングの4点が、説明可能な探索を成立させます
• 形式知化の手順：バグ票を分類し、頻出タイプを観点に言語化し、テスト設計の必須参照に組み込みます
• 最小単位の始め方：1時間のタイムボックスとチャーター1枚で、体制も予算も変えずに試せます

ケース数を増やす努力には限界があります。その外側に手を伸ばす道具が、経験を情報源とする技法群です。属人的なセンスではなく、分解し、言語化し、リストにできるスキルだと捉えてください。

まずは次のリリースで、60分のセッションを1本だけ実施してみてください。そこで見つかった事象が、観点リストの1行目になります。

テスト体制の見直しや、経験を情報源とした技法をチームに定着させる進め方を検討されている方は、テスト体制の見直しについて相談することをご検討ください。お気軽にご相談いただけます。