Mobile App Debugging: Localizing Defects and Making Bug Reports

In this article, I will describe what a QA specialist does when he/she finds a particular mobile app bug.

Basic terms:

Bug is a component or system flaw that can cause a mobile app to fail in performing a required function. A bug detected at runtime can cause a mobile app to fail. For example, a person cannot save data after completing a questionnaire.
Error is a human activity that can lead to an incorrect result. For example: entering letters in the date field (only numbers should be accepted) and then saving the data.
Failure is a component or system deviation from the expected result, performance, or operation. For example: when the person goes to the next page of the questionnaire, the data from the previous page is overwritten.

Let`s start.

Classification of mobile app bugs

Functional mobile app bugs – the mobile application functionally does not work as intended. For example:

The brand new newsletter with insights, market analysis and daily opportunities.

Let’s grow together!

data changes in the profile are not saved
adding a comment doesn’t work
deleting items from the cart doesn’t work
search doesn’t work

Visual mobile app bugs – the mobile application doesn’t look the way it’s supposed to. For example:

text overflows the margins
the control element is layered on top of the underlying element
picture is not displayed

Logical mobile app bugs – the mobile application does not work correctly in terms of logic. For example:

the user can put the date of birth “from the future” as well as non-existent dates – February 31st, December 32nd, etc
it is possible to place an order without specifying a delivery address
the search logic does not work correctly

Security mobile app bugs – user data can be affected, and there is a risk of a system crash, etc. For example:

it is possible to receive login and password as a result of SQL injection
an unlimited lifetime of the session after authorization

So, we reviewed the types of mobile app bugs. Now let’s talk about how to document them.

Mobile app bugs documentation

A mobile app bug report is a document describing the situation or sequence of actions that resulted in incorrect operation of the test object specifying the reasons and the expected result.

Maybe you think that “the next step is to document mobile app bugs,” but you are wrong.

You can’t just go and document the mobile app bug you’ve found. First and foremost, it is important to perform localization.

For example, if the mobile app bug can affect other parts of the system, it must be presented in the bug report, and this hypothesis must be tested beforehand. It is also necessary to describe all the conditions and steps in great detail so that the developer can check this mobile app bug.

But how do you search for mobile app bugs so that it is clear to developers where these defects come from and how to fix them? It would help if you stuck to a certain action plan, which I will describe below.

Re-check the mobile app bug

You need to check yourself again: reproduce the mobile app bug under the same conditions. If the error does not occur during the next test, you need to ensure that all the actions and steps of the replay that led to this result have been followed exactly. It is possible that the mobile app bug appears only at the initial system boot (at first use). To more precisely determine the conditions under which the error was reproduced, the error must be localized.

Localize the mobile app bug

To localize the mobile app bug, you need to collect as much information about its reproduction as possible:

Identify the causes of the bug

For example, password recovery fails. You should identify the source of the wrong request to the server: the backend or the frontend.

Analyze the possible influence of the bug on other areas

For example, in one of the forms, which is rarely used, there is a bug when pressing the “Edit” button. If the button is hidden as a temporary fix to the problem, it can affect a similar form in another window/tab which is accessed more frequently by users. For qualitative analysis, you need to know how the mobile application works and the dependencies between its parts.

Deviation from the expected result

You need to check if the test result corresponds to the expected result. A requirement specification helps to solve this task where information about the mobile app being tested and its functioning should be documented. You should not skip this step when testing. If the specialist is not experienced enough and does not know the requirements, he/she can make mistakes and misunderstand what is related to bugs and what is not. Careful study of the documentation allows you to avoid such mistakes.

Investigate environment

It is necessary to reproduce the bug in different operating systems (iOS, Android, Windows, etc.) or browsers (Google Chrome, Mozilla, Internet Explorer, etc.). You must check the product requirements to determine which systems should be supported. Some mobile applications only work on specific operating systems or browsers, so you don’t need to check other options.

Check on different devices

For example, a desktop app is designed for computer use, so there is no need to test it on mobile devices. For smartphones, there should ideally be a separate mobile version, which, in turn, makes no sense to test on computers. In addition, some PWAs can run on both computers and mobile devices, and they must be tested on all types of devices. You can use an emulator of this or that environment for testing.

The mobile application should be tested on several devices with different screen diagonals. In doing so, you can be guided by the requirements for the software, which should specify which devices the software is compatible with.

Test with different mobile app versions

To avoid confusing the implemented tasks, software versioning is used in development. Sometimes a bug is reproduced in one mobile app version but not in another. This attribute must be necessarily specified in the bug report so that the programmer understands in which branch the problem is to be looked for.

Analyze system resources

Perhaps the mobile app bug was found when the device’s internal memory or RAM was insufficient. In that case, the bug can be reproduced differently on identical devices.

Mobile app bug evidence fixing

Evidence of the mobile app bug must be recorded with logs, screenshots, or screen recordings:

Logs are files containing system information of the server or device, they contain information about certain actions of the user or the program. An experienced developer needs to look at the log files to understand the bug. Usually, logs are attached to a bug report as a .txt file.
- Live logging is the live capturing of system logs. Sentry can be used for this.
Screenshot. When there are errors in the interface, a screenshot helps figure out the problem faster. There are a lot of programs for taking screenshots, every QA specialist can use the ones that are most convenient for him: Jing, ShareX, Lightshot, etc.
Screencasting is a video recording of the device screen. This way, the QA specialist can easily show the errors in the operation of any software product. The indispensable tools of any QA expert are Reflector, ADB Shell Screenrecord, AZ Screen Recorder, etc.

Mobile app bug report formatting

All bugs found must be documented so that everyone involved in the project can receive instructions on how to reproduce the bug found and understand how critical it is. If it is customary for the team to verbally convey information about bugs found to the developer, there is a risk of losing sight of something.

A mobile app bug that is not documented is not found!

When all the necessary information has been gathered, and the bug is localized, you can issue a mobile app bug report. The more accurate the description of the bug, the less time it takes to fix it. The list of attributes is different for every project, but some of them, such as replay steps, expected results, and actual results, are almost always present.

Mobile app bug report attributes

Name

The mobile app bug should be described briefly and concisely and have a comprehensible name. This will help the developer understand the mobile app bug’s nature and whether he can take the case to work. It also makes connecting new specialists to the project easier, especially if the development is conducted for many years, and it becomes increasingly difficult to remember the bugs and track them. The project’s name can be composed according to the principle of “Where? What? When?” or “What? Where? When?” depending on the team’s internal rules.

For example:

Where is it happening? – In the client card (in which section of the system).

What exactly is happening? – No data is saved.

When does it happen? – When saving changes.

Mobile application component

In which part of the functionality was the bug found?

Mobile app version number

The product version in which the bug is reproduced.

Criticality

This attribute shows the impact of the bug on the functionality of the system, for example:

Blocker – a bug that blocks the use of the system

Critical – a bug that disrupts the basic business logic of the system

Major – a bug that disrupts a particular function but not the whole system

Minor – a minor bug that does not break the application’s business logic, for example, a user interface bug

Trivial – a subtle, non-obvious bug

Priority

Priority determines how urgently a bug must be corrected. Usually, the following kinds of priorities are distinguished:

High – the bug must be fixed as soon as possible, it is critical for the project

Medium – the bug must be fixed, but its presence is not critical for the project

Low – the bug is to be fixed, but it does not require an urgent solution

Status

Bug status indicates the stage of the bug lifecycle, whether the bug is in progress or has been resolved. Examples: to do, in progress, in testing, done. Additional statuses are possible depending on the project’s peculiarities (e.g., analytical).

Assigned to

The bug report is sent to the project team leader or the developer who will be responsible for fixing the bug, depending on the agreements accepted by the team.

Preface (if necessary)

Necessary to describe the actions that preceded the reproduction of the bug. For example, the client is authorized in the app, a request with ABC parameters is created, etc. Bug reports may not contain a preface, but sometimes it is necessary to describe the replay steps more easily.

Replay steps

One of the most important attributes is the description of the steps that led to the bug being found. It is optimal to use 5-7 clear and brief steps to describe the bug, for example:

Open (…)
Click (…)
Enter value N1 in the A field
Enter in field B the value N2
Click the “Calculate” button

The actual result and expected result

What happened after playing the above steps, and what should happen after reproducing the test steps as required?

Attached files

Logs, screenshots, screen recordings – everything that will help the developer understand and fix the mobile app bug.

After you make a bug report, you must check it to avoid mistakes or misprints.

I also recommend you reading:

All information provided on this website is for educational and informational purposes only. Please consult with our Disclaimer.