バグ・欠陥・故障・エラーの違いとは？ソフトウェアテストの用語を整理

2026 8/08

2026年8月8日

開発やテストの現場では「バグが出た」「不具合が発生した」「障害報告を上げて」といった言葉が日常的に飛び交います。ところが、いざ「バグと欠陥はどう違うのか」「エラーと故障は同じものか」と問われると、明確に答えられる人は多くありません。用語の定義が曖昧なままだと、原因の切り分けが曖昧になり、再発防止も的外れになります。

ソフトウェアテストの国際的な資格認定体系であるISTQB（日本組織はJSTQB）では、これらの用語は明確に区別されています。本記事では「エラー」「欠陥」「故障」という3つの中核用語を整理したうえで、現場語との対応関係、欠陥が生まれる原因、欠陥管理の実務、品質を測る指標までを解説します。

バグ・欠陥・故障・エラーの違いを一覧で把握する

まず全体像を押さえておきましょう。JSTQB／ISTQBの用語体系では、3つの用語が「原因 → 結果 → 現象」という一本の因果関係でつながっています。

用語	英語表記	何を指すか	存在する場所	観測できるタイミング
エラー（誤り）	Error / Mistake	人間が犯す間違いそのもの	人間の頭の中・行為	直接は観測できない
欠陥	Defect / Fault / Bug	エラーの結果として成果物に埋め込まれた不備	コード・仕様書・設計書などの成果物	レビューや静的解析、テスト結果からの追跡で判明
故障	Failure	欠陥が実行され、期待どおりに動作しない事象	実行中のシステムの振る舞い	実行時（テスト中・運用中）

ポイントは「エラーは人に、欠陥はモノに、故障は振る舞いに存在する」という置き場所の違いです。この一点さえ押さえておけば、混乱の大半は解消します。以降でそれぞれを詳しく見ていきます。

エラー（Error）とは — 人間が犯す間違い

エラーとは、人間が犯す間違いそのものです。JSTQBの用語集では「誤った結果を生み出す人間の行為」と定義されています。日本語では「誤り」と訳されることもあり、Mistake（間違い）という語が併記されることもあります。

重要なのは、エラーはソフトウェアの中には存在しないという点です。エラーは人の認知や判断の中で起きる出来事であり、それが成果物に書き込まれて初めて形を持ちます。

エラーの具体例

要件定義書の「以上」「未満」を読み違えた（仕様の誤解）
境界値の扱いについて、開発者と企画担当者で認識がずれていた
設計時に例外パターンの存在を思いつかなかった（考慮漏れ）
タイムゾーンの扱いを勘違いしたまま設計した（知識不足）
納期が迫っていたため、影響範囲の確認を省略した（プレッシャー下の判断ミス）

注意したいのは、エラーの原因が「その人の能力不足」だけではないことです。仕様書の記述が曖昧、レビュー時間が確保されていない、情報が届いていないといった組織的・環境的な要因がエラーを誘発するケースは非常に多くあります。エラーを個人の責任に帰着させる文化は報告の隠蔽を招き、かえって品質を悪化させます。

欠陥（Defect）とは — 成果物に埋め込まれた不備

欠陥とは、エラーの結果として成果物の中に埋め込まれた不備です。JSTQBでは「要求された機能をコンポーネントやシステムが実行することを妨げる可能性のある不備」と定義されています。英語ではDefectのほか、Faultという語も同義で使われます。そして日常的には、この欠陥のことを「バグ」と呼んでいるケースがほとんどです。

欠陥はコードの中だけにあるわけではない

「バグ＝プログラムの誤り」というイメージが強いため見落とされがちですが、欠陥はコード以外の成果物にも存在します。要件定義書、設計書、テスト設計書、ユーザーマニュアルにも欠陥は入り込みます。

