What you can do to give a developer the best chance of finding the bug, recreating it and thus, squashing it as soon as possible
Bugs. No one wants to find one in their app but it’s inevitable at some point. It’s difficult to understand why something isn’t working as you expected it to. But it happens.
The most important factor for reporting a bug to a developer is to not only fix it but to fix it in good time. One way to do this is ensuring the developer knows exactly what they’re fixing. Giving clear, concise instructions on how to reproduce the bug, noting down the device and version used, as well as the key difference in expected outcome vs actual outcome could mean fixing a bug with minimal continued disruption to the app.
So, what should a bug report include?
First things first, you need to ask yourself;
What device did I find this bug on?
What software version am I using?
These two important questions are what’s going to kick off the bug reporting with a bang. Noting down exactly which device the bug was found on, e.g. iPhone 12, or, Samsung Galaxy S8 is the most efficient way to begin the bug report and giving the developer something to go on.
Giving the bug a title corresponding to the issue is the easiest way to communicate effectively with all parties. You need to ensure the title is clear and concise whilst explaining the problem. For example, instead of ‘Home button not working’, put ‘Tapping on the Home button in the top nav bar opens the bluetooth modal instead’. This clearly shows the developer which home button in the app and what isn’t working about that specific one.
Having specific titles means developers, product owners (or anyone else for that matter) can easily correlate the communications to the right bug.
This is the next question you should be asking yourself. Go through exactly how you got to the bug and note down each step of the way. A short example would be, ‘Launch the app, click on the home button in the top navigation bar, this opens the bluetooth modal’. For a longer or more complicated one, bullet point or number the steps to ensure the bug can be easily reproduced.
At this stage, it is also worth noting down whether this bug happens every time, or only sometimes. When a developer goes to look at the bug and all appears normal it can be frustrating on both ends. Recording this at the beginning is beneficial for all involved and shows the developer exactly how many times they need to tap on a button, or go through the flow in order to recreate what you’re seeing.
In the given examples throughout, all you need to do is note down what the expected outcome was. E.g. The home button in the top nav bar should take me to the home screen. The next question to answer is, what was the actual outcome? Try to mirror the wording from the expected outcome to make it clear at what point the bug is happening. E.g. The home button in the top nav bar does not take me to the home screen, instead it opens the bluetooth modal.
Structuring a bug report this way is essential for an effective and efficient end result where the developer involved can pick up the task with ease.
Search over 400 blog posts from our team
Subscribe to our monthly digest of blogs to stay in the loop and come with us on our journey to make things better!
We develop intelligent mobile apps for iPhone & Android that deliver for you.
Want to connect? You can find us on Instagram, Facebook, X (formerly Twitter) and LinkedIn.
Here’s our privacy policy.
Here’s our Accessibility statement.
Copyright © 2024 Brightec Limited. All rights reserved.
