What Makes Your Bug Report PERFECT?

We live with bugs! Yes, everything revolves around a bug for us software testers. Whatever we talk, measure, find, Report are all in terms of bugs. But, do we actually know how much responsibility lies in our hands when we find a bug? How much contribution we are making towards the Product we are testing to make it usable by millions of people across the globe? A ‘Bug’ is the only way we communicate with our client to tell them what is missing or what is wrong with their product. So, when you submit a bug, you are not actually breaking the product to see how well you are at it! Instead, you are helping the product to be perfect.

So, just submitting a bug is not enough. You need to understand what we have submitted as well. I have heard lot of new joiners tell this- “What big deal in submitting a bug? We have a readymade defect logging template, we just fill it and so a bug is logged”. Should this be the attitude, then we can log millions of bugs in a single day! But, just submitting hundreds of bugs and increasing your bug count is not enough.
Will you be called a good tester if you only have your large bug count? NO- You also need to make the developer understand your bug. What’s the point if you just submit it and there is no one who can solve the problem? All your effort of finding the issue is gone waste. Suppose, you logged a bug which breaks a major functionality but while writing your report, you missed out some info which says in which area the bug was caused. Can anyone understand? Will they be able to solve it? It will either be rejected as improper info or will be assigned back to you. It will just result in a waste of time for you as well as developer.
And, if it’s a major issue then imagine how much impact it could have on the business, on the client? And, of course your job
There is no perfect mantra for a good bug report. The basic point here is you should be able to convey the issue to the developer in a proper manner and with all the data so that it will be solved easily. Below are some of the ‘ingredients’ of a good bug report.
Bug reports usually consist of a bug title, the steps, and a screenshot. But, it can be made more helpful if you add a couple of points more:

A bug report should go like this:

#1 Bug Title:

This should be a short (Just about a line) and easy to understand description of what exactly the problem is. It should ideally describe the area in which the bug is along with the error message if any. For example, if there is a bug in the Installation of a product when you select custom install, your bug title should be something like- “Error during custom install” or “Product fails to install, gives 1234 error when custom installation”. The second one would be more apt as it also describes your error code. But, if the error code is very long, try avoiding it in the title, you can write the same in description

#2 Repro Steps:

The repro steps or the reproducibility steps are the most important in a bug report. These steps tell you how you would arrive at the problem. They should be steps from the start of what you did to arrive at this problem. Here, generally we tend to avoid some simple steps which we think are not necessary. But, no step is unimportant. Yes, but also avoid duplicate steps.
Example of repro steps would be-

1. Install app
2. Go to fileàopen
3. Give a file name
4. Click on cancel
5. Observe the error

Do not forget to mention where the problem is. That means, don’t just leave the steps as it is. Tell them where you encountered the problem. Also, mention any pre-requisites installed before performing these steps. Do not make the steps repeatable and lengthy.

#3 Actual and Expected Results:

This will describe what is the actual result got and what is the expected result of the issue.

#4 Description:

This might or might not be necessary. It depends if you have some issue that requires explanation like a long error message of any special note.

#5 Priority:

How important the bug is, and how soon it should be resolved.

#6 Severity:

How severe the problem is.

#7 Frequency:

How frequent the issue occurs. For ex- every time, only once etc.

#8 Environment info:

This is your system info like OS version, Browser used (if it’s a Web app), any updates installed on top of it, Flash version if required etc.

#9 Screenshot:

When you give the screenshot make sure you Highlight the area where you think the bug is. This would be very helpful while logging UI bugs. The developer will be able to understand where actually the bug is if the issue is very small to detect otherwise. Naming your screenshots according to the issue would also be a good idea here.

#10 Additional Info:

This will be any additional info like what do you think might cause the problem. Or, if the issue is browser/OS specific.
The basic point to remember while you are submitting a bug is – ‘The person who is reviewing your bug should understand the bug, and in one way it should also help him in solve the problem’. Also, make sure you are not “bugging” the developer too much!! After all, he is also a busy man like us