ソフトウェアのバグ/欠陥の分類

Question

私たちはバグ/欠陥をよりよく説明する用語を考え出そうとしています。私たちにとって、「バグ」または「欠陥」という用語は一般的すぎて、何が起こっているのかを正確に反映していません。たとえば、（一般的な意味で）バグがあると言うのではなく、どのような種類のバグ（エラー、拡張、または改善など）であるかを言います。「バグ」を説明するためにどのような名前を使用しますか？

http://www.softwaredevelopment.ca/bugs.shtml が見つかりました。それらをどのように分類しますか？

aufather · Accepted Answer

それらを次のように分類します

変更リクエスト（小さな機能強化、動作の変更）
設計変更要求（設計ドキュメントを必要とする大きな機能）
sw-bug（プログラマーのエラーによるソフトウェアのバグ）
test-bug（実際にはソフトウェアのバグではなく、スクリプトでのテスターのミス）
サポートリクエスト（通常はフィールドからの情報/説明リクエスト）
無効（報告された問題は存在しないか、予想される動作です）
重複（まったく同じ問題がすでに報告されています）
doc-bug（ドキュメントエラー、ドキュメントは正しい動作で更新する必要があります）（これを指摘してくれたMichaelに感謝）

Roman Starkov · Answer

バグトラッカーの分類を設計するとき、各フィールドの目的を非常に意識するようにしました。これが最終的な結果です。

いつ作業する予定ですか？

このフィールドには、計画の結果が記録されます。検索とフィルタリングを行うことは非常に便利です。開発者がタスクを実行していない場合（割り当てられたすべての作業が完了したか、何らかの理由で作業がブロックされた場合）、「いつ"：

enter image description here

私たちは頻繁に「Now」と「Next」の間で問題を移動し、「Soon」タスクを時々およびリリース後にレビューします。時々、「後で」タスクを実行します。「If if」は、リクエストを閉じる代わりに使用するフィールドであり、これから作業するかどうかはわかりません。

これを修正するにはどのくらい時間がかかりますか？

このフィールドは、作業にかかると思われる時間の最も適切な見積もりです。これを理解することは非常に難しいことですが、対数目盛と桁数の粗さのため、このリストの複数のエントリから外れることはめったにありません。

enter image description here

このフィールドはいくつかの状況で使用されます。何よりもまず、上で説明した「いつ」フィールドに何が入るかについての主要な考慮事項です。やる気がなければ、月曜日にこのフィールドを使用して非常に短いタスクを開始するのが好きです。また、新入社員ややる気のない人のために仕事を見つけることも役に立ちます。

物事の壮大な計画において、この仕事はどのくらい重要ですか？

このフィールドは、プロジェクト計画を行う人のためのものです。開発者は本当に気にしません。この作業がプロジェクトの成功にどの程度重要であると考えるかを記録するのに役立ちます。

enter image description here

これは、「この作業にかかる時間」と一緒に使用され、このタスクにいつ取り組むかを決定します。

バグの状態はどうですか？

このフィールドはワークフローに使用されます。以下に示すすべての状態は、「開いている」または「閉じた」状態です。バグトラッカーには、未解決のバグのみを表示するショートカットがあり、それがこのフィールドの主な用途です。

enter image description here

オープン/クローズドへの細分化がこのフィールドの主な目的ですが、個々の「クローズド」エントリは結果を要約するように機能します。これはコメントからも推測できますが、この情報を見つけることができる標準的な場所があると役立ちます。

重複するバグには、そのバグが何であるかを示すリンクが少なくとも1つ必要であるという、バグトラッカーによるルールがあります。

過去の経験から、これを適切に最新の状態に保つことは非常に困難であり、その結果、状態は良い状態よりも害を及ぼす可能性があるため、「進行中」の状態を使用しないことは非常に明確です。

このバグは何ですか？

これは、従来の「バグタイプ」フィールドに最も近いものです。その主な目的は、エントリを人間に記述することです。 このフィールドを検索したり、フィルタリングしたりすることはほとんどありません。バグのタイトルに単語を保存するのはそこだけです。リストはプロジェクトによって多少異なりますが、代表的な例を次に示します。

enter image description here

空のフィールド

上記のすべての値を選択することは必ずしも容易ではないため、バグを入力した人は、現時点では把握できないフィールドを空のままにすることができます。私たちは、あなたが怠惰に感じているだけの場合でも、これが完全に問題ないという姿勢を維持します。

「いつ」と「重要度」のフィールドは、プロジェクトプランナーが決定するためのものなので、多くの場合、空白のままにします。「Much work」が空白のエントリは時々レビューされ、潜在的な譲受人はそれを見積もるよう求められます。

プロジェクト固有

大規模なプロジェクトは上記のすべてを使用しますが、特定の小規模なプロジェクトは少数を排除します。それらが「重要性」を使用しない場合、フィールドはそのプロジェクトから削除されると主張します。アクティブに使用されているフィールドのみが存在する必要があるという考えです。

追伸上記のスクリーンショットは、YouTrackのものです。すべての組み込みフィールドを削除して、独自のフィールドを使用しても問題はありませんでした。

