Blogger of the Month: 3 Simple Reasons Why Your Bug Report Sucks

First, let me ask you a few questions.

Are your bugs often rejected? Are your bugs often assigned back to you and discussed back and forth to clarify information? Do your leaders or managers often complain about your bugs?

If the answer is YES, chances are your bug report sucks.

In this post today I will point out 3 simple reasons causing bad bug report and how to fix it.

Sounds cool right? Let’s start with…

Reason #1: You underestimate the importance of reporting a bug

I’ve been in testing for several years and I’ve seen one problem:

As a tester, you pay too much attention to bug finding.

“Hey, what’s wrong with bug finding? I’m a tester and my job is to find the bug?” you might ask.

No, nothing wrong with that, it’s just this: You pay less attention to bug reporting.

What’s the point if you do testing and find bugs, but you don’t want to report or report them poorly?

It doesn’t sound right, right?

Now, let’s take a few seconds to recall us about the goal of software testing.

Definition from Wiki:

“Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test.”

Also, from Michael Bolton:

“Testing is not quality assurance, but acts in service to it; we supply information to programmers and managers who have the authority to make decisions about the project.”

It’s clear that as a tester, you are not only doing testing, but you are doing a service. Your service is to provide as much information about the system under test to your customers.

“Who are my customers? In other words, who are my bug report readers?”

It depends on the project or the shop you are in. However, more often, the following people need and read your reports:

Your managers: They need your report to have an overview of the status of the system under test so that they can plan the work or make a Go/ No Go decision.

Your developers: Well, developers may not love you guys testers, but they surely need your bug report so that they can fix the problem accordingly.

Your peers: Your peers need your bug information so that they can refer to it, search to know more about the system, and avoid duplicates before submitting a bug.

You see? There are many people relying on your bug report to do their job properly.

If you fail to identify who your customers are and why they need your service, you fail to be a tester.

Reason #2: You report the invalid bugs

Tell me if this sounds familiar to you:

You spent hours to find a bug.

You were quite sure that your bug was great.

You opened a bug tracking system and reported it right away.

And then…

You bug was coldly rejected as Invalid.

How come? Your bug is invalid because:

It’s how the system is designed and you assume that’s a bug or it’s a duplicate and your peer has reported it before. Needless to say, reporting an invalid bug is a total waste.

By reporting an invalid bug, you are not only wasting your time but also your manager’s time to review it.

Reason #3: Your bug is unable to be reproduced

I see testers making this mistake a lot.

Your bugs sound great and valid, but the only problem is that: “IT’S UNREPRODUCIBLE”

Why? Because you might have missed one important step to reproduce the problem.

How can this happen?

Chances are that you didn’t double check your steps to reproduce before hitting submit button

Chances are that you did double check your steps, but you didn’t follow EXACTLY the steps you wrote. You double checked the steps based on your understanding of the bug and you assumed people having the same understanding as yours.

If the bug can’t be reproduced, there’s no way to get it fixed.

4 tips to have a quality bug report

“Okay, now I know why my bug report sucks, how can I fix this?”

To fix this, I would suggest focusing on these 4 key things in your bug reporting.

Tip #1: Your summary

Most of customers including your managers, developers, and peers will read the summary first when they review a bug. This is especially true when they have more bugs to review.

The simple reason is that they don’t have enough time to go into details of every bug, so having a short and concise summary will surely help to grab an idea of what the problem is about and how important it is.

You can have a short and concise summary by telling exactly what problem you found and in what condition.

Don’t write your summary like this:

“System crashes.”

Write this instead:

“System crashes when users login and logout.”

Don’t write like this:

“The camera does not work properly.”

Write this instead:

“The camera preview is blurred when taking picture in dark room.”

I can give more examples, but you got the idea right?

Be short and concise. Focus on what problem you see and in what condition.

Of course, you have no way to tell everything in your bug summary. That’s why you need the following…

