3 Simple Reasons Why Your Bug Report Sucks (and How to Fix It)

First, let me ask you a few questions

Are your bugs often rejected?

Are you 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 that 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 under-estimate 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:

. . .and 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.” (Quoted from http://www.developsense.com/blog/2009/08/testing-vs-checking/).

It’s clearly 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, search to know more about the system and to avoid duplicate 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.
• It’s a duplicate. Your peer has reported it before.

Needless to say, reporting an invalid bug is totally a 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 that you didn’t double check yours steps to reproduce before hitting submit button

Chances 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 include your managers, developers, and peers will read the summary the first thing 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 the steps by steps 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 what’s your expectation 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 either to learn a writing course, to be “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, but having 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 in which you describe common terms and definitions used in your projects. By doing this, all team members will share the same understanding on 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 “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 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 like that hosting service provider. Before clicking submit button, go extra miles and ask yourself:

What else information I can 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, screenshot or video of the problem?
• If your problem is about a system crash, you can provide a workaround information to help user 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’s really paid 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 re-cap:

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 reference, of course, you need to add or delete where necessary

BONUS: Some Frequently Asked Questions about bug report:

Q. What’s the difference between bug Priority and Severity?

Severity: Telling how bad the problem from the technical perspective. The values could be:

• System crashes, data loss.
• Major Function breaks.
• Minor Function breaks
• Enhancement, Feature Request

Priority: Telling how urgent the problem needs to be fixed from the business perspective. The values could be:

• Urgent
• High
• Medium
• Low

More often the more severe the problem is, the higher priority..but not always.

Ex: If the system crashes and it’s blocking the entire testing. We have:

Severity -1 and Priority – Urgent

However if the system crashes, but it requires hundreds of steps which are unlikely user will do it or the crash is intermittent, so it’s not urgent to fix it. We have:

Severity-1 and Priority-Low.

Side-note: Severity is often decided by tester while Priority is decided by managers/stakeholders

Q. What tool to capture screenshot and recording video?

I’ve used some, but my favorite tool is Jing. It’s very simple and easy to use. Give it a try.

Q. What other information when reporting a bug?

• Summary
• Description
• Attachment
• Detected in Version
• Priority
• Severity
• Component
• Assigned To
• Status: New-Open-Fixed | Rejected |-Closed

Those are the most common fields in a bug tracking system you often have to fill in before submitting a bug.

Q. Do I need to write up a bug report or do I need just go and talk to the developers?

It depends on what model of your project is following and if your team members are co-located or distributed across the globe.

If your team is co-located, it’s best to communicate directly about the bug. However, if your team is distributed across the globe, writing a bug is recommended to keep track of the problem

Q. What are common bug reporting tools?

• Bugzilla
• QC
• JIRA
• TestLink
• Unfuddle
• Rally
• Redmine
• Mantis

There are more tools out there, but those are the most common and powerful ones

Q. When reporting bugs, do I need to report it quickly or I need to fill all information.

Check out this similar question: https://asktester.com/questions/bug-raise-them-fast-or-raise-them-with-full-information/

There are many great responses there.

FINAL THOUGHTS

Software testing is not all about bug report, but having a good bug reporting is a game changing part. 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 a practice. Hope after reading this post, you can write outstanding bug reports that everyone loves it.

Like What You’ve Read?

Subscribe now to be updated on future posts!

Email Address