欠陥が存在しうる成果物	欠陥の例	主な検出手段
要件定義書	要件同士が矛盾している／必要な要件が記載されていない	レビュー、ウォークスルー
基本設計・詳細設計書	異常系の処理フローが定義されていない	インスペクション、設計レビュー
ソースコード	境界条件の判定式が誤っている／NULLチェック漏れ	静的解析、単体テスト、コードレビュー
設定ファイル・環境定義	本番環境のパラメータ値が誤っている	構成レビュー、環境テスト
テスト設計書・マニュアル	期待結果の記述が誤っている／実装と異なる操作手順が書かれている	テストケースレビュー、ドキュメントレビュー

成果物に埋め込まれた欠陥をコードになる前に見つける活動が、レビューやインスペクションです。詳しくはレビューとインスペクションによる品質向上で解説していますが、実行を伴わずに欠陥を検出できるという意味で、テストとは補完関係にあります。

なお、DefectとFaultはほぼ同義ですが、Faultは信頼性工学の文脈で「故障を引き起こす直接原因となるシステム内部の状態」を指す傾向があります。標準ごとに微妙な差異があるため、どちらが正しいかを突き詰めるより、自組織でどの語をどの意味で使うか決めるほうが実務的です。

故障（Failure）とは — 実行時に現れる事象

故障とは、欠陥を含むコードが実行された結果、システムが期待どおりに動作しない事象です。JSTQBでは「コンポーネントやシステムが期待した結果と異なる動作をすること」と定義されています。

故障は「振る舞い」であって「モノ」ではないため、故障そのものは直せません。直せるのは欠陥のほうです。「故障を修正する」は厳密には正しくなく、「故障の原因となった欠陥を修正する」が正確な表現になります。

故障の具体例

金額を入力して確定ボタンを押すと、画面がエラーメッセージなしで固まる
本来は登録できないはずの日付が受け付けられてしまう
帳票の合計金額が1円ずれる
バッチ処理が異常終了し、翌日のデータが更新されない

いずれも「実行して初めてわかる」性質を持ちます。つまりテスト実行で直接見つかるのは故障であり、欠陥は故障を手がかりに追跡して特定するという関係になります。

「エラー → 欠陥 → 故障」という因果の連鎖

3つの用語は、時間軸に沿った一本の連鎖として理解するのが最も実用的です。具体例で追ってみましょう。

段階	用語	起きていること（例：年齢18歳以上を会員登録可とする仕様）	誰が関与するか
1	エラー（Error）	設計者が「18歳以上」を「18歳より上」と読み違えた	人間（設計者）
2	欠陥（Defect）	詳細設計書に「age > 18」と記載され、コードにも同じ条件式が実装された	成果物（設計書・コード）
3	故障（Failure）	18歳のユーザーが会員登録しようとすると「登録できません」と表示される	実行中のシステム
4	影響（Impact）	18歳の新規会員を取りこぼし、問い合わせが増加する	ユーザー・ビジネス

この連鎖を意識すると、対策の打ち方が変わります。故障だけを見て「条件式を直した」で終わらせると再発します。「なぜ読み違えが起きたのか」（＝エラーの発生要因）まで遡って初めて、仕様書の記述ルールを改める、境界値のレビュー観点を追加するといった本質的な再発防止につながります。

欠陥があっても故障するとは限らない

連鎖を理解するうえで極めて重要なのが、「欠陥は存在するだけでは故障を起こさない」という事実です。欠陥を含むコードが実行され、かつ特定の条件が揃って初めて故障として表面化します。

先ほどの例なら、テストデータに18歳のケースが1件もなければ、欠陥はあるのにテストは全件パスします。これが「潜在欠陥」であり、リリース後に条件が揃った瞬間に故障として噴き出します。

だからこそ、実行経路をどれだけ通したかを測るカバレッジの考え方が重要になります。命令網羅・分岐網羅・条件網羅の違いについてはC0・C1・C2カバレッジの違いと使い分けで詳しく整理しています。ただしカバレッジ100%でも、通した経路のデータが不十分なら欠陥は見逃されます。カバレッジは「見逃しの上限を下げる指標」であって、「欠陥がないことの証明」ではありません。

故障の原因が欠陥とは限らない