Tip #2: Your bug description

Bug description is very important because it is where people will go and look into the details to see and fix the problem.

So, what’s in a bug description?

1) Precondition: Describe what people need to prepare before reproducing the bug such as a specific OS, Browser version, Support device, Networks, etc. This will ensure that people have necessary environments and conditions to reproduce the bug.

2) Steps to reproduce: Describe step-by-step how to duplicate the problem.

You don’t have to tell a long story here. All you need is a clear, step-by-step instruction to take people right to the problem.

Remember how you tell the way to someone on the street? This is exactly the same.

Warning: Don’t make your steps too detailed. E.g. you don’t have to write like this:

  1. Click Start button.
  2. Go to All Program.
  3. Click on [Program Name].

If the team doesn’t need this level of details, you can simply write:

Launch [Program Name]

Also, please be specific about what and where exactly people look at or do to see the problem. Don’t let user have to guess. Be specific.

3) Expected and Observed result: You tell exactly what you observed and your expectations to reason why you think it’s a bug.

Tip #3: Focus on the language you use

Many testers complain that their bug reports suck because they are not good at writing or English is just their second language.

This is a fair excuse, but does not convince me entirely.

No, you don’t need to take a writing course, to be the “next-Hemingway,” or to be a native English speaker to write a bug report effectively.

All you need is to use simple English (as simple as possible) words to describe the problem.

TIP: If you can find a simpler word that has the same meaning, use it. This will help you avoid misinterpretation issue.

You can also create a simple guideline, an instruction or whatever you would like to call it, in which you describe common terms and definitions used in your projects. By doing this, all team members will share the same understanding of the same word or phrase.

“Say what you mean and mean what you say.”

Tip #4: Over-provide

Like I said in the earlier part of the post:

As a tester, you are not just testing, you are providing services and one of the tips of doing services is to “over-provide.”

Let me tell you a story:

A few weeks ago, I had some problems with my website and I contacted my hosting provider to clarify some of my questions. My questions were clarified clearly. What I loved about the service so much was that they not only answered my questions but also provided solutions which I hadn’t thought of to help me better. Of course, I was totally satisfied with this support service.

As a tester, when you report a bug, you should do exactly the same as that hosting service provider. Before clicking the submit button, go extra miles and ask yourself:

What other information can I add to help “my customer” understand the bug better?

You can try the following ideas (it works for me just fine):

  • How about sending a separate email to managers/team to notify about the bug if the bug is critical and needs to be addressed immediately?
  • How about attaching log files, screenshots or videos of the problem?
  • If your problem is about a system crash, you can provide a workaround information to help users correct the issue and continue with the work.
  • If you know the root cause of the problem, you can suggest technical solutions for developers.
  • It might take you a little more time to do this extra service but you know what? It really pays off.

I have just shared with you 3 simple reasons why your bug report is bad and 4 ways to fix it.

Now, let’s recap:

You don’t have a good bug report because:

1) You don’t see the importance (this is very important).

2) You report the wrong bug.

3) You report it poorly.

I also suggest 4 ways to fix it:

1) Focus on the summary to make it short and concise. The summary will tell exactly what problem you see and in what condition. This is important because the summary is the first place people read your bug.

2) Your bug description. You must describe the problem exactly and clearly. Re-read and follow your steps again and again before submitting.

3) Use simple and concise words to describe the bug. Say what you mean, mean what you say.

4) Over-provide. Consider adding more information to bug to help readers understand it better.

Bug report checklist

Now, the good news is that you don’t have to remember all these things. I have created a simple checklist for you to cover these points.

You can print it out, stick it to somewhere you can refer to it easily when reporting it.

BONUS: Click here to download the checklist. It’s FREE.

Note: My checklist is just for reference, of course, you need to add or delete where necessary.

Final Thoughts

