What is a Bug Report?

if you’re new to bug tracking, issue management, or web development in general, you might wonder what a bug report is.

in this blog post, i try to answer this question from different viewpoints. and trust me, it’s not going to be boring.

we always talk about bug reports…

… but never explain what they are.

i just noticed that we at usersnap haven’t answered this core and essential question.

we’ve more than 1.000 sites indexed by google, published 183 blog posts on our blog , have written multiple guest posts on other sites, and gave some talks on the do’s and don’ts of bug tracking .

however, we haven’t answered this core question... not even once. though, we did cover a lot of topics in the area of bug reporting.

for example, i’ve shown you 6 easy bug reporting tricks , answered the 4 w’s of bug reporting , and gave you some insights on bad bug reports . i’ve even shown you how to set up a bug-free web development environment.

nevertheless, i haven’t answered the simple–yet important–question of what a bug report actually is.

but today, i am finally tackling this issue. ready?

what is a bug report?

so, let me answer the question “ what is a bug report? ” for you.

in order to answer this question, we need to understand the following concept of bugs, bug reports, and bug reporting software.

what is a bug?

in the context of software development, engineering, or web development, a bug is not—despites its name—a little insect, but something else entirely.

according to wikipedia a software bug (or just a bug) can be defined as:

“a software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result or to behave in unintended ways.”

so in short, this means:

a software bug is an error, flaw, failure, or fault that produces an incorrect or unexpected result.

basically, a software bug is something which is not working as designed .

why is called a bug then? the origin of a bug.

you might wonder, why a bug is called a bug? it’s a great question, because the term bug, describing an software error or failure goes way back to 1945. in late 1945, at the university of harvard, a technical team found something unusual between points in relay70. the found a real dead bug (the insect) which caused an error.

as stated in the bug log, it’s the " first actual case of a bug being found ."

so, in theory, a bug is something not working as designed .

but, what if something is not designed as it should be? is it a bug then? as you can see, this question alone leaves a lot of room for interpretation.

no matter if you’re a developer, designer, or user of a software, chances are high that you’ve stumbled upon a bug in the past, or maybe you even caused a bug yourself.

what is a bug report?

so, here’s the core question: 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.

according to yegor , a bug report " should explain how exactly the product is broken. "

he continues that a bug 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? however in practice a bug report and what documentation is included isn’t that clear.

imagine you encountered a bug and wanted to send in a bug 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 reports

so, you might wonder, what’s the difference between a good bug report and a bad one. and, why are there so many bad bug reports out there?

i collected some statements about this issue in order to distinguish between the two of them:

• a good bug report contains the information needed to reproduce and fix problems
• a bad bug report does not contain the information needed to reproduce and fix problems
• a good bug report is an efficient form of communication for both bug reporter and bug receiver
• a bad bug report is a lengthy, inefficient form of communication for everyone involved
• a good bug report is resolved as fast as possible
• a bad bug report never gets resolved
• a good bug report is sent to the person in charge
• a bad bug report isn’t filed at all
• a good bug report is on point
• a bad bug report contains no specific information
• a good bug report is filed in the defined way
• a bad bug report is filed in any medium available, but not in the defined way (little hint: twitter isn’t a good way to file a bug report)
• a good bug report establishes a common ground of collaboration
• a bad bug report doesn’t enable collaboration

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 a software or on a website. and in the best case scenario: this is done in the most efficient manner possible.

i’ve created this bug reporting checklist in order to get a feeling on what questions a bug report must answer.

wrapping it up.

all in all, i’ve shown you the basics of bugs, bug reports and bug reporting systems. there are a lot of further do’s and don’ts when it comes to the bug reporting workflow, from bugs, to no bugs .

this post orginally appeared at the usersnap blog .

follow me on twitter @tompeham or @usersnap for further updates on bug reporting.