Principles of Good Bug Reporting

Reporting a good bug is not hard, but many times we do it hurriedly and without putting our full attention into it. As in the case above, the results of a badly written bug are 3-fold:

1. You waste your time reporting a bug incorrectly and most certainly will need to re-write it.
2. You waste the time of the other people reviewing the bug and trying to make sense of what you wrote.
3. You harm your good name as a QA Professional, by writing a bug that is either correct but incomprehensible or altogether wrong.

What are the components of a Good Bug?

1. Short and precise title
Each bug should have its individual title. The title gives us the opportunity to quickly understand and remember what the bug is all about.
The title cannot be generic (e.g. Error on Application), or too long. It should be one sentence, providing the highlights of the issue and the way to understand how a user could run into it.

Examples of good and bad titles are (taken from actual bugs!): “Unable to log into the system when username contains foreign characters” and not “User cannot work in Chinese”; or “Log rotation doesn’t work, grows until the disc runs out of space” and not “Server crashes due to log size”.

2. Concise but complete description: Steps to reproduce, consequences of the bug, and suggested behavior
The description of the bug is where the tester can express his “artistic sense” and write what he thinks will help stakeholders to understand and handle the bug.

The most important things to include in the bug are:
i. Steps to reproduce – with all the steps, sometimes even the trivial ones, just to make sure people who need to judge the bug and are not experts in the system can understand it correctly. Make sure to include also the data required to reproduce it (e.g account names, strings, etc).

ii. Consequences of the bug – what will happen to the user if/when she runs into it.
Here again, sometimes it is trivial but other times it isn’t and you need to make sure this information reaches the person who is reading your report.

iii. Suggested/Expected behavior – especially when you are reporting a bug that doesn’t create data-loss or other catastrophes, but on the other hand makes the application uncomfortable or unusable to the end-user.

The description is the place where you can add all the information that you cannot write on any other place, but on the other hand you cannot write to much into it (and expect people to read it) or write irrelevant information.

As a rule of thumb, 3 to 10 lines should be enough in 80% of the cases.

3. Good attachments
Specially true when you need to show GUI malfunctions, error messages, and/or log files that compliment the description of your bug.

One thing to take into account is to provide ONLY the relevant information in your attachment. This means that if you have a long log file attach only what you know is relevant and not all of it, if you have a screen capture cut down the area that is relevant and not all the desktop if it is unnecessary, etc
Use also zip files and compressed formats in order to save space.

4. Complete definition of the categorizing fields
If you work with a Structured Bug tracking system you will have fields that categorize your issues. Examples of these fields are Module, Infrastructure, Browser, etc.

This fields will help your team to categorize and in some cases reproduce the bug correctly. The only reasons not to fill this fields laziness or carelessness.

5. Correct Severity & Priority Another big Tester Sin is to over prioritize your bugs. Obviously you are happy you found a bug and you want it fixed, but giving it the wrong severity will only make the person in charge of the bug angry and it will lower your chances of having this bug fixed.

You will also automatically harm your name with this person and from now on she will be skeptic whenever you report a critical issue (remember “the boy who cried wolf”…)

If your problem is that you are not sure what severity to give your bug you can either consult with a fellow tester or developer, or ask you lead for a table describing the cases and standards used in your company for this purpose.

6. Follow-up and comment.
You should continue following up on your bugs, and providing comments when necessary. This is specially true when a developer or other stakeholder does not understand the bug, and either rejects it or delays it.

You are not the owner of your bugs, but you certainly have say on them and you should make sure that say is heard.
Depending on your company this last point may not apply, but I think in most companies it does.