fommil · Answer

Code Completeの「開発者テスト」セクションでは、欠陥を次のように分類しています。

構造的
データ
実装された機能
建設
統合
機能要件
テストの定義または実行
システム、ソフトウェアアーキテクチャ
不特定

（これは1990年のBeizerの研究によるものです）

もちろん、欠陥のクラスは、それが修正されたことを後から見ないと明らかにならない場合があります。

この分類スキームは、欠陥のタイプをその重大度（重大->取るに足らない）と優先度（昨日必要->パイプドリーム）と区別します。

また、これは ticket がDEFECTまたはENHANCEMENT（非常に標準的なタイプのチケット）ではなく、TASKとしてすでに分類されていることを前提としています。）。

Thomas Owens · Answer

直交欠陥分類のようなものが役に立つかもしれません。アイデアは、すべての送信に対して意味のある単一の可能な値のみをそれぞれが持つような一連のオプションを持つことです。 IBM Researchにはこのコンセプトに特化したいくつかのWebページがあります。

欠陥の種類に関する限り、私が本当に知りたいのは、それが欠陥なのか、それとも機能強化なのかだけです。欠陥は、それを生成したアーティファクトに適合しない作業成果物に存在します。たとえば、利害関係者の意図を十分に捉えていない要件には欠陥があります。同様に、要件に対応していないデザインや、デザインや要件を実現していない実装には欠陥があります。拡張または変更要求は、指定された要件を満たさないアーティファクトの変更になります。これは、例として、技術的負債を削減するための新しい要件またはリファクタリングになる可能性があります。

包括的な分類スキームでは、次の質問に対処すると思います。実際にキャプチャする必要のあるものは、データの使用方法によって異なります。タスクを追跡するための欠陥データの使用は、厳密なメトリックプログラムへの入力である欠陥データよりも完全でない必要があります。

これは既存の成果物または成果物の拡張機能の問題ですか？要件、ドキュメント、またはコードモジュールのいずれかです。、仕様に準拠していないか、作業成果物のベースとなる仕様を拡張する必要があります。
どの作業成果物が影響を受けますか？これはドキュメントに影響を与えますか（そしてどれに影響しますか）？コードに反していますか？ユニットテスト？リリースプロセスによっては、追加のデータ要素として、この欠陥または機能強化の影響を受けるバージョンに対処する場合もあります。
この欠陥の優先度および/または重大度は何ですか？優先度は通常、顧客またはユーザー定義の要素であり、いくつかの解決策がどれだけ迅速に必要かを示します種類。優先度の高い欠陥に最初に対処する必要があります。「対処」とは、欠陥が適切に解決されるまで、単に回避策を分析および開発することを意味する場合があることに注意してください。重大度は通常、作業への影響を定義します。重大度が低いと、ビジネス価値への影響が最小限になります。重大度が高いと、欠陥のためにユーザーがビジネス目標を達成するのが非常に困難になります。
欠陥はいつ報告されましたか？最終的にそれが解決されたのはいつですか？これは、顧客満足度メトリックスに関連している可能性がある閉鎖までの時間データを追跡するために使用できます。
欠陥はどこにあり、どこに最初に挿入されましたか？これは、欠陥の合計数などの欠陥数の測定基準をキャプチャする場合にのみ必要です（社内で発見/修正された欠陥とリリース後の欠陥の数）またはフェーズ封じ込めの有効性。私はアクティビティベースの概念（要件、アーキテクチャ/設計、実装、テスト、フィールドに沿ったもの）を好み、反復を無視して、欠陥のキャプチャに熟練しているプロセスに関連するアクティビティと、必要な場所を特定できるようにしますプロセスを改善するため。
この欠陥が存在する、または挿入される原因は何ですか？これをどのように定義するかは組織によって異なりますが、 PSPが出発点として適切です。理解できないほど複雑なものは必要ありません。また、直交欠陥分類と同様に、欠陥を複数のカテゴリに分類できないようにします。
この欠陥を特定して参照するにはどうすればよいですか？通常、一意の識別子と短く人間が読めるタイトルがこの情報を提供します。これらを使用して、進行中の作業に関する情報を顧客/ユーザーに提供したり、ステータスレポートやコミットログで情報を提供したりして、閉鎖までの欠陥を追跡できます。

これらのほとんどは、存在する理由を除いて、欠陥と機能強化に等しく適用されます。

sevenseacat · Answer

機能強化や改善をバグとは呼んでいません。

私は通常、次のように課題追跡で課題を分類します。

バグ-予期しない出力につながるコードの問題。
サポート-他の問題を見る前に行う必要があること。すなわち。 CSVジェネレーターがエラーを生成しているというバグは、適切なCSVジェネレーターがまだないためです。サポート-CSVジェネレーターを作成します。
機能-私がしたい強化または改善。大きくても小さくてもかまいません。
願い-日の光を見ることはおそらくない本当の目を見張るタイプの機能-「ソフトウェアがあなたの心を読んで、あなたが自動的に探していたものにあなたを導くことができたら素晴らしいのではないでしょうか？」
Todo-適切に詳細化/分類する前に調査/スコーピングが必要なもの。