Testing mobile application quality

Over the past few years, the number of mobile devices and mobile device users has grown exponentially and continues to increase. With this rise in both devices and end users, the need for stringent quality assurance testing is also ever-increasing.  

Anyone who uses a mobile device is a tester, each and every day, but we just do not think of it in that way when we pick up our device to check an email or scroll through social media. Fortunately, at the same time, quality assurance engineers – experienced professionals – are also testing, and it is thanks to them that issues are discovered and can be rectified. Whoever is carrying out the testing, the main criteria is quality and, ultimately, the end user’s satisfaction with the product.  

There are a number of verifications to be performed by quality assurance testers while executing test cases. For me, I have found that the Android Design Guidelines and the iOS Human Interface Guidelines are the main documents I use for investigation, in this case as a part of requirements. A verification list is necessary because it covers the main dependencies between an app’s functionality and the mobile device.  

Whoever is carrying out the testing, the main criteria is quality and, ultimately, the end user’s satisfaction with the product.

Testing native mobile applications has its own specifics, but it is possible to determine a general mobile verifications list that can form the basis for testing any application. This will help to avoid future issues and increase the quality of products as they are developed.  

Common verifications checklist 

My own checklist below contains common, but important, verifications for native mobile applications on Android and iOS platforms. Running through it every time before a new release saves time for quality assurance testers by helping to avoid bugs during production, thereby increasing the quality of the app and keeping end users satisfied with the product. Verifications include:

• app installation/launching/uninstallation; 
• app functionality in a particular screen orientation; 
• functionality of different connections; 
• verifying that the main app functionality does not depend on device’s settings; 
• verifying the redirection from the app or web-resource; 
• messaging, calls and notifications, screen-locking mode, sleep mode; 
• verifying external influences; 
• verifying graphic user interface and navigation; 
• verifying language settings and localisation; 
• verify application’s speed and performance; 
• verifying the notification functionality of the app; 
• specific verifications, including synchronisation with device’s accounts, input data such as symbols and emojis and specific functions such as turning on/off sound; 
• verifying the app’s stability; 
• application corresponds the security requirements; 
• verification power-saving mode; 
• authorisation and work in the application using the account from the social network; 
• verify app’s functionality with connected external devices. 

Tracking results 

It is highly recommended that all checklist data is kept in table form, using something such as Google Sheets or Excel. Adding the date or the version of the build while testing activity assists in tracking results and avoids mess. Simple titles for the columns such as ‘Verification’, ‘Status (Passed/Failed)’ and ‘Comment’ also help to keep track of the results, as does colour-coding the status, for example green for passed and red for failed. Sometimes it is useful to add a column with a Jira link to each reported issue opposite the failed status.  

Of course, it is complicated to perform such verifications as an installation-testing application without a free device’s memory. In such a situation, it is useful to use emulators for Android devices, or, if you need to verify different screen resolutions for iOS devices, simulators will help; apps such as Android Studio and xCode are good choices.  

An example of when such apps could be used would be for verifying the user interface (UI) on a different screen resolution of an iOS device. If you have only one device to use in this test, you could run the project in the xCode app, using simulators to recreate various iOS devices. Simulators cover UI and application logic, accessible for iOS. At the same time, emulators – used for Android devices – cover the UI, an app’s logic and also the device’s hardware, meaning that a quality assurance tester can perform verification even when lacking a free device’s memory. That said, despite all the advantages they offer, it is wise not to rely totally on emulators and simulators. 

Please note, the verifications listed above are generic and can be used for most native mobile applications, but every application has its own logic and a main reason as to why it was developed. As a result, it is essential that functional testing is always carried out.