Tips for writing a great bug report, advice from a QA tester

As part of our Ask a Tester series, we feature QA experts from our network who share with us their experience, expertise, and perspective on software testing. Writing a good bug report is a skill that our tester Dina excels at, so we asked her to share some of her best practices and tips.

About Dina

Dina is from Lviv, Ukraine. She has been with Testlio since 2015 and enjoys working as a freelance software tester. As a classically trained professional pianist, she appreciates the power of diligence and hard work.
In her spare time, she loves gardening and spending time with animals – her house is filled with plants of all sizes and she has two little guinea pigs.

Tips on writing a great bug report

What is your testing approach?

It depends on the situation but generally, when I start testing, I always try to find (and open) high or medium severity bugs first. They are the most valuable because it allows clients to focus on the most critical aspects to affect user experience. If I find low severity issues first, I’ll write them down to deal with later. 

If I’m invited to a new project, I first go over the documentation and try to familiarize myself with the application under test. Unfortunately, there are cases where we don’t always have detailed documentation about a given project. If that’s the case, I’ll do my own research and look for videos and reviews on Google. It should be forbidden to start testing when you don’t know what the application is about 🙂

How do you decide if something is a bug or not?

It always depends on the task – If I have a task list with detailed steps and expected results, it’s easy to understand what is a bug. If the actual result is different from the expected one, then in most cases it’s a bug. Or a bug in the documentation.

When I perform exploratory testing, I have certain assumptions of how the application and its features should behave. Of course, if I’m familiar with the project, it’s easier to determine what is wrong or correct. But if it’s a new project, I’ll try to think of other similar products I previously tested or used in real-life situations, to get a feel for how the app should work. If I feel that something doesn’t work correctly, I’ll classify it as a bug. A certain level of experience can make a difference here.

What do you do when you find a bug?

When I find a bug, I try to reproduce it one more time. 

I test around specific areas to understand what exactly causes an issue – in other words, I’ll try to isolate the bug. For example, I want to open a file received in the chat – after opening it, the app crashes. I’ll have to check after what types of files the app crashes, maybe the file name contains some specific characters, maybe it’s due to the file size and so on. I’ll want to check if only the receiver gets a crash or the sender as well. 

Or I find a bug after pressing push notification. I’ll need to check if a crash occurs when the app is backgrounded or foregrounded. Or if the application has a few types of notifications, I’ll investigate if it crashes for all of the push notifications or only some of them and add this data to the notes as well. The more useful information, the better. 

As a general rule of thumb, here’s what I do when I find a bug:

  • If a bug is easily reproducible, I’ll record a video, take a screenshot and capture logs. After that, I’ll write down all the details and open a ticket. So, in total, the issue was reproduced at least 3 times. 
  • If I find a bug with complicated steps, I try to find an easier path – very often there are easier steps to get the same bug. 
  • After creating a ticket, I always double-check the ticket details, attachments, etc. to be sure that there are no bugs in my own ticket.
Testlio Bug Report Template

Does the type of project affect how you write a bug report – how?

Projects vary greatly and each might require specific information.

For example, when you test on the iOS platform and find a bug, you might want to compare with Web to understand if it’s an iOS issue or a server-side issue. 

Or when you test on a new build, you can compare it with a live one to understand if it’s a regression bug. Sometimes we test one project on several platforms in parallel so it’s a good way to check the main functionality on two platforms at a time. You can add a note to a ticket if a bug is reproducible for only one platform or for both. You can suggest improvements (if these are welcome in a particular project) – for example for an iOS app if something is missing when compared to Android or vice versa.

So writing bug reports always depends on the type of projects at hand. 

Example of a good bug report

What screen capture tools do you use?

It depends on the platform and sometimes on the project as well but there are tons of useful software testing tools available in the market, so it’s a matter of choice really.

Any other tips and tricks you can share?

I would recommend that all newbie testers take on issue reproducing tasks in different projects. I can attest that it really helped me grow professionally when I started out.

When you do issue reproducing tasks, you can see how the more experienced testers work and on top of that, you’ll be able to understand the project better. Always try to understand the issue first,  then reproduce it. 

I’d also suggest testers to be more proactive – try gathering the information you need on your own first. There are so many resources out there. For example, if you don’t know how to capture web console logs, just do a Google search and you’ll find a lot of information on that topic – this is not something you should be asking your Test Lead or Project Manager. 

Or if you have a question about a feature in the app, like ‘is it a bug?’, ‘should I report it?’, ‘where is this button?’  – try searching the Project Document first within reported tickets (usually, project documents are in the project details). If the project has been ongoing for a while, there will be open and closed tickets. Try using different keywords to find relevant tickets that might contain the answer to your question. 

Of course, it’s always alright to ask questions in the project chat, but try to be mindful of your CTL’s or project manager’s time. Some answers are easy enough to find on your own. This will even help you understand the project better, gain knowledge on how to find information quickly, and it will save the time of other participants in the project. 

And finally, don’t forget to add feedback to the test cases which cause confusion – CTLs and Project Managers are there to fix them for future runs.

Good luck and #lovetesting!

Jumbotron image