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.
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!
More information on mobile application testing strategies: https://www.german-testing-board.info/wp-content/uploads/2022/01/ISTQB-CTFL-MAT_Syllabus_v2019_EN.pdf
