優れたバグデータベースを維持する手順

バグデータベースを維持することは、すべてのプロジェクトにとって重要です。バグデータベースに以下を保存するのに慣れています

• 発行日時
• 誰に割り当てられています
• 解決されたかどうか
• 解決された場合、解決された日時

十分なバグデータベースを維持するのに十分ですか？

良いバグデータベースには次のようなものがあります。

//日時関連

• バグの発行日時
• 修正/解決予定日時
• 解決された場合、解決された日時

//割り当て先+

• 割り当て者（検出者）
• に割り当てられた

//バグの動作

• 観察された（バギー）動作
• スクリーンショット（可能）
• バグを再現するための手順を完了する
• 予想される行動

// 優先度

• バグの優先度

//リンク、ステータス、その他

• 関連するバグのリンク
• バグのステータス
• 解決されたかどうか
• それでは解決した場合、説明でどのように解決したか

編集：私もお勧めしたいです

• バグが発見されたリビジョン/ブランチ
• どのリビジョン/ブランチでバグが修正されましたか

編集： @jgauffinのコメントが好きです

• 修正しない、バグではない、重複、解決済み

編集：良いバグデータベースシステムも維持します

• 責任割り当てマトリックス

プロジェクトのニーズに応じて、ログに記録する必要があるカスタムフィールドがいくつかある場合があります。私はあなたが同様に考慮する必要があるかもしれない次のリストを思いつきました：

• DateTimeバグ/欠陥の問題
• バグの説明-再作成する手順。
• 見つかった環境（開発、QA、QC、ステージング、製品）
• 問題のスクリーンショット
• 誰がログに記録したか（検出者）
• 誰に割り当てられているか（割り当て先）
• バグの重大度（低、中、高）
• 期待される解決策 DateTime
• 状態トリアージ（提案、進行中、解決済み、クローズ）
• バグがクローズされたDateTime-バグが解決されてクローズされたとき
• テストに割り当てられている（によってテストされている）

編集：追跡する価値のある一般的な情報のほとんどは、Bugzillaなどのソフトウェアでよく説明されています。Bugzillaは、もともとMozillaプロジェクトによって開発および使用され、Mozilla Public Licenseの下でライセンスされたWebベースの汎用バグトラッカーおよびテストツールであり、無料です。私は考えを強くアドバイス主な例として、それらを取り、あなたのプロジェクトのニーズにそれを拡張します。

ほとんどの有用なフィールドはすでに他の回答でカバーされているようですが、私が有用だと思うものは次のとおりです。

• どのリビジョン/ブランチでバグが発見されたか。
• どのリビジョン/ブランチで修正されました。

これは、バグが発見/修正された日時よりも少し具体的です。

ソフトウェアが複数のプラットフォーム（OSまたはハードウェア）で実行されている場合、バグが発生したプラットフォームをリストするフィールドも必要になる場合があります。

ただし、バグデータベースの管理には、フィールドに含める必要がある以上のものがあります。また、ベースの使用方法も考慮する必要があります。

未解決/未解決のバグの数をできるだけ少なくするようにしてください。これは明白に思えるかもしれませんが、少なくとも大規模なプロジェクトでは、予想よりも難しい場合があります。再現できない問題や、問題の最初の提出者から情報が不足していることが決して提供されない問題をクローズするのを恐れすぎる人がよくいます。また、永遠に存在し、ソフトウェアの古いバージョンで最後に見られたバグは、そのままにしておくべきではありません。これにより、実際の問題である場合とそうでない場合がある問題でデータベースが大きくなり、開発が遅くなります。

多くの場合、バグの履歴を確認する必要があります。解決された後、再開され、再度解決されます。そのため、すでに提案されているものに加えて、追跡するために別のテーブルを用意することをお勧めしますバグが（再）開かれるたびに、その履歴が表示されます。このテーブルは、バグのテーブルと多対1の関係にあり、次のようなフィールドを持つ可能性があります。

• 開業日
• 開店者
• 解決日
• 解決者
• 使った時間
• 解決方法
• 等

特に大規模なチームで作業している場合は、誰に、いつバグが割り当てられたのかを追跡するために、同様のテーブルが必要になる場合もあります。

また、既存のシステムを確認することもお勧めします。IMHO Jiraは、最高の問題追跡システムの1つです。これには非常に豊富な機能があり、それらのいくつかを独自のシステムのガイドとして使用できます。

バグ追跡のプロセスは、データと同じくらい重要です。以下についても考えてみてください。

• ユーザーはどのようにバグを報告しますか？
• 誰がバグをリポジトリに入力しますか？
• 誰がバグの存在を確認できますか？
• バグが解決されたことを誰が確認できますか？
• 誰がバグを解決したことをエンドユーザーに通知しますか？

チーム内のすべての人（エンドユーザーを含む）が自分の責任を理解できるように、RACIチャートを作成します。これを適切なデータ入力手法と組み合わせると、わずかな労力でより多くの価値が得られます。