逆方向の非対称性もあります。故障が観測されたからといって、必ずしもソフトウェアに欠陥があるとは限りません。JSTQBでも、以下のような外部要因による故障の存在が指摘されています。

ハードウェアの故障（メモリ不良、ディスク障害）
ネットワークの断絶やパケットロス
環境条件（想定外の負荷、ディスク容量の枯渇、時刻同期のずれ）
テスト環境固有の設定ミス（アプリケーションではなく環境側の問題）
テストケース自体の誤り（期待結果が間違っている）

この非対称性があるため、テスト現場では「まず観測された事象を記録し、原因が欠陥かどうかは調査後に判定する」という運用が必要になります。この「原因未確定の観測事象」を指す言葉が、次に説明するインシデントです。

「バグ」「不具合」「障害」「インシデント」との対応関係

実際の現場では、より多様な言葉が使われています。それぞれが標準用語のどれに対応するのかを整理しておきましょう。

現場で使われる語	標準用語での対応	実際のニュアンス	使うときの注意
バグ	欠陥（Defect）	最も広く使われる語。厳密には欠陥だが、故障を指して使われることも多い	「バグが出た」は故障、「バグを直した」は欠陥を指しているケースが多い
不具合	故障（Failure）に近い	「期待どおりでない状態」全般を指す日本語。原因を特定していない段階でも使える	範囲が広いため、原因の所在が伝わらない
障害	故障（Failure）＋業務影響	運用フェーズで、業務やサービスが止まった／影響が出たときに使われる	「障害」は影響度の大きさを含意することが多い
インシデント	Incident（原因未確定の観測事象）	「調査が必要な出来事」。欠陥に起因するかはこの時点では未確定	ITILの「インシデント」とは意味が異なるため文脈に注意
フォールト	欠陥（Fault）	Defectとほぼ同義。信頼性工学の文脈で使われやすい	組織内で用語を統一しておく
エラー	本来はError（人の誤り）	実際には「エラー画面」「エラーログ」など、システムの出力を指して使われる	最も誤用されやすい語。文脈で意味が真逆になる
デグレ／リグレッション	欠陥の一種（既存機能の劣化）	修正や機能追加によって、以前は動いていた機能が動かなくなること	原因は新規欠陥の混入であり、区分ではなく発生パターンの呼称

「エラー」が最も混乱を招く

表の中でとくに厄介なのが「エラー」です。標準用語では人間の誤りを指しますが、現場で「エラーが出た」と言うときの「エラー」は、システムが出力したエラーメッセージ、すなわち故障の一形態を指しています。つまり同じ単語が、文脈によって連鎖の両端（原因側と結果側）のどちらも指してしまうのです。

議論が噛み合わないときは、たいていこの語の意味がずれています。「今のエラーは人の誤りのほうか、画面に出た表示のほうか」と確認するだけで話が整理されることは少なくありません。

現場では厳密に使い分けられていない、という現実

正直に言えば、日本のソフトウェア開発現場の大半では、これらの用語は厳密に使い分けられていません。「バグ票」に故障の現象が書かれ、「障害管理表」に現象と原因が混在している、というのが実態です。

これは必ずしも悪いことではありません。日常会話まで標準用語で統一すると、コミュニケーションのコストのほうが高くつきます。重要なのは、「どこで厳密さが必要になるか」を見極めることです。

場面	厳密さの必要度	理由
チーム内の日常会話	低い	文脈で伝わるため、言い換えのコストのほうが大きい
バグ票・欠陥管理システムへの記録	高い	「現象」と「原因」を分けて書かないと、集計も分析もできなくなる
根本原因分析（RCA）・振り返り	非常に高い	エラーまで遡らないと再発防止策が的外れになる
顧客・発注者への報告、契約・検収文書	非常に高い	「障害」か「仕様どおり」かで責任の所在が変わる
品質メトリクスの算出	非常に高い	数える対象が揺れると、指標そのものが意味を失う

