【ソフトウェア開発技術】経験者の勘でバグを狙い撃ち！「エラー推測」｜情報処理問題1000本ノック
ソフトウェアテストにおいて、規定のテストケースだけでは見抜けず見落としがちな不具合。テスト担当者の経験や過去の失敗事例から発生しそうなエラーを予見して検証する「エラー推測」の概念を攻略しましょう。
1. 【 問題 】：ソフトウェア開発技術（テスト設計技法）
【 問題 】 ソフトウェアテストの設計技法に関する記述です。標準的な仕様書に基づくテストケースの作成とは異なり、テスト担当者の経験、直感、過去の欠陥履歴などに基づいて「発生しそうなエラーやバグのパターン」をあらかじめ推測し、そのエラーが発生しないこと（正しく処理されること）を確認するテスト技法を何と呼ぶでしょうか？
（ア）エラー推測（Error Guessing）
（イ）境界値分析（Boundary Value Analysis）
（ウ）同値分割法（Equivalence Partitioning）
（エ）決定表テスト（Decision Table Testing）
2. 正解：
正解：（ア）エラー推測（Error Guessing）
3. 解説：「開発者がやらかしそうなポイント」をピンポイント攻撃
エラー推測（Error Guessing）は、公式なルールや仕様書の数式だけに頼らず、人間の経験則や過去のノウハウを活かす補完的なテスト技法です。
たとえば、「入力欄にゼロ（0）を入れたらゼロ除算エラーが起きないか」「絵文字や特殊文字を送信したら文字化けしないか」「通信が途切れた瞬間に送信ボタンを連打したら二重決済されないか」といった、仕様書には細かく書かれていないけれど『開発者が考慮漏れしそうな意地悪なシナリオ』を推測してテストを実行します。
| テスト技法 | テストケース生成の基準・根拠 |
|---|---|
| （ア）エラー推測 | 担当者の「経験・直感・過去の欠陥パターン」からエラーを想定する。 |
| （イ）境界値分析 | 仕様の「境界ギリギリの値（上限値、下限値、その前後）」を選ぶ。 |
| （ウ）同値分割法 | 入力範囲を「同じ挙動をするグループ」に分け、各グループの代表値を選ぶ。 |
| （エ）決定表テスト | 複雑な条件の組み合わせと動作結果を「デシジョンテーブル」に表して整理する。 |
1. 理解のコツ: 「熟練の防犯診断員（セキュリティ専門家）」に例えてみましょう。
・新築の家（システム）をチェックする際、図面（仕様書）通りに鍵がかかるかテストするのが「境界値分析」や「決定表」です。
・一方でエラー推測は、熟練の泥棒対策プロが「泥棒はだいたいこの低いフェンスから飛び越えようとするんだよな」「この窓の鍵は締め忘れやすいから試してみよう」と、過去の犯行パターン（バグの事例）から不備を言い当てる感覚です。体系的なテスト手法を補う「隠れたバグのハンター」として非常に有効です。
2. 試験対策の視点: ソフトウェア開発技術や品質管理の分野において、用語の定義を問う問題としてよく出題されます。
問題文の中に「経験」「直感」「過去の障害履歴」「エラーの発生を想定・推測」といったキーワードがあれば、即座にエラー推測（Error Guessing）を選択してください。
「誰がやっても同じ結果になる」形式的な技法（同値分割や境界値分析）と異なり、「テスト担当者のスキルや知見に依存する」という特徴・課題がある点もセットで理解しておくと完璧です。
4. まとめ
「担当者の経験や過去の障害パターンからエラーを予測し、ピンポイントで発生しないか確認する技法」。これがエラー推測です。境界値分析や同値分割法などの形式的な技法と組み合わせて使う『実践的なテスト手法』として記憶に定着させておきましょう！