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

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 ...
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 ...
Alexa Voice Service (AVS): Amazon’s service offering for a voice-controlled AI assistant. Offered in different products. Source: https://whatis.techtarget.com/definition/Alexa-Voice-Services-AVS Autopilot Short for “automatic pilot,” a device for keeping an aircraft on a set course without the intervention of the pilot. Source: https://en.oxforddictionaries.com/definition/us/automatic_pilot Blockchain Infrastructure: A complex, decentralized architecture that orchestrates many systems running asynchronously over the ...
Introduction This article discusses the all-too-common occurrence of the time needed to perform Software Testing being short changed as specification, development, and unforeseen “issues” cause the phases prior to testing to expand. The result is that extreme pressure is placed upon the testing organization to perform the testing function within a reduced time frame. The ...
Last week I went to StarWest as a presenter and as a track chair to introduce speakers. Being a track chair is wonderful because you get to interface more closely with other speakers. Anyway…one of the speakers I introduced was Jon Bach. Jon is a good public speaker, and I was pleasantly surprised that he ...
Internet-based per-use service models are turning things upside down in the software development industry, prompting rapid expansion in the development of some products and measurable reduction in others. (Gartner, August 2008) This global transition toward computing “in the Cloud” introduces a whole new level of challenge when it comes to software testing.
Differences in interpretation of requirements and specifications by programmers and testers is a common source of bugs. For many, perhaps most, development teams the terms requirement and specification are used interchangeably with no detrimental effect. In everyday development conversations the terms are used synonymously, one is as likely to mean the “spec” as the “requirements.”
This article was originally featured in the July/August 2009 issue of Better Software magazine. Read the entire issue or become a subscriber. People often quote Lord Kelvin: “I often say that when you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot express ...
Introduction Software Testing 3.0 is a strategic end-to-end framework for change based upon a strategy to drive testing activities, tool selection, and people development that finally delivers on the promise of software testing. For more details on the evolution of software testing and Software Testing 3.0 see: Software Testing 3.0: Delivering on the Promise of ...
LogiGear Magazine March Issue 2018: Under Construction: Test Methods & Strategy
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 ...
Internet-based per-use service models are turning things upside down in the software development industry, prompting rapid expansion in the development of some products and measurable reduction in others. (Gartner, August 2008) This global transition toward computing “in the Cloud” introduces a whole new level of challenge when it comes to software testing.

Leave a Reply

Your email address will not be published.

Stay in the loop with the lastest
software testing news

Subscribe