The differences between mobile and web applications are becoming less and less over the years. Recently, they have also entered browsers: Face ID/ Touch ID, next gestures or dark mode. However, some functionalities typical for mobile applications still exist and you probably won't come across them when testing web applications on desktop or mobile browsers. As they can be used on smartphones and tablets means that they can use all the additional features that these devices have. If you have only tested web applications so far and will soon be participating in a project related to mobile platforms, this article is for you. Being aware of these differences and potential areas where bugs may appear will certainly help you take the first steps in testing them. All the information presented later in this article applies equally to the android and iOS.

## Offline mode
For applications with offline mode, it is worth checking their operation during the transition:

- from wifi network to offline
- from mobile network to offline
- from wifi network to plane mode
- from mobile network to plane mode
- from wifi network to mobile network
- from mobile network to wifi network

As you can guess, functionality may not work properly in any of these situations.

### Examples of problems:

Airplane and offline modes do not always affect the application in the same way, although it might seem so because both are responsible for switching a device to the offline mode. An app with offline music playback function working only when wifi is off and not in the airplane mode may serve as an example here.

The same case can apply when using applications on wifi and mobile networks. It should work in both cases in the same way. However, sometimes problems can arise. If developers do not check whether the state of the Internet in the application is actually changing, for example, the transition from wifi to lte can be seen as a change of a state. This will cause unnecessary refreshing of the current view or synchronization of data in the background.

A similar error may occur when the wifi connection is interrupted (it is enough to go beyond its range) or when it is manually switched off because, as it turns out, two different effects can be achieved with these actions. The wrong result of, for example, streaming tests when performing these 2 test cases, is to show in the application that the stream is active all the time when you are out of wifi range, which is actually not possible because the phone is already offline. In this situation, the information about trying to reconnect should show up, because without it a user will not be aware that his livestream has stopped working. However, if the Internet access is manually disabled, the application can correctly show that the Internet access has been disconnected/ there is an attempt to reconnect.

## Dependencies between applications

Once an application is installed on your phone, it is worth checking the impact of other applications on it. 

### Example of a problem:

It may happen that you can't install an application because another one disallows as it comes from the same product family. This may be due to a bad configuration of an external service such as facebook. To avoid such a situation, there should be two separate facebook account identifiers created for staging and production.

## Application size and RAM memory

It is also worth noting how much RAM the application uses when using it and how much drive space it takes.

### Examples of problems:

It is especially important to check the RAM consumption when using the application. If the application loads a lot of images and does not reduce their size before loading them into RAM, then the allocated memory limit by the system may be exceeded. This can result in a crash of the application.

When it comes to drive size, it will not matter much when using the application. The problem may arise when a developer forgets to clean up data that a user no longer uses, such as downloaded music on a playlist that is no longer offline. Then the drive will fill up very quickly and there will be no room for anything else.

## Background / Active / Inactive

A common test case that occurs when using applications on a mobile device is the use of them in 3 main states, i.e in the background (running in the background), foreground (active, visible to the user) and killed (inactive). Additionally, in mobile applications there is a difference in reopening applications (you can open them from the backgrounds by selecting from the last opened ones or by clicking the icon on the screen).

### Example of a problem:

Opening applications from backgrounds via the application icon: 

1. expected result - **opens in the view where we closed the application** 
2. unexpected results - **opens in a different view, tab is changed**

## Application icon

Various functions may be associated with the icon. An immediately visible function can display the number of notifications in the top corner of the icon. After  long pressing, there can also be a possibility of sharing, redirecting to a specific view or, for example, quick opening of the application after clicking on the 3 most frequently used playlists in this case in a music app.

### Examples of problems:

The lack of displaying the number of notifications or showing the wrong number may constitute a problem.

The lack of a long press redirection that should be active, the lack of clicks when selecting any of these functions or the opening of an incorrect view may become another issues.

## Availability

