What is a bug report?
If bugs occur (which they certainly do), the person finding the bug should be able to report (document & send) the bug to people in charge of fixing that error or failure.
A bug report “should explain how exactly the product is broken.”
The report should follow this simple formula:
“This is what we have, this is what we should have instead, so fix it.”
This sounds easy, right? In practice though, a bug report (and what documentation is included) isn’t that clear.
Imagine you encountered a bug and wanted to send in a report.
What information would you include? I guess everyone would answer that differently.
In the past, bug reports were lengthy forms including various fields and data requests. What’s the priority of the error? What’s the problem description? What are the components? Which browser version are you using? And so on…
Good vs. bad bug report
So you might wonder, what’s the difference between a good bug report and a bad one. And why are there so many bad ones out there?
Here there ar some statements about this issue in order to distinguish between them:
A good bug report :
- It contains the information needed to reproduce and fix problems
- It is an efficient form of communication for both bug reporter and bug receiver
- A good bug report is sent to the person in charge
- A good bug report is filed in a predefined way
- Establishes a common ground for collaboration
A bad bug report :
- A bad bug report does not contain the information needed to reproduce and fix problems
- Lengthy, inefficient form of communication for everyone involved
- A bad bug report never gets resolved
- Contains no specific information
- Gets filed in any medium available, but not in the defined way
So, how would I sum up my answer to the question: “What is a bug report?”
A bug report is something that stores all information needed to document, report and fix problems occurred in software or on a website. And in the best case scenario: This is done in the most efficient manner possible.