とくに品質メトリクスの算出は要注意です。「バグ件数」を数えるとき、故障の観測件数を数えているのか、修正した欠陥の件数を数えているのかで、数値は大きく変わります。1つの欠陥が5つの故障として観測されることもあれば、5つの欠陥が1つの故障として現れることもあるためです。

欠陥はなぜ生まれるのか

欠陥の直接的な原因はエラー、つまり人間の誤りです。しかし「人間だからミスをする」で止めては改善につながりません。エラーを誘発する構造的な要因を分解して捉える必要があります。

要因のカテゴリ	具体的な状況	打てる手
要求の曖昧さ	仕様書に「適切に処理する」など解釈の幅がある記述がある	受入基準を数値・条件で書く、具体例を併記する
コミュニケーション不足	仕様変更が実装担当まで届いていない	変更履歴の一元管理、変更時の影響範囲レビュー
時間的プレッシャー	納期直前の駆け込み修正で確認を省略する	修正時の必須確認項目をチェックリスト化する
複雑性	条件分岐が入れ子になり、全パターンを人が把握できない	リファクタリング、デシジョンテーブルによる整理
技術・ドメイン知識の不足	並行処理や文字コード、税制などの前提知識が足りない／新規フレームワークの想定外の挙動を踏む	ペアレビュー、有識者チェックポイントの設置、プロトタイプによる事前検証
環境・構成の差異	開発環境と本番環境の設定が異なる	構成管理の自動化、環境差分の明示的な管理

上流工程で作り込まれた欠陥ほど、修正コストが跳ね上がる

ソフトウェア工学の分野では古くから、欠陥は発見が遅れるほど修正コストが増大することが繰り返し指摘されてきました。バリー・ベームの研究をはじめとする複数の調査で、この傾向は一貫して報告されています。

欠陥を発見した工程	修正コストの目安（要件定義時を1とした相対比）	修正時に必要となる作業
要件定義	1	ドキュメントの修正のみ
設計	3〜6倍	設計書の修正＋関連設計への波及確認
実装（コーディング）	10倍程度	コード修正＋設計書との整合確認
結合・システムテスト	15〜40倍	修正＋再テスト＋リグレッションテスト＋関連ドキュメント更新
受入テスト	30〜70倍	上記＋スケジュール調整＋関係者への説明
運用（リリース後）	100倍以上	上記＋緊急対応＋データ復旧＋顧客対応＋信用の毀損

この倍率は調査対象や開発手法によって幅があり、そのまま自組織に当てはまる数値ではありません。ただし「後になるほど指数関数的に高くつく」という傾向自体は、開発手法を問わず成立します。本番稼働後のデータ不整合の復旧コストが、要件定義時の一行の修正と比較にならないことは変わりません。

この事実こそが、上流での品質確保を重視するVモデルの発想の根拠になっています。開発工程とテスト工程の対応関係については、Vモデルの基礎と実務での活用で詳しく解説しています。

欠陥の「作り込み工程」と「検出工程」のギャップ

欠陥管理で最も見落とされやすい観点が、欠陥が作り込まれた工程と、実際に検出された工程のずれです。可視化すると、プロセスのどこが弱いのかが浮かび上がります。

作り込み工程	本来検出すべき工程	実際に多く検出されがちな工程	ギャップが示す課題
要件定義	要件レビュー	受入テスト・運用	要件レビューが形骸化している／受入基準が不明確
基本設計	設計レビュー	システムテスト	設計レビューの観点が網羅されていない
詳細設計	設計レビュー・単体テスト設計	結合テスト	インターフェース仕様の詰めが甘い
実装	コードレビュー・単体テスト	結合テスト・システムテスト	単体テストのカバレッジや観点が不足している
テスト設計	テストケースレビュー	テスト実行中（期待結果の誤りとして発覚）	テスト設計のレビュープロセスが存在しない

たとえば「要件定義で作り込まれた欠陥が受入テストで大量に見つかる」なら、テストの精度ではなく要件レビューの仕組みそのものに問題があります。テストを厚くしても解決しません。

