バグはコーディングエラーの結果です
欠陥は要件からの逸脱です
つまり、欠陥は必ずしもコードにバグがあることを意味するわけではありません、それは実装されていないが要件で定義されている関数である可能性がありますソフトウェア。
ソフトウェアテスト のWikipediaページから：
すべてのソフトウェアの欠陥がコーディングエラーによって引き起こされるわけではありません。高価な欠陥の一般的な原因の1つは、要件のギャップ（認識されない要件など）が原因であり、プログラム設計者による省略のエラーが発生します。[14]要件ギャップの一般的な原因は、テスト容易性、スケーラビリティ、保守性、使いやすさ、パフォーマンス、セキュリティなどの非機能要件です。
本からのIlene Burnsteinの引用 Practical Software Testing （推奨） "IEEE Standards Collection for Software" Engineering（1994）および "IEEE Standard Glossary of Software Engineering Terminology"（standard 610.12、1990）：
エラー
エラーとは、ソフトウェア開発者のミス、誤解、または誤解です。
開発者のカテゴリには、ソフトウェアエンジニア、プログラマ、アナリスト、テスターが含まれます。たとえば、開発者がデザイン表記を誤解したり、プログラマーが変数名を誤って入力したりすることがあります。
障害（欠陥）
エラーの結果、ソフトウェアに障害（欠陥）が発生します。これは、ソフトウェアの異常であり、仕様に従っていないため、正しく動作しない可能性があります。
障害または欠陥は「バグ」と呼ばれることもあります。後者の用語を使用すると、障害がソフトウェアの品質に与える影響が簡単になります。 「欠陥」という用語の使用は、要件や設計ドキュメントなどのソフトウェアの成果物にも関連しています。これらのアーティファクトで発生する欠陥もエラーが原因であり、通常はレビュープロセスで検出されます。
失敗
障害とは、ソフトウェアシステムまたはコンポーネントが、指定されたパフォーマンス要件の範囲内で必要な機能を実行できないことです。
ソフトウェアコンポーネントまたはシステムの実行中に、テスター、開発者、またはユーザーは、期待どおりの結果が得られないことに気付きます。場合によっては、特定のタイプの誤動作は、特定のタイプの障害が存在することを示します。誤動作の種類は、障害の症状であると言えます。経験豊富な開発者/テスターは、障害/症状/障害ケース（第3章で説明した障害モデル）のナレッジベースをメモリに格納します。不正な動作には、出力変数の不正な値の生成、デバイス側の不正な応答、または画面上の不正な画像が含まれる可能性があります。開発中に障害は通常テスターによって観察され、障害は開発者によって特定され、修復されます。
Googleブックスの章全体をお読みいただけます こちら 。
ソフトウェアのバグに関連するいくつかの異なる用語があります。私が受講したコースからの抜粋：
エラー：障害となる人間の行動または脱落。
障害：障害は、障害の原因となるソフトウェアの欠陥（不適切なステップ、プロセス、またはデータ定義）です。
バグ：フォールトと同じ。
障害：ソフトウェアが指定されたパフォーマンス要件内で必要な機能を実行できないこと。
これによると、不具合とバグの違いはありません。ただし、バグはソフトウェアをリリースする前に見つかるエラーであり、欠陥は顧客が見つけたものであると主張する人もいます。
有名な「バグが発見された最初の実際のケース」を投稿するのに抵抗できませんでした。
ソフトウェアテストおよびソフトウェア品質に関するソフトウェアエンジニアリング知識体系KAで引用されている、ソフトウェアエンジニアリング用語集のIEEE標準用語集から：
バグ。参照：エラー。障害。
エラー。 （1）計算、観測、または測定された値または条件と、真の、指定された、または理論的に正しい値または条件との差。たとえば、計算結果と正しい結果の30メートルの差。 （2）誤ったステップ、プロセス、またはデータ定義。たとえば、コンピュータープログラム内の誤った命令。 （3）誤った結果。たとえば、正しい結果が10の場合の計算結果は12です。（4）誤った結果を生成する人間のアクション。例えば、プログラマーまたはオペレーターの側での誤ったアクション。注：4つの定義すべてが一般的に使用されますが、1つの違いは、定義1をWordの「エラー」に、定義2をWordの「障害」に、定義3をWordの「障害」に、定義4をWordの「間違い」に割り当てます。 a2so：動的エラーを参照してください。致命的な誤り;固有のエラー。セマンティックエラー。構文エラー;静的エラー。一時的なエラー。
失敗。システムまたはコンポーネントが、指定されたパフォーマンス要件内で必要な機能を実行できないこと。注：フォールトトレランスの分野では、人間のアクション（ミス）、その症状（ハードウェアまたはソフトウェアの障害）、フォールトの結果（障害）、および結果が正しくない（エラー）量を区別します。参照：クラッシュ;依存障害;例外;障害モード。故障率;ハード障害;初期障害;独立した障害;ランダムな失敗;ソフト障害;スタックが失敗しました。
障害。 （1）ハードウェアデバイスまたはコンポーネントの欠陥。たとえば、短絡や断線。 （2）コンピューター・プログラム内の誤ったステップ、プロセス、またはデータ定義。注：この定義は、主にフォールトトレランスの分野で使用されます。一般的な用法では、「エラー」および「バグ」という用語は、この意味を表すために使用されます。参照：データ依存の障害。プログラムに敏感な障害;同等の障害;障害マスキング;断続的な障害。
失敗の定義が最も適切だと思います。要件、設計、実装、テストケース/手順など、すべてが間違いから始まります。この間違いがソフトウェアに現れた場合、それは障害となります。障害は、ソフトウェアに1つ以上の障害が存在することが原因です。
ただし、エラーの正式な定義には熱心ではありません。私は dukeofgamingが彼の回答で提供した定義 を非常に好みますが、この回答の1つはIEEE標準のエラー定義です。
まあ。
昔、コンピューターの動作不良は、ネズミが配線を噛んでいることや、実際のバグ（クリッター）が作業に入るなど、さまざまな原因で発生していました。
BUGという用語は、期待どおりに機能しないものを意味する用語として残っています。
BUGは、欠陥を意味する専門用語と考える必要があります。
欠陥とは技術的に正しい用語であり、本来あるべきことをしていないことを意味します。
可能な場合は常に、BUGの代わりにDEFECTを使用すると、より些細な響きの「バグ」としてドレスアップするのではなく、実際に障害（私たちの欠陥、ユーザー要件の理解の欠如、または実装で見落としたもの）を認識するという暗示が伴います」.
DEFECTを使用します。
バグという用語は使わないようにしてください。その愚かな、無関係、歴史的、そして雑学。
Dan McGrathの答え はそれを正しく釘付けにしました。
- バグはコーディングエラーの結果です
- 欠陥は要件からの逸脱です
多分例はそれをより明確にするでしょう。
例：クライアントは、Webフォームがウィンドウを保存して閉じることができるようにしたいと考えていました。
シナリオ＃1：Webフォームには、保存ボタンと別の閉じるボタンがあります。結果：欠陥。クライアントが1ボタンを保存してウィンドウを閉じる必要があるため。開発者が誤解し、個別に作成しました。両方のボタンが要件を実行したため、これはバグではなく、クライアントの要件を満たしていないための欠陥です。
シナリオ＃2：Webフォームに保存して閉じるボタンがありますが、保存するだけで閉じません。結果：バグ。ボタンが必要な/期待どおりに機能しないため。開発者は、その結果を生成することが想定されていることを知っていますが、最終的には生成しませんでした。 （おそらくコーディングエラー）
これにより明確になるかどうかはわかりません。
p/s：開発者の観点から（私はかつて）、欠陥とバグの両方が同じくらい重要です。まだ修正します。
バグに分類された奇妙な異常に遭遇したこともあり、その原因と修正方法を継続的に解明しようと努めています。それをバグと呼ぶことは、欠陥と比較してそれを些細なことにはしません。
これは、ISTQB語彙に基づいて雇用者Q-LEAPのために以前に行ったものであり、IEEE語彙もチェックしました。楽しい。
バグと欠陥？これについては無限の議論があるかもしれませんが、同じです。私たちは本当に他に心配すべきことがある、人生はすでに十分に複雑である、など。
"How Google Tests Software" pの用語が実際にどのように使用されているかの例。 113.「IEEEソフトウェア」の記事を開くと、同じように使用されます。実際、実際に「欠陥」という言葉に遭遇することはめったにありません。
バグの存続期間
バグとバグレポートは、すべてのテスターが理解できる1つの成果物です。バグの発見、バグのトリアージ、バグの修正、バグのリグレッションは、ソフトウェア品質のハートビートとワークフローです。これはGoogleで最も一般的なテストの一部ですが、標準からの興味深い逸脱がいくつかあります。このセクションでは、作業項目を追跡するために提出されたバグを無視し、実際に壊れたコードを識別するためにこの用語を使用します。そのため、バグはエンジニアリングチームの時間単位および日々のワークフローを表すことがよくあります。
バグが生まれます。バグはGoogleの全員によって発見され、報告されています。プロダクトマネージャーは、仕様や考えとは異なる初期のビルドで問題を見つけたときにバグを報告します。開発者は、誤って問題をチェックインした、コードベース内の別の場所で問題を見つけた、またはGoogle製品のドッグフーディング中にバグを報告します。バグはフィールドから、クラウドソースのテスター、外部ベンダーのテストからも発生し、製品固有のGoogleグループを監視するコミュニティマネージャーによって提出されます。アプリの多くの内部バージョンにも、Googleマップのように、ワンクリックでバグを報告する方法があります。また、ソフトウェアプログラムがAPIを介してバグを作成することもあります。
依存性：基本的な概念と用語 によると：
システムfailureは、配信されたサービスがシステム機能の実行から逸脱したときに発生します。後者はシステムが意図されているものです。 エラーは、システム状態の一部であり、その後の障害につながる可能性があります。サービスに影響を与えるエラーは、障害が発生したか、または発生した。エラーの判断または仮説の原因は、faultです。
defectは単なる障害の別の名前として理解しています。
バグは混乱を招き、コンテキストに応じて障害または障害を表す可能性があります。
仕様についての言及はないことに注意してください。仕様でさえ欠陥がある可能性があります。
特定のバグ/タスク/チケット/欠陥/問題/その他の追跡システムインスタンス以外では、これらの単語は正確な意味を持たないため、それらの違いについて説明しても意味がありません。ワークフローを決定するときは、用語を決定し、説明を提供する必要があります。
私の現在の環境では、「欠陥」はJiraのすべてのアイテムです。 Jira自体が「問題」という用語を使用しているようです。以前のシステムから継承した可能性があります。 「バグ」は、何かが期待どおりに動作せず、ドキュメントに記述されている場合の問題の一種です。何かが期待通りに機能しているが改善が望まれる場合の「機能リクエスト」（それは明白で重要な場合がありますが、現在の動作が説明されている場合でも機能リクエストです）。タイプは他にもありますが、これら2つは、開発チームの外部の人々がそこから何かを要求するために使用されます。
課題タイプの名前を選ぶ場合、「バグ」と「欠陥」は私と同じように聞こえます。それらの違いは文体的です。英語は私の母国語ではないので、私はそれの多くを実際に見ることができず、私が見るものが正しいかどうかわかりません。
違いは、「バグ」という用語は魔法のように聞こえるということです。プログラミングが終わった後で、プログラムにランダムにバグが含まれているようです。ランダムなバグがある場合は、仕様に準拠しておらず、プログラムにエラーがあることを意味します。
欠陥は、プログラムが仕様に準拠していないエラーを意味します。これはより深刻であり、基本的にはanyエラーはプログラムのhuge問題であり、これはプログラムがリリースするのに適していないことを意味します。
違いは、用語を使用するプログラマーの態度にあります。何百万ものプログラムがバグとともにリリースされており、バグが魔法でランダムであること、およびすべてのプログラムに少なくとも1つのバグが含まれていることを何らかの理由で受け入れているため、人々はそれで問題ありません。ただし、「欠陥」という用語を使用するプログラマは、この用語の重大度が高いことを意味するため、欠陥のあるプログラムをリリースすることに不快になる可能性があります。
ある用語を他の用語よりも優先することの影響は、私たちに毎日影響を与えます。