私たちはバグ/欠陥をよりよく説明する用語を考え出そうとしています。私たちにとって、「バグ」または「欠陥」という用語は一般的すぎて、何が起こっているのかを正確に反映していません。たとえば、(一般的な意味で)バグがあると言うのではなく、どのような種類のバグ(エラー、拡張、または改善など)であるかを言います。 「バグ」を説明するためにどのような名前を使用しますか?
http://www.softwaredevelopment.ca/bugs.shtml が見つかりました。それらをどのように分類しますか?
それらを次のように分類します
バグトラッカーの分類を設計するとき、各フィールドの目的を非常に意識するようにしました。これが最終的な結果です。
このフィールドには、計画の結果が記録されます。検索とフィルタリングを行うことは非常に便利です。開発者がタスクを実行していない場合(割り当てられたすべての作業が完了したか、何らかの理由で作業がブロックされた場合)、「いつ":
私たちは頻繁に「Now」と「Next」の間で問題を移動し、「Soon」タスクを時々およびリリース後にレビューします。時々、「後で」タスクを実行します。 「If if」は、リクエストを閉じる代わりに使用するフィールドであり、これから作業するかどうかはわかりません。
このフィールドは、作業にかかると思われる時間の最も適切な見積もりです。これを理解することは非常に難しいことですが、対数目盛と桁数の粗さのため、このリストの複数のエントリから外れることはめったにありません。
このフィールドはいくつかの状況で使用されます。何よりもまず、上で説明した「いつ」フィールドに何が入るかについての主要な考慮事項です。やる気がなければ、月曜日にこのフィールドを使用して非常に短いタスクを開始するのが好きです。また、新入社員ややる気のない人のために仕事を見つけることも役に立ちます。
このフィールドは、プロジェクト計画を行う人のためのものです。開発者は本当に気にしません。この作業がプロジェクトの成功にどの程度重要であると考えるかを記録するのに役立ちます。
これは、「この作業にかかる時間」と一緒に使用され、このタスクにいつ取り組むかを決定します。
このフィールドはワークフローに使用されます。以下に示すすべての状態は、「開いている」または「閉じた」状態です。バグトラッカーには、未解決のバグのみを表示するショートカットがあり、それがこのフィールドの主な用途です。
オープン/クローズドへの細分化がこのフィールドの主な目的ですが、個々の「クローズド」エントリは結果を要約するように機能します。これはコメントからも推測できますが、この情報を見つけることができる標準的な場所があると役立ちます。
重複するバグには、そのバグが何であるかを示すリンクが少なくとも1つ必要であるという、バグトラッカーによるルールがあります。
過去の経験から、これを適切に最新の状態に保つことは非常に困難であり、その結果、状態は良い状態よりも害を及ぼす可能性があるため、「進行中」の状態を使用しないことは非常に明確です。
これは、従来の「バグタイプ」フィールドに最も近いものです。その主な目的は、エントリを人間に記述することです。 このフィールドを検索したり、フィルタリングしたりすることはほとんどありません。バグのタイトルに単語を保存するのはそこだけです。リストはプロジェクトによって多少異なりますが、代表的な例を次に示します。
上記のすべての値を選択することは必ずしも容易ではないため、バグを入力した人は、現時点では把握できないフィールドを空のままにすることができます。私たちは、あなたが怠惰に感じているだけの場合でも、これが完全に問題ないという姿勢を維持します。
「いつ」と「重要度」のフィールドは、プロジェクトプランナーが決定するためのものなので、多くの場合、空白のままにします。 「Much work」が空白のエントリは時々レビューされ、潜在的な譲受人はそれを見積もるよう求められます。
大規模なプロジェクトは上記のすべてを使用しますが、特定の小規模なプロジェクトは少数を排除します。それらが「重要性」を使用しない場合、フィールドはそのプロジェクトから削除されると主張します。アクティブに使用されているフィールドのみが存在する必要があるという考えです。
追伸上記のスクリーンショットは、YouTrackのものです。すべての組み込みフィールドを削除して、独自のフィールドを使用しても問題はありませんでした。
Code Completeの「開発者テスト」セクションでは、欠陥を次のように分類しています。
(これは1990年のBeizerの研究によるものです)
もちろん、欠陥のクラスは、それが修正されたことを後から見ないと明らかにならない場合があります。
この分類スキームは、欠陥のタイプをその重大度(重大->取るに足らない)と優先度(昨日必要->パイプドリーム)と区別します。
また、これは ticket がDEFECT
またはENHANCEMENT
(非常に標準的なタイプのチケット)ではなく、TASK
としてすでに分類されていることを前提としています。 )。
直交欠陥分類 のようなものが役に立つかもしれません。アイデアは、すべての送信に対して意味のある単一の可能な値のみをそれぞれが持つような一連のオプションを持つことです。 IBM Researchには このコンセプトに特化したいくつかのWebページ があります。
欠陥の種類に関する限り、私が本当に知りたいのは、それが欠陥なのか、それとも機能強化なのかだけです。欠陥は、それを生成したアーティファクトに適合しない作業成果物に存在します。たとえば、利害関係者の意図を十分に捉えていない要件には欠陥があります。同様に、要件に対応していないデザインや、デザインや要件を実現していない実装には欠陥があります。拡張または変更要求は、指定された要件を満たさないアーティファクトの変更になります。これは、例として、技術的負債を削減するための新しい要件またはリファクタリングになる可能性があります。
包括的な分類スキームでは、次の質問に対処すると思います。実際にキャプチャする必要のあるものは、データの使用方法によって異なります。タスクを追跡するための欠陥データの使用は、厳密なメトリックプログラムへの入力である欠陥データよりも完全でない必要があります。
これらのほとんどは、存在する理由を除いて、欠陥と機能強化に等しく適用されます。
機能強化や改善をバグとは呼んでいません。
私は通常、次のように課題追跡で課題を分類します。
優先順位は、通常、まったく別の問題です。バグは、優先度の低いものから即時のものまでさまざまですが、機能、願望、ToDoは通常常に低くなります。
ホイール(または英語)を再発明しようとする前に、バグの説明に重点を置くべきではありませんか?
「バグ」=良くない/望ましくない/間違い/エラー
はい、それは一般的ですが、何か悪いことを説明するために新しい単語を作ることから何も得られません。
私はそれらを次のように分類します。
より細かい分類は、バグ分類法の経験的調査として、またはある種の統計分析に役立つかもしれませんが、実際には、それらが修正されているかどうか、再現できるかどうか、実際にバグであるかどうかだけが重要です。
それ以上、あなたはそれを食べるのではなく、あなたの食べ物で遊んでいるのではないかと思います。