逆に「実装で作り込まれた欠陥がシステムテストまで残っている」なら、単体テストやコードレビューの強化が効きます。欠陥データは「品質の成績表」ではなく「プロセス改善の地図」として使うべきものです。

修正が新たな欠陥を生むという問題

欠陥を修正する行為そのものも、新たなエラーを引き起こしうる人間の作業です。修正の影響範囲が広いほど、新たな欠陥を混入させる確率は上がります。

そのため、欠陥修正後には修正箇所の確認テスト（再テスト）に加えて、既存機能が壊れていないかを確認するリグレッションテストが必須になります。修正のたびに全件を再実行するのが現実的でない場合は、まず主要機能が最低限動作するかを短時間で確認するスモークテストを挟み、その先で影響範囲に応じた選択的なリグレッションテストを実施する、という二段構えが有効です。

欠陥管理の実務 — バグ票の書き方

用語の区別が最も実利をもたらすのが、欠陥の記録、いわゆる「バグ票」です。ここで現象（故障）と原因（欠陥）を混ぜて書くと、後からの分析ができなくなります。

バグ票に書くべき項目

項目	内容	対応する概念	記入のポイント
ID・起票日・起票者	一意の識別子と記録情報	管理情報	自動採番にして重複を防ぐ
タイトル	1行で現象がわかる要約	故障	「〜すると〜になる」の形式にすると検索しやすい
発生環境	OS、ブラウザ、バージョン、環境名、データ条件	前提条件	環境起因かアプリ起因かの切り分けに必須
再現手順	誰がやっても同じ結果になる操作手順	故障の再現条件	番号付きで、初期状態から書く。再現性（3回中3回など）も併記する
期待結果	本来どうあるべきか	仕様	根拠となる仕様書の該当箇所を明記する
実際の結果	実際に何が起きたか	故障	スクリーンショット・ログを添付する
重要度（Severity）	システムへの影響の大きさ	故障の影響	テスト担当者が客観的に判定する
優先度（Priority）	修正の順番	意思決定	開発リーダー・PMが判断する
原因	調査後に判明した欠陥の内容と所在	欠陥	起票時は空欄。調査後に埋める
混入工程	どの工程で作り込まれたか	エラーの発生点	プロセス改善のための必須項目
修正内容	何をどう直したか	欠陥の除去	修正の影響範囲も併記する
確認結果	再テストとリグレッションテストの結果	検証	誰がいつ確認したかを残す

注目してほしいのは、「実際の結果」と「原因」が別の欄になっている点です。起票時点で書けるのは故障（現象）だけであり、欠陥（原因）は調査を経て確定します。1つの欄にまとめると、原因未確定の推測が事実として扱われる事故が起こります。

再現手順は「誰がやっても同じ結果になる」まで書く

再現手順の品質は修正までのリードタイムを直接左右します。開発者が再現できなければ調査は始まりません。

悪い例：「注文画面でエラーになる」

これでは、どの状態でどの操作をしたら何が起きたのかがわかりません。良い書き方は次のようになります。

会員ID「test001」でログインする（初期状態：カート内は空）
商品一覧から商品コード「A-1002」を選び、数量に「100」を入力してカートに追加する
カート画面で「注文手続きへ」をクリックする
配送先に既定の住所を選択し、支払い方法で「代金引換」を選ぶ
「注文を確定する」をクリックする
期待結果：注文完了画面が表示され、注文番号が採番される
実際の結果：白画面のまま10秒経過し、「システムエラーが発生しました」と表示される（3回中3回再現。数量を99にすると再現しない）

特に価値を持つのが最後の「数量を99にすると再現しない」です。再現する条件と再現しない条件を対で示すことで、開発者は欠陥の所在を一気に絞り込めます。これは単なる親切ではなく、テスト担当者が持つべき分析スキルです。

優先度（Priority）と重要度（Severity）は別物

欠陥管理で最も混同されるのが、優先度と重要度です。重要度は「事象の影響の大きさ」、優先度は「修正する順番」であり、判断する軸も判断する人も異なります。

