Communication is key element for successful projects. So, you should report bugs properly to eliminate them and you should be very careful describing them. There are some mandatory elements that should be supplied on bug reports, using some templates that provide enough information to let the developer know how to handle its solution and let him to know how to omit new bug creation. A good bug report should clearly display the right information, and we can classify them in three types, as functionality bugs, programming bugs and technical bugs.
Each bug type has its own format — I think — and they should provide the proper information to the development team to be corrected. So, those reports that are saying «does not works», simply should be avoided. The less information that you provide, the less clear is the bug report.
functionality bugs
They are related to those bugs that do not produce error screens, core dumps, or application crashes. They are only related to those bugs that allows the application to work, but they have the wrong implementation, disallowing the application to work properly. So, the information that should be supplied on those reports should be as follows.
- Bug Title, not more than 250 chars describing the bug.
- Bug Description, an extended explanation of the bug.
- Location, where it is produced (screen or URL).
- Bug Solution, how it should be solved (not technically speaking, but with a proposed solution).
- Steps to Reproduce, how you should reproduce the bug in your environment.
- Related Media, screenshots, videos, audio and related stuff that could allow the developer to have a clear idea about the bug.
As they at a very high level, they do not require technical details. So, this kind of bugs should be very well described to eliminate them. Also if you can attach a flowchart or similar diagram to let the developer to know how it should be fixed, or any diagram allowing a good understanding of the bug, it is a very good approach on how to fix it.
programming bugs
Well, if you the code has a bug, probably it will produce a visible error, that shall be reported and fixed quickly. So, you must provide enough information about them. When you are reporting bugs, you should have in mind at least three points: «how happens?», «when happens?» and «where happens?». That should be enough to allow the developer to solve the fourth point which is «what happens?». So, you should provide the following information.
- Bug Title, not more than 250 chars describing the bug.
- Bug Description, an extended explanation of the bug.
- Location, where it is produced (screen or URL).
- Backtrace & Technical Error, what is displayed on the screen or logs with a backtrace or similar kind of technical report.
- Bug Solution, how it should be solved (not technically speaking, but with a proposed solution).
- Steps to Reproduce, how you should reproduce the bug in your environment.
- Related Media, screenshots, videos, audio and related stuff that could allow the developer to have a clear idea about the bug.
technical bugs
It is related mainly to configuration issues, for example date formats and similar ones. And it should contain the same information as the programming bug, but it is different because it does not cause application crashes and stops the application work. But it is a bug and it should be solved. So, probably the priority of them is lesser than programming bugs. Just remember to always provide enough information to classify and reach the bug on testing.
Good article, but I disagree with the number of characters for the titles, when I see the list of bugs I don’t want truncated titles, I think 140 chars is more appropriate
[...] related to the bug, it should disappear. But also this requests that your QA team provides a good bug report. So, the standard MVC is not implemented any more, because you are not using a single data source [...]