エラー推測とは、過去の経験・バグのパターン・直感をもとに「バグが出やすそうな値や操作」を積極的にテストするテスト設計技法です。他の技法では見つけにくいバグを補完するため、QAエンジニアの実務経験が直接品質に反映される技法です。
💡 一言でいうと
エラー推測 ＝ 「「ここ、バグが出そう」という経験と直感をテストに変換する技法」
エラー推測は唯一「経験・直感・勘」に基づくテスト設計技法です。体系的な技法が見落としがちな「経験的に危ない値」を補完することで、テストスイート全体の品質を一段引き上げられます。
📌 この記事はこんな方におすすめ
- エラー推測の概念と実践的な使い方を学びたいQAエンジニア
- 同値分割・境界値分析だけでは足りないと感じている方
- テスト設計技法シリーズの最後の仕上げを知りたい方
- 自分の経験・勘をテストに体系的に活かしたい方
✅ この記事を読むと得られること
- エラー推測の概念と他の技法との違いがわかる
- 実務でよく使われる「バグが出やすい値」のパターンカタログがわかる
- エラー推測を他の技法と組み合わせる実務ワークフローがわかる
👤 この記事を書いた人
QAエンジニア・テスト自動化エンジニアとして15年以上の実務経験を持つ Yoshi が執筆。エラー推測は毎日のテスト設計で「他の技法の補完」として活用しており、経験が積み重なるほど精度が上がる技法です。実装コードはGitHubで公開中：github.com/YOSHITSUGU728/automated-testing-portfolio
同値分割・境界値分析・デシジョンテーブル・状態遷移テスト——これらをすべて適用してもまだ発見できないバグがあります。なぜでしょうか？
- 体系的な技法は「仕様書に書かれた条件」からテストケースを導き出す
- しかし「仕様書に書かれていない落とし穴」は体系的な技法では見つけにくい
- 「NULLを入れたらどうなる？」「空白文字だけ入力したら？」という経験的な問いかけが重要
エラー推測はこうした「経験則に基づく問いかけ」をテストケースに変換する技法です。この記事ではエラー推測の概念・実践的なバグパターンカタログ・他技法との組み合わせ方まで解説します。
📌 結論
- 「経験・直感・過去のバグパターン」をもとにテストケースを追加するテスト設計技法
- 他の6つの技法（同値分割・境界値・デシジョンテーブル等）を補完する最後の仕上げとして使う
- 経験が豊富なほど精度が上がる一方、チェックリスト化することで経験が少ないメンバーも活用できる
エラー推測とは？
エラー推測（Error Guessing）とは、「過去の経験・バグのパターン・直感をもとに、バグが発生しそうな値や操作を予測してテストケースを追加するテスト設計技法」です。
JSTQBでは「テスターの経験・直感・ヒューリスティクス（経験則）に基づく技法」として定義されています。他の技法が「仕様書の条件から論理的にテストケースを導き出す」のに対し、エラー推測は「ここが危ない気がする」という経験的な感覚を起点にします。
| 比較項目 | 体系的な技法（同値分割・境界値等） | エラー推測 |
|---|---|---|
| 起点 | 仕様書の条件・要件 | 経験・直感・過去のバグパターン |
| 網羅性 | 論理的に網羅できる | 網羅性の保証なし（補完的） |
| 再現性 | 誰がやっても同じ結果 | 経験者ほど精度が高い |
| 得意なバグ | 仕様に書かれた条件のバグ | 仕様外の落とし穴・実装の癖 |
エラー推測の実践：バグが出やすい値のカタログ
15年以上の実務経験から厳選した「バグが出やすい値・操作のパターン」をカテゴリ別にまとめます。これをチェックリストとして使うことで、経験が少ないメンバーもエラー推測を活用できます。
① 数値系のバグパターン
| 値 | なぜ危ないか | よくあるバグ例 |
|---|---|---|
| 0 | ゼロ除算・条件分岐の境目 | ZeroDivisionError・割引計算で0円になる |
| -1・負の数 | 符号なし整数型で意図しない大数になる | 在庫数に-1を入力すると4294967295になる |
| 最大値+1 | 整数オーバーフロー | int32の最大値2147483647の次が-2147483648になる |
| 小数・浮動小数点 | 浮動小数点の丸め誤差 | 0.1 + 0.2 = 0.30000000000000004 |
② 文字列系のバグパターン
| 値 | なぜ危ないか | よくあるバグ例 |
|---|---|---|
| 空文字（””） | NULL との混同・長さチェック漏れ | 空文字がDBに保存される・名前欄が空でOKになる |
| スペースのみ（” “） | 空文字と異なる扱いになる | 「入力あり」と判定されてバリデーションを通過する |
| 非常に長い文字列（1000文字以上） | バッファオーバーフロー・DB制約超過 | 500文字制限のフィールドに1000文字でエラーなし |
| 全角・半角混在 | 文字コード・長さ計算のズレ | 「あa」で2文字なのにバイト数で4になる |
| 改行・タブ文字 | CSV出力時の破損・表示崩れ | 改行含む文字列をCSVに出力すると行がずれる |
③ セキュリティ系のバグパターン
| 値 | なぜ危ないか | チェックポイント |
|---|---|---|
' OR '1'='1 | SQLインジェクション | ログインフォームで認証バイパスできないか |
<script>alert(1)</script> | XSS（クロスサイトスクリプティング） | 入力値がそのままHTMLに表示されないか |
../../../etc/passwd | パストラバーサル | ファイル名入力でディレクトリを遡れないか |
④ NULL・未定義系のバグパターン
| 値 | なぜ危ないか | よくあるバグ例 |
|---|---|---|
| NULL / None | NullPointerException・予期しない動作 | オプション項目にNULLが入ってソートでクラッシュ |
| 未選択状態 | デフォルト値の処理が不完全 | ドロップダウンを選択せずに送信するとエラー |
| 空配列・空リスト | ループ処理で0件の扱いが漏れる | 検索結果0件でページネーションがクラッシュ |
⑤ 日付・時刻系のバグパターン
| 値 | なぜ危ないか | よくあるバグ例 |
|---|---|---|
| 2月29日（うるう年） | うるう年の考慮漏れ | 「1年後」を計算すると翌年2月29日が存在せずクラッシュ |
| 月末日（28・29・30・31日） | 月ごとに日数が異なる | 「1か月後」が翌月に存在しない日付になる |
| タイムゾーン境界 | UTC変換のズレ | 日本時間23:00の予約がUTCで前日になる |
| 年末年始（12/31 → 1/1） | 年をまたぐ計算の漏れ | 週次レポートが12/31〜1/6でなく12/31のみになる |
エラー推測のチェックリスト：テスト前に確認すべき10の問い
テスト設計を終えた後、以下の問いかけをチェックリストとして使います。1つでも「テストしていない」と気づいたら、テストケースに追加しましょう。
✅ エラー推測チェックリスト
| 1 | 数値フィールドに 0・負の数・最大値+1 を入力したらどうなる？ |
| 2 | 文字列フィールドに 空文字・スペースのみ・1000文字以上 を入力したらどうなる？ |
| 3 | 必須フィールドに NULL・未入力・未選択 のまま送信したらどうなる？ |
| 4 | 同じ操作を 連続して2回・高速に 実行したらどうなる？（二重送信） |
| 5 | 日付フィールドに 2月29日・月末・年末年始 を入力したらどうなる？ |
| 6 | 文字列に シングルクォート・<script>タグ・SQLコメント を入力したらどうなる？ |
| 7 | リストや検索結果が 0件 のときにページネーションやソートはどうなる？ |
| 8 | ファイルアップロードに 空ファイル・極端に大きいファイル・不正な拡張子 を送ったらどうなる？ |
| 9 | ネットワーク切断・タイムアウト・サーバーエラーが 処理の途中 で起きたらどうなる？ |
| 10 | ブラウザの「戻る」ボタン・URLの直接入力・ブックマークからのアクセスはどうなる？ |
テスト設計技法シリーズの締め：エラー推測の位置づけ
テスト設計技法7選のシリーズを通じて、各技法の役割と組み合わせ方を整理します。
| 技法 | 役割 | タイミング |
|---|---|---|
| 同値分割 | 入力値の範囲をグループ化 | まず最初に実施 |
| 境界値分析 | グループの境界を重点テスト | 同値分割の直後 |
| デシジョンテーブル | 複数条件の組み合わせを整理 | 業務ロジックに |
| 状態遷移テスト | 状態と遷移の正しさを検証 | フロー系システムに |
| ユースケーステスト | ユーザー操作フロー全体を検証 | E2Eテスト設計に |
| ペアワイズテスト | 多数の組み合わせを効率化 | 環境設定・パラメータ組み合わせに |
| エラー推測 ←今ここ | 経験・直感で危ない値を補完 | すべての技法の最後に追加 |
🎯 実務ワークフロー
① 同値分割・境界値分析でベースのテストケースを設計
② 業務ロジックにデシジョンテーブルを適用
③ フロー系はユースケーステスト・状態遷移テストで補強
④ パラメータが多い場合はペアワイズで最適化
⑤ 最後にエラー推測チェックリストを回して「経験的に危ない値」を追加
⚠️ エラー推測でよくある失敗パターン4選
エラー推測を実務で使うときに陥りやすい失敗を紹介します。
① エラー推測だけで体系的な技法を省略する
「経験があるから同値分割とかやらなくていい」という判断は危険です。エラー推測は「補完する技法」であり、単独では網羅性が保証できません。体系的な技法でベースを作り、エラー推測で仕上げる順番を守りましょう。
② チームメンバーの経験に依存しすぎる
「あの先輩がやれば見つかるけど、自分にはわからない」という状態はチームのリスクです。エラー推測のバグパターンをチェックリスト化・ドキュメント化することで、経験が少ないメンバーも活用できるようになります。「個人の勘」を「チームの資産」に変えましょう。
③ セキュリティ系のエラー推測をQAが省略する
「セキュリティはセキュリティ専門家の仕事」と思ってSQLインジェクション・XSSのテストをQAが省略してしまうケースです。専門的なペネトレーションテストと異なり、基本的なパターン（シングルクォート・scriptタグ等）はQAエンジニアが普段のテストに組み込むべきです。
④ 「勘で追加した」テストケースの根拠を残さない
テストケースに「なぜこの値をテストするのか」の根拠コメントを書かないと、後から見たメンバーが「なぜこれが必要なの？」と削除してしまうことがあります。「経験上、空白文字のみの入力でバリデーションを通過したことがあるため」のように根拠を1行残しておきましょう。
FAQ
Q. エラー推測は経験がないメンバーには使えませんか？
使えます。この記事で紹介したバグパターンカタログ・チェックリストを活用することで、経験が少ないメンバーも「よくあるバグが出やすい値」を体系的にテストできます。最初はカタログをそのまま使い、バグを発見するたびにチームのカタログに追加していくことで精度が上がります。
Q. エラー推測とアドホックテストの違いは？
アドホックテストは計画なしに気の向くままにテストを行う手法です。エラー推測は過去の経験・バグパターンに基づいてテストケースを設計する手法です。アドホックテストより再現性・目的意識があり、チェックリスト化することでチームで共有できる点がエラー推測の優位性です。
Q. JSTQBでエラー推測はどの程度出題されますか？
JSTQB Foundation Levelでは「エラー推測の定義・他の技法との使い分け・経験・直感・ヒューリスティクスに基づく技法であること」が問われます。「エラー推測は補完的な技法であり、他の技法と組み合わせて使う」という位置づけを理解しておけば対応できます。
Q. エラー推測のバグパターンカタログはどう育てればいいですか？
「バグが発見されるたびにカタログに追加する」運用が最も効果的です。バグのポストモーテム（振り返り）で「このバグはエラー推測で事前に発見できたか？」を問いかけ、発見できなかった場合はカタログに追加します。GitHubのリポジトリやConfluenceなどのチームWikiで管理すると継続的に育てていけます。
📖 関連記事（テスト設計技法シリーズ）
実務では、テスト設計が完了した後にこの記事のチェックリストを1周するワークフローを採用しています。15年以上の経験から「このチェックリストを回したことで毎回1〜2個のバグが追加で発見される」という実感があります。特に「空白文字のみ」「二重送信」「月末日計算」は普遍的なバグパターンとして何度も助けられています。
📋 この記事のまとめ
- エラー推測は「経験・直感・過去のバグパターン」をテストケースに変換するテスト設計技法
- 他の6つの技法の最後の仕上げとして使い、体系的な技法では見落としがちな「経験的に危ない値」を補完する
- バグパターンカタログ・チェックリスト化することで経験が少ないメンバーも活用できる
- 「個人の勘」を「チームの資産」に変えることがエラー推測の本質的な価値
- テスト設計技法7選はすべて組み合わせて使うもの。エラー推測はその締めくくり
テスト設計技法7選のシリーズを通じて、QAエンジニアが実務で使う技法の全体像を学びました。同値分割・境界値から始まり、デシジョンテーブル・状態遷移テスト・ユースケーステスト・ペアワイズテスト、そして最後のエラー推測——これらを組み合わせることで、体系的かつ経験的な「強いテスト設計」が完成します。あとは実際のプロジェクトで使いながら、自分だけのバグパターンカタログを育てていきましょう。
