Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Maintaining bug database is an important for every project. I am used to store the followings at bug database
Is those enough to maintain a good bug database?
A good bug database may have the followings
// Date Time Related
// Assigned By + To
// Bug behavior
// Priority
// Link, Status and Others
EDIT: I also want to recommend
EDIT: I like @jgauffin's comment
EDIT: A good bug database system also maintains
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:
DateTime of Bug/DefectDateTimeDateTime - when a bug is resolved and closedEdit: 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:
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:
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:
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.
