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

Josepha Miltony Martšuk , Managing Editor, Testlio

February 19th, 2020

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.

Related: Meet at Tester: Dina

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 🙂

I ask myself if I’ve tested something similar to the app before, whether I know its main purpose and target audience. If yes – then it’s easier, if no – then I try to find as much information as I can. Sometimes, there is no information because the project is brand new and has not yet been released to the public – in such a case, I try to think: do I know of a similar app? If yes – then I can explore the main functionalities of the app, just so I can compare it to my current task and have a better understanding of it. I find it especially useful when I get exploratory tasks where you have to think about actual scenarios – so it helps to have something to compare the app with. But of course, to do this you need to have plenty of time.
If I have to do exploratory testing tasks (which I love!), I try to cover some real-life scenarios and always start with positive testing. Running negative tests first might not bring out the needed value if the feature doesn’t work properly under positive scenarios. For instance, if the app should work mainly in online mode and it crashes when you try to send a message using an internet connection, no need to test sending a message in offline mode, etc.

While I’m testing, I also try to use the knowledge or skills gained from my previous work and real-life experiences. A while back, I worked as a sales manager in a travel agency and we often provided discounts or special offers to the customers. Because of these discount codes, our application would sometimes display errors when calculating total prices – as a result, we had quite a few unhappy clients 🙂 Then when I became a software tester, I had the opportunity to draw upon this experience when testing a similar app for cashiers – I found many valuable bugs related to discounts and offers while doing both payments testing and exploratory testing.

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.

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.

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.

Personally, on iOS, I use the native Screen Recorder and Console app to capture logs for example. On Android, I use Android Studio to record/capture logs and screen. Also, Screencast o Matic is a great tool for screen recording on Mac and Windows. To convert videos, I use an online video converter application.

I also suggest checking out Testlio’s help articles to find more great resources on this topic.

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!

Do you like testing? Join our network of world-class testers!