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

This article was developed from concepts in the book Global Software Test Automation: Discussion of Software Testing for Executives. Quality cost is the sum of all costs a company invests into the release of a quality product. When developing a software product, there are 4 types of quality costs: prevention costs, appraisal costs, internal failure ...
When it is out of the question to delay delivery, the solution is a prioritization strategy in order to do the best possible job within the time constraints. The scenario is as follows: You are the test manager. You made a plan and a budget for testing. Your plans were, as far as you know, ...
David S. Janzen – Associate Professor of Computer Science Department California Polytechnic State University, San Luis Obispo – homepage LogiGear: How did you get into software testing and what do you find interesting about it? Professor Janzen: The thing I enjoy most about computing is creating something that helps people. Since my first real job ...
I’ve been reviewing a lot of test plans recently. As I review them, I’ve compiled this list of things I look for in a well written test plan document. Here’s a brain dump of things I check for, in no particular order, of course, and it is by no means a complete list. That said, if you ...
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. ...
People rely on software more every year, so it’s critical to test it. But one thing that gets overlooked (that should be tested regularly) are smoke detectors. As the relatively young field of software quality engineering matures with all its emerging trends and terminology, software engineers often overlook that the software they test has parallels ...
March Issue 2019: Leading the Charge with Better Test Methods
This article was originally featured in the May/June 2009 issue of Better Software magazine. Read the entire issue or become a subscriber. In my travels, I’ve worked with a number of companies that have attempted to assess the quality of their testing — or worse, their testers — using poorly considered metrics. Sometimes the measurement ...
Please note: This article was adapted from a blog posting in Karen N. Johnson’s blog on July 24, 2007. Introduction The password field is one data entry field that needs special attention when testing an application. The password field can be important (since accessing someone’s account can start a security leak), testers should spend more ...
In software testing, we need to devise an approach that features a gradual progression from the simplest criteria of testing to more sophisticated criteria. We do this via many planned and structured steps, each of which brings incremental benefits to the project as a whole. By this means, as a tester masters each skill or area ...
There are many ways to approach test design. These approaches range from checklists to very precise algorithms in which test conditions are combined to achieve the most efficiency in testing. There are situations, such as in testing mobile applications, complex systems and cyber security, where tests need to be creative, cover a lot of functionality, ...
Jeff Offutt – Professor of Software Engineering in the Volgenau School of Information Technology at George Mason University – homepage – and editor-in-chief of Wiley’s journal of Software Testing, Verification and Reliability, LogiGear: How did you get into software testing? What do you find interesting about it? Professor Offutt: When I started college I didn’t ...

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