On android as well as on iOS in the "availability" section of the phone, you can change the settings for appearance, interaction, audibility, etc. This is an edge case because a fairly small number of users use these settings, but it is always worth checking how the application will behave after such changes. 

### Example of a problem:

After activating the "button shapes" option in the navigation bar, for example, the return arrow disappears, which makes using the application much more difficult.

## Contacts

There are applications that have contact synchronization used to search for friends. You can then invite them to create an account in the app by sending a text message or search by phone number for those who have already created accounts and invite them to join your friends.

### Examples of problems:

You should check here whether all contacts are actually well synchronized.

It is worth noting whether the application asks for access to the contacts, whether the message is formulated in the right way (there must be specific information for the user on how these contacts will be processed) and whether it is displayed in the right place.

If the application is on the foreign market, it is also worth noting whether the invitations with text messages come to the recipient (this may be related to the directional prefix and the replacement of for example "+" with 00 digits).

## Update

When the application is already in the store, it is worth testing what the update will look like. You should then download the store version and install the version that will be released as an update to it. There may also be various popups, buttons in settings, etc. in the application in order to inform the user about available updates.

### Examples of problems:

Crash when opening an application, so called instant crash, crashes in other places in the app or other changes in functionality. 

You should check if the popup or button associated with the update shows up in the right version, if it shows up at all and if it redirects to the app store/google play.

## Summary

There are 8 functionalities presented in the article, together with error examples (these are obviously not the only possible examples or their only possible compilations) occurring during tests of various applications on the android and iOS platform. They should increase the experience in testing applications, make it easier to write test cases in given areas, reduce the probability of making fundamental issues and illustrate what problems can be encountered during the project. Every detail in mobile app testing is important, such as checking apps on the basis of changes made in "availability" in phone settings, because during the review of an app before it is released to the store, it can be rejected for this reason. However, the most important thing is to be aware that a function can behave differently despite potentially the same action. 

