Submitting bug reports is a very important part of being a software tester, and there are countless resources that have been generated to help people get better at it. Naturally, I’ve also covered it in my beginner software testing book. Much as you’d expect, I cover many of the things that I think you should include in a good bug report, and important steps to take in investigating bugs before you submit them.

However, in my opinion, the most important part of submitting a bug report doesn’t concern knowing what belongs in it or what to do. Rather, it revolves around words like “care” and “effort”. Almost everybody knows what belongs in a bug report, at the very least they do after they’ve read a good blog post or chapter on the subject. And yet, if you’ve been in the industry for five minutes, you’ve seen examples of bad bug reports from people that should really know better. So the main emphasis of this chapter in my book? Take care. Put the effort in, do the investigation, check the reproduction steps, add the logs, imagine what might be misunderstood and what questions other team members might ask when they see it.

Why? Because if you do that, people will like you. People will like you because you’ll be doing a good job, and making their lives easier. You’ll learn more about the product, you’ll be respected, you’ll be practicing the kind of skills (effort, diligence, competence, teamwork) that will help you progress in your career, and other people might actually want you to succeed because you didn’t make their lives harder. Do put the effort in.

It's a great bug, but a little more information about how on earth you managed it would be helpful...

In my opinion, if you’re a brand new or aspiring software tester, you could do a lot worse than aim to make submitting bug reports the thing you do best. You’ll do that by going the extra mile on those bug reports, not just by patting yourself on the back because you “know” what belongs in the report. Sure, you could save time on the report and get onto completing more tasks, but some jobs are only worth doing if you’re going to do them well, and for me, this is one of them.

I’ve included the complete chapter below for anybody that would like to see it. I’d love to hear what you think! Similarly, if you know anybody that is seriously thinking about making the switch into software testing, or still in the very early days, I’d love to hear from them. I’ve had one beginner tester read what I have from end to end, but some more feedback from the kind of people I’m hoping could benefit most would be really useful.

Related articles