欠陥とバグの違いは何ですか？

• バグはコーディングエラーの結果です

• 欠陥は要件からの逸脱です

つまり、欠陥は必ずしもコードにバグがあることを意味するものではなく、実装されていないがソフトウェアの要件で定義されている機能である可能性があります。

ソフトウェアテストに関するWikipediaページから：

すべてのソフトウェアの欠陥がコーディングエラーによって引き起こされるわけではありません。高価な欠陥の一般的な原因の1つは、要件のギャップ、たとえば、認識されていない要件によって引き起こされ、プログラム設計者による省略の誤りが生じます。[14] 要件のギャップの一般的な原因は、テスト容易性、スケーラビリティ、保守性、使いやすさ、パフォーマンス、セキュリティなどの非機能要件です。

「ソフトウェアエンジニアリングのIEEE標準コレクション」（1994）および「ソフトウェアエンジニアリング用語のIEEE標準用語集」（標準610.12、1990）の定義から外れているPractical Software Testing（推奨）からIlene Burnsteinを引用：

エラー

エラーは、ソフトウェア開発者側の間違い、誤解、誤解です。

開発者のカテゴリには、ソフトウェアエンジニア、プログラマ、アナリスト、テスターが含まれます。たとえば、開発者が設計表記を誤解したり、プログラマが変数名を誤って入力したりする場合があります。

障害（欠陥）

エラーの結果として、障害（欠陥）がソフトウェアに導入されます。ソフトウェアの異常であり、仕様どおりではなく、正しく動作しない可能性があります。

障害または欠陥は「バグ」と呼ばれることもあります。後者の用語を使用すると、障害がソフトウェアの品質に与える影響を単純化します。「欠陥」という用語の使用は、要件や設計文書などのソフトウェア成果物にも関連付けられています。これらのアーティファクトで発生する欠陥もエラーが原因であり、通常はレビュープロセスで検出されます。

失敗

障害とは、ソフトウェアシステムまたはコンポーネントが、指定されたパフォーマンス要件内で必要な機能を実行できないことです。

ソフトウェアコンポーネントまたはシステムの実行中、テスター、開発者、またはユーザーは、期待した結果が得られないことを観察します。特定のタイプの不正行為は、特定のタイプの障害が存在することを示す場合があります。不正行為のタイプは障害の症状であると言えます。経験豊富な開発者/テスターは、障害/症状/障害のケース（第3章で説明した障害モデル）の知識ベースをメモリに保存します。不正な動作には、出力変数の不正な値の生成、デバイス側の不正な応答、または画面上の不正な画像が含まれます。通常、開発中にテスターが障害を観察し、開発者が障害を特定して修復します。

Googleブックスの章全体をこちらで読むことができます。

ソフトウェアのバグに関連するいくつかの異なる用語があります。私が受講したコースからの抜粋：

• エラー：人為的行為または不作為により不作為。

• 障害：障害は、障害の原因となるソフトウェアの欠陥（不正なステップ、プロセス、またはデータ定義）です。

• バグ：障害と同じ。

• 失敗：指定されたパフォーマンス要件内でソフトウェアが必要な機能を実行できないこと。

これによると、欠陥とバグの間に違いはありません。ただし、バグはソフトウェアをリリースする前に発見されたエラーであると主張する人もいますが、欠陥は顧客が発見したものです。

私は有名な「発見されたバグの最初の実際のケース」を投稿することを避けられませんでした。

まあ。

昔のこと-コンピューターの動作不良は、あらゆる種類の物事によって引き起こされました-ラットが配線を噛むことや、実際のバグ（生き物）が作業に入ることを含みます。

BUGという用語は、期待どおりに機能しないものを意味する用語として定着しています。

BUGは、欠陥を意味する専門用語として考えるべきです。

欠陥とは、技術的に正しい用語で、本来あるべきことをしていないことを意味します。

可能な限り、BUGの代わりにDEFECTを使用すると、より些細な音の「バグ」としてドレスアップする代わりに、失敗（私たちの欠陥、ユーザー要件の理解不足、実装で見落とされたもの）を認識するという意味合いが実際に伴います「。