観点	重要度（Severity）	優先度（Priority）
何を評価するか	システムや業務への影響の大きさ	いつ修正すべきかという緊急度
判断する人	テスト担当者（客観的に判定）	開発リーダー・PM・プロダクトオーナー
判断の軸	技術的・機能的な影響範囲	ビジネス上の価値、リリース計画、修正コスト
変動するか	基本的に変わらない	状況によって変わる（リリース直前に上がるなど）

2軸は独立しているため4つの組み合わせが生まれます。典型例を押さえておくと判断がぶれにくくなります。

組み合わせ	典型例	対応方針
重要度高／優先度高	決済処理が失敗し、金額が二重に引き落とされる	最優先で即時修正。リリース停止判断も検討
重要度高／優先度低	数年に一度しか使わない管理画面の機能がクラッシュする	影響は大きいが発生頻度が低い。次期リリースで対応
重要度低／優先度高	トップページの会社名の表記が誤っている	機能影響はないが、信用に関わるため即修正
重要度低／優先度低	設定画面の項目の並び順が設計書と異なる	バックログに積み、余裕のあるタイミングで対応

「重要度低／優先度高」の存在が、2軸を分ける最大の理由です。1軸だけで管理していると、技術的影響は小さいがビジネス上は最優先という欠陥が「軽微」として埋もれてしまいます。

欠陥のライフサイクル

欠陥は起票から収束まで、いくつかの状態を遷移します。ステータスの定義を組織で統一しておくと、進捗の把握が容易になります。

新規（New）：起票直後。内容の妥当性は未確認
受理（Open）／却下（Rejected）：仕様どおりの動作、重複、再現不可などは却下
調査中（Analyzing）：原因となる欠陥を特定している段階
修正中（In Progress）／修正済（Fixed）：欠陥の除去作業中、または確認待ち
確認済（Verified）／クローズ（Closed）：再テストとリグレッションテストで確認し、対応完了
保留（Deferred）：今回のリリースでは対応せず、次期に持ち越すと合意した状態

実務上のポイントは、「却下」と「保留」を正しく使い分けることです。対応する余裕がないという理由で却下すると、既知の欠陥がリリース後に見えなくなります。判断としての持ち越しは、必ず「保留」として記録に残すべきです。

欠陥を数値で捉える指標

用語を正しく区別できるようになると、欠陥を定量的に扱えるようになります。代表的な指標を整理します。

指標	計算式	何がわかるか	使うときの注意
欠陥密度	検出欠陥数 ÷ 規模（KLOC、ファンクションポイントなど）	規模あたりの品質水準。モジュール間の比較に使える	規模の測り方を統一しないと比較にならない
欠陥除去率（DRE）	該当工程で検出した欠陥数 ÷（該当工程で検出＋後工程に流出した欠陥数）	各工程のフィルターとしての性能	流出欠陥が確定するまで算出できない
欠陥検出率	単位時間・単位工数あたりの検出欠陥数	テスト活動の効率	高ければ良いわけではない（品質が低いだけの可能性）
欠陥流出率	後工程・運用で発見された欠陥数 ÷ 総欠陥数	テストプロセス全体の抜け	運用での発見件数の把握が前提
欠陥収束曲線	累積検出欠陥数の時系列推移	テストの収束具合。リリース判断の材料	テスト消化率とセットで見ないと誤読する
修正リードタイム	起票からクローズまでの平均日数	欠陥対応プロセスの詰まり	重要度別に分けて見る
再オープン率	修正確認後に再発した欠陥数 ÷ 修正欠陥数	修正品質、原因分析の深さ	高い場合は対症療法的な修正を疑う

指標を使うときの落とし穴

ただし指標は、扱い方を誤ると逆効果になります。

