単純なバグ追跡システムのために取り残されている可能性のあるものはありますか?
ERD http://img694.imageshack.us/img694/8166/captureqpe.jpg
ここに新しい変更を加えた更新バージョンがあります
単純なバグ追跡システムのために取り残されている可能性のあるものはありますか?
ERD http://img694.imageshack.us/img694/8166/captureqpe.jpg
ここに新しい変更を加えた更新バージョンがあります
それはあなたの「シンプル」の定義に依存します。ドキュメント(スクリーンショットなど)を添付するメカニズムはありませんが、単純なバグ追跡システムにはそれらがない可能性があります。
「商品」はあまりきめが細かくありません。サブシステム(より大きなシステムの場合)およびコンポーネント(より複雑なアーキテクチャの場合)と同様に、リリース番号またはリビジョンが役立ちます。
また、バグテーブルには、環境(開発、テスト、本番など)、完了予定日、およびドロップデッド日付の属性が必要です。誰がそれを報告したのか、誰が現在取り組んでいるのかを区別できることも役立ちます。もちろん、それが終了するのを見る最終的な責任は誰にあるのかは言うまでもありません。
確かにあなたのテキストフィールドは短すぎます。私のバグは説明するのに255文字以上必要です!
用語についての口論。開発者以外の人々、特にテスターは、バグについて報告、進行、コメントします。したがって、Developerテーブルにはより一般的な名前が必要です。同様に、すべてがバグであるとは限らないため、バグテーブルの名前はIssueなどのロードされていないものにする必要があります。
おそらく、Developers から開発者のチームを表す FK を持つ Teams テーブルです。(QA チーム、開発チーム、トリアージ チーム)。
BUg と開発者は、多対多の関係である必要があります。複数の開発者が割り当てられているバグがあります。そのためには結合テーブルが必要です。