If you find a bug within a mobile app, you need to report it in order to get it fixed. Filing mobile bug reports requires some additional information that the developers need in order to reproduce and fix the bug.
But what is important when filing a mobile bug? What should a bug report look like?
Before I answer those two questions, I want to raise another one: “Why even send a bug report?”
Bug reports are very important for the product owner, product manager and the developers. Firstly, a bug report tells the developers and the product owner about issues they were not aware of. They also help to identify possible new features no one has thought of and, last but not least, they provide useful information about how a customer may use the software. All of this information can be used to improve your software.
Whenever you find something strange, if something behaves differently or looks weird, don’t hesitate to file a bug report.
Let’s come to the question of what a bug should look like and what’s important when filing it.
A bug report should contain as much information as possible in order to identify, reproduce and fix the bug. Having said that, your report should only include information that’s important to handling the bug, so try to avoid adding any useless information. Another important point is that you should only describe one error per bug. Don’t combine, group or create containers for bugs. It’s likely that not all of the bugs will be fixed at the same time so refrain from combining or grouping them.
The following information should be included in a bug report:
Bug ID
A bug must have an unique identifier like a number or a combination of characters or numbers. If you’re using a defect management tool, the tool will handle the bug IDs for you. If not, think about a unique ID system for your project.
- Bad: 123 is a unique ID, but you might have several projects where the ID is the same.
- Good: AppXYZ-123 is good because you’re combining an ID with a project abbreviation and a number.
Description
Create a short but meaningful description in order to provide the developer with a quick overview of what went wrong without going into detail. You should, for example, include error codes or the part of the application where the bug occurred.
- Bad: “The app crashed”, “White page”, “Saw an error”, “Bug”
- Good: “Error Code 542 on detail message view.”, “Timeout, when sending a search request.”
Steps to Reproduce
This is one of the most important points. Provide the exact steps together with the input data on how to reproduce the bug. If you are able to provide this kind of information, the bug will be very easy to fix in most cases.
- Bad: “I tried to execute a search.”
- Good: “Start the app and enter ‘Mobile Testing’ into the search input field. Press the search button and you’ll see the error code 783 on the search result page header.”
Expected Result
In this section you should describe what you expected to happen when the bug occurred.
- Bad: “It should work.”, “I didn’t expect it to crash.”
- Good: “I expected to see a search results page with a scrollable list of 20 entries.”
Actual Result
What happened when the bug occurred? Write down the actual result, what went wrong or the error that was returned.
- Bad: “It just won’t work.”
- Good: “The search results page was empty.” or “I got the error code 567 on the search result page.”
Workaround
If you’ve found a way to continue using the app by avoiding the bug, explain your steps. Those steps are important to know since the workaround could cause other problems or indicate a way in which the app should not be used. On the other hand, a workaround can be very useful for the customer support team in order to help customers solve the current problem until the bug gets fixed.
- Bad: “I found a workaround.”
- Good: “If you put the device into landscape mode, the search button is enabled and the user can search again.”
Reproducible
If you found a reproducible bug, that’s fine, but does it occur every time? If it happens every time, that’s great as this should be an easy fix for the developer. But if the bug only occurs 20 percent of the time, it is much harder to find a solution for that. Make sure you provide this information, however, as it is very useful for the developer and will prevent the bug from being closed with the comment “can’t be reproduced”.
- Bad: “Sometimes”
- Good: “The bug occurs 2 out of 10 times.”
Operating System, Mobile Platform and Mobile Device
The same applies to the operating system, the mobile platform and the mobile device. Write down the operating system, mobile platform and device on which the bug occurred.
- Bad: “On Android” or “On iOS”
- Good: “Android, Version 4.1.2 Google Nexus 4” or “iOS, Version 6.1 iPhone 4S”
Mobile Device Specific Information
Mobile devices have lots of interfaces and sensors that could have an impact on your app. The battery could also affect the app you’re testing. Write down all of this information in your bug report.
- Bad: “No information”
- Good: “GPS sensor activated, changed the orientation from landscape to portrait mode.” or “Used the device in a sunny place.” or “Battery state was 15%.” or “Battery state was 100%.”
Browser Version
If your app is a mobile web app and you found an issue, it’s very important to note down the browser version where you found the bug as it may only occur in a certain browser version.
- Bad: “Google Chrome” or “Mozilla Firefox”
- Good: “Google Chrome Version 45.35626” or “Mozilla Firefox 27.6”
Software Build Version
Another really useful piece of information is the current build version of the app where the bug occurred. Maybe you found the issue in version 1.2, but there is already a newer version available where the bug has been fixed. This will prevent the developer from wasting time by trying to reproduce a bug that’s already been fixed.
- Bad: “No information”
- Good: “App build version 1.2.3”
Network Condition and Environment
When filing a mobile bug, it’s important to provide some information about the network condition and the environment in which the bug occurred. This will help to identify the problem more easily and will possibly show some side effects no one has thought of.
- Bad: “No information” or “Happened on my way to work”
- Good: “I was connected to a 3G network while I was walking through the city center.”
Language
If your app supports several languages, provide this information in your bug report.
- Bad: “No information”
- Good: “I was using the German-language version of the app.”
Test Data
This information can already be provided in the steps taken to reproduce the section, but test data you need to reproduce the bug may be more complex, so it makes sense to provide this information in a separate section. Provide SQL dumps, scripts or the exact data you entered in the input fields.
- Bad: “No information”
- Good: “Find the attached SQL script to put the database in the defined state.” or “Enter ‘Mobile Testing’ into the search input field.”
Severity
Every bug you find needs a severity level. Either your defect management tool will offer you some categories or you have to define them with your team. It is important to give a bug a severity level as it will allow the team to prioritize their bug-fixing time so that critical and high priority bugs will be fixed first. If this information is not provided, it takes much more time to find the right bugs that need to be fixed before the release. The default severities are: Critical, High, Medium and Low.
- Bad: “No information”
- Good: “Critical” or “Medium”
Bug Category
Besides the severity level, the bug category is also a very useful piece of information. The product owner or the developer can filter by category to get an overview of the current status of bugs per category. For example, if there are lots of UX bugs, this may be an indicator of a poor UI and UX or a missing design expert in the team, meaning that the app needs some more design improvements.
- Bad: “No information”
- Good: “Functionality” or “UX” or “Performance”
Screenshot or Video
Whenever you find a bug, try to create screenshots or a video to provide the developer with more information. When providing a screenshot, use an image editing tool to mark the bug in the screenshot. A video is also a great way to describe a bug you’ve come across. It is also very useful to give the screenshot or the video a good name or description.
- Bad: “No screenshots or videos attached.” or “Screenshot1.png”
- Good: “01_InsertSearchTerm.png, 02_SearchResultPageWithError.png”
Log Files
If your app crashes or freezes, connect the device to your computer and read out the log files. In most cases a stack trace will be shown with a description of the error. This kind of information is extremely useful for developers as they know right away in which class the bug or the error has occurred.
- Bad: “No information provided when the app crashed.”
- Good: “Provide the full stack trace in the bug report.” or “Attached the log file to the report.”
Tester who found the Bug
Write down your name or the name of the tester who found the bug. Developers or product owners may have some questions about the reported bug and they would of course like to directly get in touch with the tester who found the issue. In most cases, this is automatically done by the defect management system where each user has his or her own account. If not, make sure you add your e-mail address and/or phone number.
- Bad: “No information”
- Good: “Daniel Knott, [email protected]”
As you have seen, there is a lot of information that should be included in a bug report. There are three other points you should keep in mind when writing a bug report.
The first one is Don’t get personal. When filing a bug report, describe the software misbehavior rather than the developer’s mindset or the quality of his or her work. Don’t use offensive or emotionally charged words as those kind of bugs will be ignored by the developer and will end up with bad blood within the team.
The second one is It’s not you. It’s not your fault that the bug occurred. It is the software that’s broken and you and your colleagues need to fix it.
And the third point is Keep it simple. Try to write your bug report in such a way that someone with no idea about the project or the app is able to understand the problem. If the bug report is that easy, every developer within the team will be able to fix it and non-technical colleagues can understand the problem and will value your work.
If you want to read more about mobile testing, please have a look at my book „Hands-On Mobile App Testing“ which is available under: http://www.handsonmobileapptesting.com/
About the Author:
After his time at IBM, Daniel studied computer science at the University of Applied Sciences in Wiesbaden, Germany. Software testing soon became a passion during his time at university and the reason why he chose a career in software testing. Daniel has worked at several companies in various different industries where he was responsible for testing web, desktop and mobile applications. During a number of projects he developed fully automated testing frameworks for Android, iOS and web applications. Daniel is a well-known mobile expert, speaker at various conferences in Europe, and a blog author http://www.adventuresinqa.com. Furthermore, Daniel is the founder and organizer of a local software testing user group in central Germany (www.stugrm.de).
Get in touch with Daniel:
Linkedin: http://www.linkedin.com/pub/daniel-knott/1a/925/993
XING: https://www.xing.com/profile/Daniel_Knott
Blog: http://www.adventuresinqa.com
Twitter: @dnlkntt
E-mail: [email protected]