DEFECTを使用します。

BUGという用語は使用しないでください。その愚かで、無関係で、歴史的で、雑学。

ソフトウェアテストおよびソフトウェア品質に関するソフトウェアエンジニアリング知識体系KAで引用されているソフトウェアエンジニアリング用語のIEEE標準用語集から：

バグ。参照：エラー; 障害。

エラー。（1）計算、観測、または測定された値または条件と、真の、指定された、または理論的に正しい値または条件との差。たとえば、計算結果と正しい結果の間の30メートルの差。（2）不正なステップ、プロセス、またはデータ定義。たとえば、コンピュータープログラムの誤った指示。（3）誤った結果。たとえば、正しい結果が10の場合の計算結果は12です。（4）誤った結果を生成する人間のアクション。たとえば、プログラマーまたはオペレーターの一部に対する誤ったアクション。注：4つの定義すべてが一般的に使用されますが、1つの区別により、定義1が「エラー」、定義2が「障害」、定義3が「失敗」、定義4が「間違い」に割り当てられます。 a2so：動的エラーを参照してください。致命的な誤り; 固有のエラー; セマンティックエラー。構文エラー。静的エラー。一時的なエラー。

失敗。システムまたはコンポーネントが、指定されたパフォーマンス要件内で必要な機能を実行できないこと。注：フォールトトレランスの規律は、人間の行動（誤り）、その兆候（ハードウェアまたはソフトウェアの欠陥）、欠陥の結果（障害）、および結果が正しくない量（エラー）を区別します。参照：クラッシュ; 依存障害; 例外; 故障モード; 故障率; ハード障害; 初期障害; 独立した障害; ランダム障害; ソフト障害; スタック障害。

障害。（1）ハードウェアデバイスまたはコンポーネントの欠陥。たとえば、短絡または断線。（2）コンピュータープログラムの誤ったステップ、プロセス、またはデータ定義。注：この定義は、主にフォールトトレランス分野で使用されます。一般的な用法では、「エラー」および「バグ」という用語はこの意味を表すために使用されます。参照：データに依存する障害。プログラムに敏感な障害; 同等の障害; 障害マスキング; 断続的な障害。

失敗の定義が最も重要だと思います。要件、設計、実装、またはテストケース/手順にあるかどうかにかかわらず、すべては間違いから始まります。この間違いがソフトウェアで明らかになった場合、それは障害になります。障害は、ソフトウェアに1つ以上の障害が存在することによって発生します。

ただし、エラーの正式な定義については熱心ではありません。私は彼の答えでデュークゲーミングによって提供された定義を非常に好みますが、この答えの1つはエラーのIEEE標準定義です。

Dan McGrathの答えはそれを正しかった。

• バグはコーディングエラーの結果です
• 欠陥は要件からの逸脱です

たぶん例がそれをより明確にするでしょう。

例：クライアントは、Webフォームでウィンドウを保存および閉じることができることを望んでいました。

シナリオ＃1：Webフォームには、保存ボタンと別の閉じるボタンがあります。結果：欠陥。クライアントがウィンドウを保存して閉じるために1ボタンが必要だったためです。開発者は誤解され、別に作成されました。両方のボタンが要件を実行したため、これはバグではなく、クライアントの要件を満たしていないための欠陥です。

シナリオ＃2：Webフォームには保存して閉じるボタンがありますが、保存するだけで閉じません。結果：バグ。ボタンが必要/期待どおりに機能しないため。開発者は、その結果を生成することを想定していますが、最終的にはそうしませんでした。（おそらくコーディングエラー）

これで明確になるかどうかはわかりません。

p / s：開発者の観点から（私はかつて）、欠陥とバグの両方が同じくらい重要です。引き続き修正します。

奇妙な異常にさえ遭遇し、それをバグの下に分類し、原因とその修正方法を常に把握しようと試みました。バグと名付けても、欠陥と比べて些細なことではありません。

違いは、「バグ」という用語が魔法のように聞こえることです。プログラミングが完了した後、プログラムにランダムにバグが発生する可能性があります。ランダムなバグがある場合は、仕様に準拠しておらず、プログラムにエラーがあることを意味します。

