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.
“Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test.”
“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:
- Click Start button.
- Go to All Program.
- 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