Software testing is not all about the bug report, but having good bug reporting is game-changing. You don’t have to be passionate to report a bug effectively. You just need to recognize its importance and have enough interest to care about reporting a bug. It needs a little bit of practice to do that job well, but it’s worth the practice. Hopefully after reading this post, you can write outstanding bug reports that everyone loves it.

Thanh Huynh

Thanh Huynh is a tester who runs a site called AskTester. He has several years of experience in testing,managing and leading testing projects. He looks for customer satisfaction, sustainability, and cost-effectiveness in his testing work. AskTester is for a community of professional testers where they can freely ask questions about testing, voice their opinions, and share interests.

Thanh Huynh
Thanh Huynh is a tester who runs a site called AskTester. He has several years of experience in testing,managing and leading testing projects. He looks for customer satisfaction, sustainability, and cost-effectiveness in his testing work. AskTester is for a community of professional testers where they can freely ask questions about testing, voice their opinions, and share interests.

The Related Post

Test organizations continue to undergo rapid transformation as demands grow for testing efficiencies. Functional test automation is often seen as a way to increase the overall efficiency of functional and system tests. How can a test organization stage itself for functional test automation before an investment in test automation has even been made? Further, how ...
As I write this article I am sitting at a table at StarEast, one of the major testing conferences. As you can expect from a testing conference, a lot of talk and discussion is about bugs and how to find them. What I have noticed in some of these discussions, however, is a lack of ...
Test design is the single biggest contributor to success in software testing. Not only can good test design result in good coverage, it is also a major contributor to efficiency. The principle of test design should be “lean and mean.” The tests should be of a manageable size and at the same time complete and ...
People who follow me on twitter or via my blog might be aware that I have a wide range of interests in areas outside my normal testing job. I like to research and learn different things, especially psychology and see if it may benefit and improve my skills and approaches during my normal testing job. ...
Introduction All too often, senior management judges Software Testing success through the lens of potential cost savings. Test Automation and outsourcing are looked at as simple methods to reduce the costs of Software Testing; but, the sad truth is that simply automating or offshoring for the sake of automating or offshoring will only yield poor ...
VISTACON 2010 – Keynote: The future of testing THE FUTURE OF TESTING BJ Rollison – Test Architect at Microsoft VISTACON 2010 – Keynote   BJ Rollison, Software Test Architect for Microsoft. Mr. Rollison started working for Microsoft in 1994, becoming one of the leading experts of test architecture and execution at Microsoft. He also teaches ...
Trying to understand why fails, errors, or warnings occur in your automated tests can be quite frustrating. TestArchitect relieves this pain.  Debugging blindly can be tedious work—especially when your test tool does most of its work through the user interface (UI). Moreover, bugs can sometimes be hard to replicate when single-stepping through a test procedure. ...
In today’s mobile-first world, a good app is important, meaning an effective Mobile Testing strategy is  essential.  
Reducing the pester of duplications in bug reporting. Both software Developers and Testers need to be able to clearly identify any ‘Bug’, via the ‘Title’ used for the ‘Bug Report’.
Experience-based recommendations to test the brains that drive the devices In essentially every embedded system there is some sort of product testing. Typically there is a list of product-level requirements (what the product does), and a set of tests designed to make sure the product works correctly. For many products there is also a set ...
  Explore It! is one of the very best software testing books ever written. It is packed with great ideas and Elisabeth Hendrickson’s writing style makes it very enjoyable to read. Hendrickson has a well-deserved reputation in the global software testing community as someone who has the enviable ability to clearly communicate highly-practical, well-thought-out ideas. ...
I’ve been intending to write a book review of How We Test Software At Microsoft, by Alan Page, Ken Johnston, and Bj Rollison, but for whatever reason I just never found the time, until now. In general, I like this book a lot. It’s a nice blend of the tactical and the strategic, of the ...

Leave a Reply

Your email address will not be published. Required fields are marked *

Stay in the loop with the lastest
software testing news

Subscribe