件数だけで品質を判断しない：検出欠陥数が少ないのは、品質が高いからかもしれませんし、テストが甘いからかもしれません。単独では解釈できません
数える対象を統一する：故障の観測件数と修正した欠陥の件数を混ぜて数えると、数値の意味が失われます
個人評価や目標値に使わない：欠陥数を評価に結びつけたり「欠陥密度を◯以下にする」と目標化したりすると、起票の抑制という形で容易に達成されてしまいます
欠陥の偏在を前提にする：欠陥は特定のモジュールに集中する傾向があります（欠陥の偏在／クラスタリング）。全体の平均値だけを見ると、この集中を見逃します

最後の「欠陥の偏在」は、ISTQBのテストの7原則にも挙げられる重要な性質です。集中しているモジュールを特定できれば、テスト資源をそこに重点配分できます。どのテストレベル・テストタイプで検証するかを設計する際は、ソフトウェアテストの種類一覧で全体像を確認したうえで選択するのが効率的です。

欠陥の検出を第三者視点で強化したい場合

ここまで見てきたとおり、欠陥は「人間のエラー」から生まれます。そして人間には、自分が書いたものの誤りに気づきにくいという認知的な性質があります。設計者が自分の設計をレビューし、実装者が自分のコードをテストする体制では、エラーを生んだのと同じ思い込みが、検出の場面でも働いてしまいます。

これがテストにおける「独立性」が重視される理由です。開発者とは異なる視点、異なる前提を持った担当者がテストを設計・実行することで、内部では気づけなかった欠陥が見つかります。

とはいえ、独立したテスト体制を社内に構築するには、人材の確保・育成と継続的な運用コストがかかります。ソフトウェアテスト代行サービス『テスター10』では、テスト設計から実行、欠陥の起票・管理までを第三者の立場で支援しています。

開発チームとは独立した視点でのテスト設計・実行
再現手順・重要度が明確なバグ票の作成と欠陥管理の運用
混入工程の分析を含む、プロセス改善につながる欠陥データの整備
リリース前の集中的なリグレッションテストなど、スポットでの支援

「どの工程に手を打つべきかわからない」「テスト工数が確保できず、リリース前の検証が薄い」といった課題をお持ちでしたら、現状の欠陥データを一緒に見るところからご相談いただけます。

よくある質問（FAQ）

バグと欠陥は同じ意味ですか

ほぼ同じ意味です。JSTQB／ISTQBの用語集でも、Bug（バグ）はDefect（欠陥）の同義語として扱われています。ただし現場では「バグが出た」という言い方で故障（実行時の事象）を指すこともあり、文脈によって指す対象がずれます。文書に記録する際は、標準用語である「欠陥」に統一しておくと誤解が減ります。

「バグ」という言葉の由来は何ですか

1947年、コンピュータMark IIに蛾（bug）が挟まって誤動作を起こし、その虫が作業日誌に貼られたという逸話が知られています。ただし機械の不具合を指す「bug」自体はそれ以前からエジソンら技術者の間で使われており、この逸話は語源というより、コンピュータ分野で定着させた象徴的エピソードと捉えるのが正確です。

エラーが表示されていなければ欠陥はないと考えてよいですか

いいえ。むしろエラーメッセージが出ないタイプの欠陥のほうが危険です。計算結果が静かに1円ずれる、データが欠落したまま処理が正常終了する、といった欠陥はエラー表示を伴いません。期待結果と実際の結果を突き合わせるテストが必要になるのは、このためです。

欠陥をゼロにすることはできますか

現実的には不可能です。ISTQBのテストの7原則にも「テストは欠陥があることは示せるが、欠陥がないことは示せない」「全数テストは不可能である」が含まれています。目指すべきは欠陥ゼロではなく、リリース判断に必要な情報が揃っている状態です。

インシデントと欠陥はどう使い分ければよいですか

インシデントは「調査が必要な観測事象」であり、原因が確定していない段階の呼び方です。調査の結果、原因がソフトウェアの不備であれば欠陥として登録し、環境設定やテストケースの誤りであれば欠陥ではないと判定します。テスト現場では、まずインシデントとして記録し、調査後に欠陥かどうかを判定する運用が推奨されます。