How do you write a great bug report? [closed]

Question

"Is this going to be a stand-up fight sir, or a bug hunt?" - Hudson

I've always wondered what the secrets were to writing a great bug report. Over time I've narrowed down the activity to three basic elements.

1. Replicate: Once you've found the bug, replicate it.
2. Document: Write it down, pack in detail where necessary.
3. Communicate: Input it into the bug tracker and tell someone.

Replicate - Clearly this is the most hated step because you just made something break, why should we break it again? Unfortunately, it's part of the process. Bugs that are repeatable often give the development/implementation team a very clear view into what might be going wrong. A bug that happens one time can be very hard to track down. So, your first step if you find something wrong is to try and make it happen again. This is why it's critical that you mentally keep track of what you're doing and what you've clicked. Certain combinations can yield bugs, while others won't.

Document - The only thing worse than a bug is a bug without any details. For example, what's wrong with the following bug report?

My order failed. I think it is broken.

Aside from the fact that your order failed, there's no detail! Examples of very excellent detail:

• Steps to repeat the bug (see Step 1)
• What you were expecting vs. what you got
• Error messages that appear on the page
• What browser/operating system were you using

So if you were to rewrite the bug like the following - this will make it easier for the implementation team to investigate and solve the issue:

I'm using the following: OS: Mac OS X (10.4.9) Browser: Firefox 2.0.0.3

My order for a snuggle puppies on yoursitehere.com wouldn't go through and I'm not sure why. When I try to place the order, I end up on the order entry page with the following error message: "We're sorry, our records indicate another order has already been placed...." I was expecting to end up on the receipt page with a confirmation message and with a confirmation email in my inbox and instead I'm getting an error.

Try the following steps:

Your steps here

Communicate - In order for a bug to get corrected, the implementation team needs to know about it. This doesn't end up being as plodding as it sounds. But the sooner you let your primary developer/project manager/testing know the sooner it can be put into the queue to be fixed.

This is how I've done it ... but what makes a great bug report in your mind?

Answer 1

I document the following:

1. What I think the problem is. Sometimes this can be tricky, and if I'm not certain, I'll talk to someone about the functionality before submitting it.
2. What do I think the expected result should be? Again, tricky. See #1.
3. Steps to reproduce. The easiest way to a developers heart is to provide detailed easy to follow instructions on how you reproduce the problem.
4. I attach any log files I have and trim them down to only the relevant information.
5. Attached database backup or virtual environment ready to go.

Answer 2

1. A clear title - I want to be able to be able to tell at a glance without going into the report itselt what I am looking at.
2. Description of the bug - this should be as concise as possible.
3. Reproduction steps. You should be able to reproduce the bug and hopefully have narrowed it down to the simplest possible steps.
4. Environment considerations (OS, browser, hardware) that are relevent.
5. Any additional materials that make digging into the problem easier (stack traces, logs, script files, specific data sets, screen shots).

Answer 3

A bug report should include as many details as possible. But keep in mind that it should not bog down the tester from creating them if it involves lot of effort from their part.

A good template should contain Title (Short and descriptive), Build No, Requirements Reference (Optional), Problem Description, Expected results, Steps to reproduce, Analysis (Optional).

In addition, the Test manager should update other attributes like, target build (for which this should be resolved), Internal Priority, Customer Severity (if this project is for a client), Project Identifier (If the project has multiple releases).

Be aware, that asking a tester to set the Internal priority or customer severity would require explaining lot of managerial aspects of the project.

Answer 4

A great bug report gives the information to the developer that they need to fix the bug, with as little extra as necessary.

Unfortunately, you can't rely on testers to always know what is necessary and what is not, so I would have them err on the side of caution and include as much detail as possible about what they were doing, as long as they keep it cohesive. A good developer will be able to sift through it (assuming the report was written cohesively) to find the information he really needs to fix the issue.

Most bugs are simple fixes, and for the most part are simply a misunderstanding of the requirements. It's finding what simple fix to make that is the headache.

If the tester is able to find specifically which requirement isn't being fulfilled, it should help the developer out a lot.