[Click this line to find additional source of information about other common bugs on mobile applications.](https://appunite.com/blog/ten-most-common-bugs-mobile-apps)

large_most common mobile features testing problems.jpg

medium_most common mobile features testing problems.jpg

small_most common mobile features testing problems.jpg

thumbnail_most common mobile features testing problems.jpg

most common mobile features testing problems.jpg

https://strapi-appunite.s3.eu-central-1.amazonaws.com/covers-with-text/26a209d6-29f8-4b2b-a45f-dd800e626457.png

If you have only tested web applications so far and will soon be participating in a project related to mobile platforms, this article is for you.

The 8 most common mobile features testing problems | AppUnite Blog

The 8 most common mobile features testing problems

# Differences in creating testing strategies based on parameters typical of mobile applications

Often testers in their work have contact with mobile and web applications. It may seem that both types can be tested in the same way. But are you sure that's it? It turns out that there are several differences. They should be taken into account when creating testing strategies for native mobile applications, web applications opened with a desktop browser and web applications opened with a mobile browser. We come across many types of applications on a daily basis, but for the purposes of this article I decided to simplify them to the most common ones. The differences between these approaches are presented below.


## #1 Number of devices supporting the application

In the strategy of testing web applications opened with a desktop browser, you don't need to consider mobile devices because you open them using browsers, so a device has no influence on their appearance or behaviour. As far as native mobile and web apps opened with a mobile browser are concerned, it is worth taking into account as many different models of phones as possible to check how the application behaves and looks on them. It is often the case that it works properly on one device and not on the other.


## #2 Ability to use the application in the landscape mode

Of these three types of software, only two can use this mode: on native mobile applications and on a web application opened with a mobile browser. It is important to take this into account when creating a test strategy, because then, you have to adjust the designs to these views and often when rotating the screen. the bugs appear, e.g. no record of actions performed just now, ugly-looking view and even crash. This is because when the screen is rotated, a new action is performed and the current state is not saved. This has to be handled additionally, but sometimes programmers happen to forget about it.


## #3 Operation of applications without the internet access (offline mode)

It sometimes happens that (if such functionality is added) native mobile applications can be used offline. However, practice shows that applications used only on browsers do not have this possibility. You should then consider different cases to test this mode. For example, checking application operation when switching from wifi network to offline, wifi to airplane mode, LTE to offline and LTE to airplane mode. It may turn out that what was supposed to work in a certain way, does not work in any of these situations.


## #4 Differences in UX and UI design on platforms

The designs for android and iOS are designed separately. Each platform has developed its own style to determine the appearance and operation of the application. If tests are performed on both platforms, it must be remembered that they will not look or work the same. On the other hand, web applications opened with a desktop browser - or web applications opened with a mobile browser - it is assumed that they have one common design for all browsers. However, sometimes there may be differences on browsers, not to mention the responsiveness of websites, which is a separate topic.


## #5 Additional approval cycles when releasing applications to the store

Before releasing the mobile application to the store, you have to reckon with the fact that it must go through a review. It usually takes longer on iOS than on Android. Rejections are also often made during approval because of discrepancies presented by the checking person. Then you and your team, need to make corrections and release it again for review. Web applications do not need to be placed in Google Play or AppStore stores, so this aspect does not need to be considered. 

It is also worth remembering that applications that only use a browser can be patched at any time and are automatically accessible to users. When it comes to mobile applications, the risk of error correction is much greater here, because the user decides whether they will or will not update on their phone.


## #6 Installing and updating applications

In order to use the application, a user must be able to install it from the store and then be able to update it without any problems. If the application is already in the shop and an update is to be released, it is worth testing it on the production version. For the production version, which is a copy of the one in the shop, we can install a version that will be an update. Once this is done, you may find that not everything works as it did before the update. Web applications are not installed and updates are done by the owners of the application, so the user has no control over this. 


## #7 High visibility of the feedback

In the store, each application can be evaluated in a place visible to all users. Any error encountered can easily be published, and this in turn can affect the success of the application. Therefore, it is necessary to ensure the highest possible quality of the application, so that users are satisfied with its operation and pay attention to emerging evaluations and negative repair with the team. When it comes to web applications, there is no way to publicly evaluate them, which of course does not mean that their quality does not need to be taken care of either.


## #8 Hardware differences 

Sometimes, it can happen that the application works differently on the same model of a mobile device. This is due to the factory hardware differences of a particular device. For example, the situation that there are several crashes on some phone model. It may seem that a phone with the necessary parameters is within our reach, but in the end, you can't recreate that crash on it. Ultimately, it turns out that this problem only occurs on a few of these devices. Web applications do not have such a problem because they are browser-based and such differences do not affect them. 

![](https://appunite-blog.s3.eu-central-1.amazonaws.com/images/78d9a66b/5b96/RmluYWwgMi5wbmc=)

## Summary:

When creating a testing strategy, be aware of the differences between approaches to different types of applications to avoid unnecessary mistakes. Distinguished parameters are 100% applicable to mobile applications. However, two are common to mobile and web applications opened with a mobile browser, and when testing web applications, none of them occur. It is worth remembering that on each device the application can behave or look different, developers must face up to different view modes and that releasing the application to the store is a big risk and challenge. If you need a hand deciding which approach to take, [write to us](https://appunite.com/briefs)!

More information on mobile application testing strategies:
[https://www.istqb.org/documents/ctfl-mat-syllabus-2019.pdf](https://www.istqb.org/documents/ctfl-mat-syllabus-2019.pdf)




S2FzaWEgUUEuanBn (1)

https://strapi-appunite.s3.eu-central-1.amazonaws.com/covers-with-text/ed3125c5-b20b-4593-826d-3b9f41db2dcd.png

Often testers have contact with mobile and web applications. It may seem that both types can be tested in the same way. But are you sure that's it?

Articles

Let’s Work Together!