欠陥とは、プログラムが仕様に適合しないエラーを意味します。これはより深刻で、基本的に、エラーはプログラムの大きな問題であり、これはプログラムがリリースに適していないことを意味します。

違いは、用語を使用するプログラマーの態度です。バグでリリースされた何百万ものプログラムがあり、バグは魔法でランダムであり、すべてのプログラムに少なくとも1つのバグが含まれていることを何らかの理由で受け入れているため、人々はそれで大丈夫です。ただし、「欠陥」という用語を使用するプログラマーは、その用語が重大度が高いことを意味するため、欠陥のあるプログラムをリリースすることに不快感を覚える場合があります。

ある用語を他の用語よりも優先することの意味は、毎日私たちに影響を与えます。

ディペンダビリティによると：基本的な概念と用語：

提供されたサービスがシステム機能の実行から外れると、システム障害が発生します。後者はシステムの目的です。エラーは、後続の故障につながるおそれがあるシステム状態の部分である：サービスに影響を与えるエラーは、障害が発生し又は発生したことを示すものです。エラーの裁定または仮定原因がある不具合。

私は欠陥を単なる欠陥の別の名前として理解しています。

バグは紛らわしく、コンテキストに応じて障害または障害を表します。

仕様については何も言及されていないことに注意してください。仕様にさえ欠陥がある可能性があります。

これは、ISTQB語彙に基づいて雇用主Q-LEAPに対して以前に行ったもので、IEEE語彙も確認しました。楽しい。

バグと欠陥？これについては終わりのない議論ができますが、同じことです。他にも心配すべきことがあります。人生はすでに複雑です。

「How Google Tests Software」 p から、この用語がどのように使用されているかの例。113.「IEEE Software」の記事を開き、同じ方法で使用します。実際、実生活では「欠陥」という言葉に出会うことはめったにありません。

バグの生活

バグとバグレポートは、すべてのテスターが理解できる1つの成果物です。バグの発見、バグのトリアージ、バグの修正、バグの退行は、ソフトウェア品質のハートビートとワークフローです。これは、Googleで最も一般的なテストの一部ですが、まだ標準からいくつかの興味深い逸脱があります。このセクションでは、作業項目を追跡するために提出されたバグを無視し、この用語を使用して実際の破損コードを特定します。そのため、バグは多くの場合、エンジニアリングチームの1時間ごとおよび1日ごとのワークフローを表しています。

バグが生まれます。バグはGoogleの全員によって発見され、報告されています。プロダクトマネージャーは、初期のビルドで仕様や考えとは異なる問題を発見するとバグを報告します。開発者は、問題を誤ってチェックインしたか、コードベースのどこかで問題を見つけた場合、またはGoogle製品をドッグフードしているときにバグを報告します。バグは、クラウドソーシングのテスター、外部ベンダーのテストからも発生し、製品固有のGoogleグループを監視するコミュニティマネージャーによって提出されます。アプリの多くの内部バージョンには、Googleマップなどのバグを登録するための簡単なワンクリック方法もあります。また、場合によっては、ソフトウェアプログラムがAPIを介してバグを作成します。

特定のバグ/タスク/チケット/欠陥/問題/追跡システムインスタンス以外では、これらの単語は正確な意味を持たないため、それらの違いを議論することは無意味です。ワークフローを確定するときは、用語を確定し、説明を提供する必要があります。

私の現在の環境では、「欠陥」はJiraのアイテムです。Jira自体が「問題」という用語を使用しているようです。以前のシステムから継承した可能性があります。「バグ」は、何かが期待どおりに機能せず、ドキュメントで説明されている場合の問題の一種です。何かが期待どおりに機能しているが改善が必要な場合の「機能要求」（明らかで重要な場合もありますが、現在の動作が記述されている場合は、まだ機能要求です）。より多くの種類がありますが、これら2つは、開発チーム以外の人が何かを尋ねるために使用します。

課題タイプの名前を選択している場合、「バグ」と「不具合」は私に似ています。それらの違いは文体的です。英語は私の母国語ではないので、英語の多くを実際に見ることができず、私が見ているものが正しいかどうかわかりません。