What Developer Needs From a Bug Report?

Really – what information should be mentioned in a bug report? Yes, you know about these things with High, Highest, OurBusinessHasBeenDestroyed priorities and severities, everyone knows about them. But does anyone know what is really needed from a bug report? I had a nice time working as a QA engineer at the start of my career and I’ve learned some things that, combined with what I learned while being a developer and mixed with what I’ve read about, form this post.

Let’s all become goal-oriented and define a goal of any bug report. The final goal of each bug report is to eliminate the bug this report was written about. It doesn’t matter whether it will be fixed or considered not a bug but feature – the bug should be eliminated anyway.

The key to problem solving lies within understanding the problem. In case of a bug, bug report is used for that. Thus, it should contain all necessary information for understanding the problem. Two possible sides of detailing report are simplicity and complexity.

What’s the simplest bug report should contain? It should contain the description of the problem, it’s application. It’s like a smell. If someone enters a room with a nice perfume – you’ll smell it. The simplest bug report should just describe this smell. This way developer will have to spend much time reproducing the problem.

What’s the most complex bug report should contain? It should contain info about:

1. Full description of bug, and more strange bug gets, more details QA should provide
2. When did it appear, with millisecond precision?
3. What actions caused it?
4. Where was QA located in application map - page, screen, etc.?
5. What environment caused the bug - OS, browser?
6. Did QA do anything unusual before detecting the problem?
7. What context produced this bug? Maybe it was during version update or hacker attack?

It should also contain information on how to reproduce – that’s very important. Describing steps for reproducing a bug is not easy at all:

1. It should contain conditions that make the bug happen
2. It should not contain conditions that do not affect bug appearing
3. It should contain conditions on how to avoid bug

Moreover, instead of describing problem implications only, complex bug report should suggest problem roots. Yes it’s much harder but damn we’re talking about complex report! QA should analyze provided problem implications and suggest what could cause the problem.

Yes, complex bug report really differs from a very simple one – but using it for bug solving will be much easier and you’ll always get positive feedback from a developer. However, you should be aware of the 80/20 rule: 20% of work takes 80% time and vice versa. This means that you should always consider all options and just think – some information is much easier to get for developer, not QA. Don’t waste your time thoughtlessly – you may reach 90% complexity and this will be enough.

Test thoroughly and report well :)

UPDATE: updated bug description criteria to be more specific.