A good bug database may have the followings

// Date Time Related

• Issue date time of the bug
• Expected fix/solve date time
• If solved then, solved date time

// Assigned By + To

• Assigned by (detected by)
• Assigned To

// Bug behavior

• Observed (buggy) behavior
• Screen Shot (Is possible)
• Complete steps to reproduce the bug
• Expected behavior

// Priority

• Priority of the bug

// Link, Status and Others

• Link of related bugs
• Status of the bug
• Whether it has been solved or not
• If solved then, how solved with explanation

EDIT: I also want to recommend

• In what revision/branch was the bug discovered
• In what revision/branch has the bug been fixed

EDIT: I like @jgauffin’s comment

• Wont fix, Not a bug, Duplicate, Solved

EDIT: A good bug database system also maintains

• Responsibility assignment matrix

There might be a number of custom fields that you may need to log, depending on the project needs. I came up with the following list that you may need to consider as well:

• Issue DateTime of Bug/Defect
• Description of the Bug – steps to re-create.
• Environment where it found (Dev, QA, QC, Staging, Prod)
• Screen-shot of the issue
• Who logged it (detected by)
• Whom is it assigned (assigned by)
• Severity of the Bug (Low, Medium, High)
• Expected resolution DateTime
• State Triage (Proposed, In Progress, Resolved, Closed)
• Bug is Closed DateTime – when a bug is resolved and closed
• Assigned to be tested ( tested by )

Edit: Most of the common information that have value to be tracked are well-described in softwares like Bugzilla. Bugzilla is a Web-based general-purpose bugtracker and testing tool originally developed and used by the Mozilla project, and licensed under the Mozilla Public License- and is FREE. I would strongly advice take them as primary example and extend it upon your project needs.

Most of the useful fields seem to have been covered already by other answers, but some that I find useful is:

• In what revision/branch was the bug discovered.
• In what revision/branch has it been fixed.

This is slightly more specific than at what date/time the bug was discovered/fixed.

If your software runs on several platforms (OS or hardware) you may also want a field that lists the platforms where the bug occurs.

But there’s more to maintaining a bug database than what fields it should contain. You also need to consider how you use the base.

Try to keep the number of open/unresolved bugs as low as possible. This may seem obvious, but may be more difficult than expected, at least for larger projects. I often see people too afraid to close issues that are either non-reproducible or where lacking information is never provided by the original submitter of the issue. Also bugs that have been laying around forever and was last seen in ancient versions of the software should not be left laying around. This makes the database grow with issues that may or may not be real issues, and slows down development.

You would often need to see the history of a bug _ it may be resolved, then reopened, then resolved again, etc. So, in addition to what has already been suggested, I’d advise you to have a separate table to keep track of the history of a bug each time it is (re)opened. The table would be in many-to-one relationship with the table of bugs and would likely have fields like:

• Opened Date
• Opened By
• Resolved Date
• Resolved By
• Time Spent
• How was resolved
• etc.

You may also need a similar table to track to whom and when the bug was (re)assigned, especially if you work in a big team.

I also suggest you take a look at existing systems. IMHO Jira is one the best issue tracking systems. It has very rich features, and you could use some of those as a guide for your own system.

The process of bug tracking is just as important as the data. Try to think about the following as well:

• How do Users report the bug?
• Who enters the bug into the repository?
• Who can confirm the bug exists?
• Who can confirm the bug is resolved?
• Who informs the end user that the bug is resolved?

Build a RACI Chart so everyone in your team (including end users knows their responsibilities. Combine this with proper data entry techniques and you will see a lot more value with the little extra effort.