What is more annoying than a slow, poorly performing mobile app? Well, many things, but application development has never been about choosing the lesser of two evils.
If users don't like your app, they'll most certainly uninstall it and replace it with something that works better. For you as an owner, this can result in substantial losses. At the same time, it's will be much harder to attract new users to an app with bad reviews than to a new app.
So, running a performance test before a release is a must for everyone who wishes to build a truly enjoyable product.
In this article, we'll give you a sneak peek into how performance testing is done and what it consists of.
First of all, you need to make sure your app isn't a mobile-destroyer. It should not crash devices or overly consume their resources, such as memory, CPU or battery.
As long as all devices have different properties, it's a good practice to run tests on various models and OSs, as this will help you detect the issues that might arise on specific platforms.
Here are a few features that are checked while conducting this kind of testing:
This parameter introduces your app to a user. To make a good first impression, the start screen should be fully loaded within 1-2 seconds after a user taps the app's icon.
Some applications consume battery life like dementors. As a result, they create excessive load on CPU and heat the device. This not only makes the user experience less pleasing, but also it can cause damage to a gadget. So, it's crucial to make sure the app consumes no more resources than it can get without overloading the device.
Like computers, smartphones have in-built memory, though it's much more limited. Some apps’ features, such as push notifications in Android, can consume quite a lot of it. During testing, an engineer checks how much memory is used while an application is On and Off. If an app consumes almost as much as the mobile OS, then it needs to be optimized, asap.
An app should not conflict with other programs when being run simultaneously. The best way to test it is to simulate user actions: to switch the apps while using.
When switched to the background, an app should retain the same state until the moment it's turned on. Otherwise, a user risks losing important data or simply missing something interesting.
If your application is interacting with the server using API, the response time becomes extremely crucial for overall user experience.
Here are 3 major factors influencing it that are usually checked by QA engineers:
Loading and displaying requested data should not take long. If it is sent in a specific format that is different from the one the app uses, the conversion should also be performed quickly and effectively. At this stage, a QA Engineer ensures that the response time is ok and that the data is delivered correctly.
Number of API Calls
Each API call generated by an application decreases the performance, so it's better to minimize the number. For example, if several calls are made to perform the same functionality, then a developer will have to rewrite the code to handle the same tasks with fewer API calls.
Server Down Time
The app should stay operational even if there are server issues. For example, if the server is down, the data should be accessible from the native database. Another way to solve the issue could be to switch to a backup server when the database server fails. To ensure the smooth failover, the backup server must be synchronized with the main one.
3) Network Performance
The app should operate smoothly in any network conditions. To ensure maximum network performance, testers often check the following items:
Jitter is the variance in the time delay between data packets delivered over a network. Normally, it's 10 ms. Longer delays can cause problems in receiving and processing data for latency-sensitive applications. An app should be able to handle jitters; otherwise, the information will arrive scrambled.
If a whole packet is lost, the app should be able to resend the request or generate an alert. In that case, information arrives incomplete, and a user won't be able to perceive it; therefore, the app shouldn't try to display it but to display a suitable notification.
The app should be tried on 2.5G, 3G, and 4G, both Wi-Fi and mobile. Additionally, a QA engineer should check the app's behaviour when several networks are available, especially on switches between them. Sometimes issues arise while switching from mobile internet to WIFI - an app can cease to respond and will have to be restarted.
Looking for an expert QA specialist to run performance testing for your app? Intersog will be happy to provide you with the right people and the right expertise. Contact us to get a free quote and to learn more about our QA and testing services.