Testing Lite Mobile Applications: A Way to New Markets

Mobile application testing in itself already involves a lot of details and processes, but now there are also “Lite” mobile applications that bring their own challenges to the table. In my experience testing such apps, I’ve noticed a couple of interesting technicalities that, in my opinion, should be shared with the testing world. 

While it is very important to test any kind of app, properly testing Lite apps can become imperative to conquering new markets and leaving good first impressions on users that may be accessing company services for the first time. In this blog we will be taking a look at what it means to test a Lite application. To see examples of Lite apps, you can simply search for any mobile app that contains “Lite” or “Go” in their name. 

What is a Lite application?

Generally, the term “Lite app” refers to apps that are designed to use less resources and function more efficiently than their full version counterparts. This allows them to be used on lower-end hardware with limited capabilities, which does not only account for the slower processing speed of the device, but also limited storage space, memory capacity, smaller screen size, shorter battery life, and also limited connectivity to the Internet.

With these restrictions, developing a lite app presents various challenges: 

• The app itself must be small in size to account for limited storage space. 
• The graphical user interface must be compatible with lower resolution screens while still being able to support higher resolutions in case the user decides to use a newer device.
• The app should aim to reduce the amount of battery drainage to maintain uninterrupted usage.
• Data usage should be kept at a minimum as data packs in remote regions may be quite expensive and the connectivity may be unreliable.
• The app must support older mobile operating systems, to make sure that the majority of mobile users can still use it regardless of the OS version they have.

Keeping in mind that the target user base for Lite apps includes people who are new to technology and the Internet, it is important that the app is designed in a way that does not overwhelm users. Unlike modern apps that tend to be bloated with various features that only tech-savvy people can fully utilize, Lite apps should focus on simplicity, offering basic functionality that’s easy to use.

Why are Lite applications needed?

With the inevitable rise of globalization, technologies have become more widespread across the globe, even reaching remote areas. More and more people can now access the Internet. According to Statista, in 2023, 6 out of the top 10 countries with the highest number of internet users were located in regions like Southeast Asia, Africa, and South America. For big tech companies, this has led to discovering new business opportunities in non-Western markets, offering their services to the people who are new to technology and the Internet.

As the existing platforms were not suitable for these new markets, companies needed to adapt by creating new “Lite” applications that would specifically tackle the needs of customers in these regions. These new, lighter versions would allow people with older, slower devices to be able to access their services. 

Challenges of testing Lite applications

At first glance, testing a Lite application might not seem different from testing a regular application. While the general challenges and tips of mobile application testing still apply, there are a few additional aspects that need to be taken into account. Let's take a deeper look at them below.

Challenge #1: Using a reference app

Lite apps are typically designed to mimic their full-version counterparts, with modifications made to suit the needs of lower-end hardware. In general, this is the most noticeable difference when testing a Lite app and the original version, i.e. a regular app that does not have a reference app. 

Any major feature or functionality that is available in the full version of the app should also exist in the Lite version. This makes it fairly easy to spot any functional issues in the app. If a feature in the Lite version behaves differently than in the full version of the app, this discrepancy may be a bug. In any case, before knowing for sure, the issue needs to be investigated further.

Missing features from the original app

In some cases, specific features or functionalities from the full version of the app are intentionally left out of the Lite app. Either the feature is too heavy or too complicated to implement, or the feature does not align with the needs of the target audience. Whatever the reason, it is important to understand which features of the app are expected to be only available in the full version.

Features that are specific only to the Lite app

On the contrary to the previous case, it’s also possible that the Lite app has certain features that are not available in the full version. Such features are often designed to support the different needs of the Lite app users. For example, these could be things like data saving modes, partial content loading, or greater language support. In this case, when the feature doesn’t exist in the full version and can’t be referenced, having clear documentation for Lite-specific features is essential.

Differences in the same feature

Sometimes, both the Lite and full version offer the same feature, but it might not be fully implemented in the Lite version. For example, let’s take a messaging app that allows users to send a text message. The Lite version of the app might only support sending plain text, whereas the full version also supports emoticons, GIFs, and stickers. Knowing which parts of the feature are supported in the Lite app is important to avoid mistakenly reporting these differences as bugs. Additionally, it helps detect cases where features only intended to be available in the full version leak into the Lite version.

Bugs that are reproduced on both or only one of the apps

When a feature exists in both apps, it is a good idea to check whether a bug is reproducible in both apps. Since many features in the Lite app are carried over from the original app, testing for reproducibility can reveal the source of the defect and whether the issue is caused by the Lite app.

If the issue only occurs in the Lite version, it means that it is a bug specific to the implementation of the feature in the Lite app and not a bug in the feature itself. The same applies in instances when the issue is only reproduced in the original app. 

Only when the issue is reproducible in both apps, can we say that the bug is with the feature itself and not its implementation. 

Details like these can be crucial for the development team for finding the root cause of the issue and therefore should always be checked when being reported.

Client-specific vs. platform-specific bugs

Since both the Lite app and the original app are designed to provide the same service, they are likely connected to the same platform, making them prone to  platform-specific issues. A good way of telling if an issue is platform-specific is to check reproducibility on different versions of the same app. If the issue reproduces no matter the version, then that is an indication of a platform-specific bug.

Triaging found issues

Triaging reported defects can be a bit tricky. The triage process depends on how responsibilities are divided between different development teams which may support only one or both apps. Some teams may focus exclusively on either the Lite or full version of the app, while others might handle both. In some cases, one team manages a feature in both versions; in others, separate teams handle the same feature in each version. Understanding which teams are responsible for which parts of the app is essential for effective triaging and ensuring issues are directed to the right group.

Challenge #2: Ensuring consistent platform experience

Lite apps are part of a much bigger platform, so it’s vital for companies to make sure that the user experience remains the same no matter how users choose to access their services.

Data updates and refreshing

Imagine that the user is using two different devices simultaneously. For example, let's say that they have a Lite app installed on their phone, while at the same time they have a web page open on their computer. From the user's perspective, anything that they do in the Lite app, should also be reflected on the web page and vice versa.

The challenging part comes down to the fact that the Lite apps try to conserve data and therefore are less likely to constantly update information in the app from the Internet. As a workaround, a feature for refreshing data in the app is implemented. This, however, can lead to confusion, as some actions, like changing your username, would still be expected to be updated automatically without needing to refresh the app manually. 

For the testing team it can be difficult to distinguish which areas in the app require manual refreshing and which ones should be refreshed automatically. Hence, it is important to keep track of such areas or to establish common rules on what data needs to be refreshed manually.

Using two apps on the same device

Another situation that may affect the experience is when the user has both the Lite app and the regular app installed on their device. While for the most part this should not be the case, it can still happen if the user wants to use both apps due to features that are only available in one or the other app.

For such users, duplicate notifications may be an issue if both apps send device notifications. This happens when both of the apps are instructed to notify the user and hence each of the apps send their own notification. Dealing with such a situation can be difficult as the apps would essentially need to be aware of each other’s presence, and then figure out which app will be the one that will send the notification. For this reason, it could be accepted that duplicate notifications will occur and the testing team should consider it as an expected behavior, not a bug, and not report it.

Another issue that arises is managing user accounts across both apps. A user might be signed into different accounts in each app or the same account on both. In any case, the testing team would need to make sure that any actions performed in one of the apps should not cause any unexpected changes in the other, and make sure that both apps can be used interchangeably without issues.

Challenge #3: Testing lower-end devices

If one of the main purposes of a Lite app is to support the lower-end of device range, which mostly consists of either older devices or newer less expensive devices, using such hardware becomes a vital part of the testing process. While it is possible to perform testing on a device emulator or simulator, in manual testing it is generally preferred to use physical devices.

Testing on lower-end hardware implies longer test execution times due to the slower loading speed of the device and longer setup time. For example, if the device runs out of battery, it may take longer to charge. Also, it may be much harder for the tester to execute their tests as the device could have slower or delayed screen response time, as well as less sensitive and less precise touch displays, which makes it harder to perform tests efficiently.

Small screen resolution

It is fairly common for older and lower-end devices to have small screen resolutions. Older devices typically have physically smaller screens, while newer, less expensive devices reduce display resolutions in order to keep the devices affordable. Either way, testing teams need to be well informed about the pixel densities, screen sizes and resolutions that need to be supported by the Lite app, so that they can choose the right devices for testing. This also implies keeping track of the screen specifications for each device used in testing.

Common issues with poor resolution support include overlapping or cropped elements, for example buttons that cannot be tapped or UI elements that get hidden due to overlaps. Sometimes these elements may even become stretched or squashed, which makes things like text very difficult to read or any other visual information very difficult to interpret. If the app supports displaying media like photos and videos then it also becomes important to see how well they behave when viewed from various screen sizes. 

Small memory size and caching

Low-end devices also have limited RAM capacity, typically ranging from 2–4GB of device memory, with the lowest being around 1–1.5GB. It’s important to note that most of the memory capacity is already used by the operating system and various other background processes, which leaves even less room for the Lite app to run. The more memory is occupied, the slower the device runs, as the system processes have less space to function properly until memory is freed up.

Limited memory means that applications do not have a lot of space for storing on-the-go data. In order to work around this limitation, applications tend to store a lot of data in the cache, however, this is slower than memory and is also prone to more errors. Caching errors can be very random and very difficult to debug as it is not known what kind of data is stored in the cache at any given time. As an example, on multiple occasions I've spent a lot of time investigating issues that simply disappear if the app is reinstalled. In order to avoid such situations during testing, the app cache needs to be cleared regularly.

Small storage space

With modern apps taking more and more storage space, it becomes vital for Lite apps to remain as small as possible. Once the storage is full, users have no choice but to uninstall existing apps in order to free up space for new ones. This does not even account for the media, like photos and videos, that users may want to keep on their device. It is important to make sure that the app size does not exceed certain limits. In addition, testing teams must also ensure that the app can still function properly even when the device storage is full.

Challenge #4: Testing on much older devices

As Lite apps are designed to support a wide range of mobile OS versions, particularly older ones, testing teams will also have to deal with devices that can be up to 10 or 12 years old. This can impose significant challenges on the testing process, as such devices are no longer supported by many tools used for testing, as well as the hardware itself is outdated. Testers must be well-prepared beforehand, anticipating potential tool limitations and having workarounds ready for devices that do not support them. 

Battery life and charging issues

One of the most noticeable things in older devices is  slow charging speed and fast battery drain. From my testing experience, if I fully charge such a device, lock the screen, and leave it for a day or two, the next time I try to use it, the battery will have fully drained.

In order to avoid any downtime while the device is charging, it is recommended to make sure the device is fully charged before testing begins. Also, after testing is done, the device should be shut down to conserve the battery for the next testing session. However, you need to keep in mind that constantly charging the device during testing can lead to battery swelling, which can also damage the device itself. Given the scarcity of older devices, they cannot be easily replaced, so care should be taken when using them. 

If needed, it is also advised to look into battery usage testing, as having to frequently charge the device battery can disrupt the user experience. In the case of Lite apps, it is even more important to make sure that the app does not cause high battery drainage.

Connectivity challenges

Testing teams should expect much slower WiFi and cellular connectivity. This is mostly due to the fact that old devices do not have modern wireless hardware nor support modern wireless protocols. Also, there has been a significant increase in wireless traffic compared to the time when the device was originally released.

Using a wired connection like Ethernet may also not be feasible, as Lite apps are intended to be used in remote regions where mostly wireless connections are possible. As these regions generally have unreliable connectivity, it may be necessary to simulate bad network conditions in order to find any issues that are caused by frequent network interruptions.

Another consideration is SIM card swapping during tests. If the tests require frequent swapping of SIM cards, then it must be taken into account that older devices do not have removable SIM slots. In order to swap the SIM card, the device needs to be fully shut down. Also, it must be noted that older devices usually use a mini SIM slot, meaning that modern nano SIM cards will need to be put in the casing for mini SIM before they are used.

Screen recording

Another issue that can arise during testing is the possibility to record the screen of the device. Due to low performance, using a screen recording app is not feasible, and in some cases, there may not even be an available app for older operating systems.

Instead, a common workaround is to record the screen of the device with another phone that has a good quality camera. The tester must make sure that reflections, light blooms, or screen refresh artifacts are reduced in the recording. Also, it is recommended to use a holder, like a mobile tripod and to lock the camera focus, so that the video footage remains stable and sharp. As using such a setup takes more time than using a native app, the additional delay should be taken into account when planning for test execution time.

Capturing logs

Older devices often operate on lower API levels, which can lead to issues when the app attempts to access features not recognized by the device’s API. These issues can be easily spotted in the system logs, making it important for testers to know how to capture them. Testing teams should be familiar with tools like Android Debug Bridge (ADB), which enable them to capture device logs.

Challenge #5: Delivering a good experience to users new to technology and the internet

Lite apps are designed to support users that may not be that familiar with technology. Their simplistic design, straightforward functionality, and support for various languages (localization) aim to provide a good user experience for these groups of people. Companies must make sure that these users get the very best experience, to increase the likelihood of them actually using their app.

Unlike standard apps, Lite apps may require extensive User Experience (UX) testing to support a vastly different user base. Correctly identifying and addressing the needs of these users, as well as understanding all the cross-cultural aspects that are involved can be the difference between gaining or losing a new customer.

As an example of bad user experience, consider feedback forms that allow users to leave a rating from 1 to 5 stars. The design of the user input assumes that the rating will be read from left-to-right, meaning the closer it is to the right side, the better. For users that are native to languages that use a right-to-left writing system, it may seem that the rating closer to the left side is better. As a result, this may lead to unintentional low ratings, when in fact the user intended to leave positive feedback.

Key takeaways

Testing Lite apps presents a range of unique challenges, from handling older devices with limited resources to ensuring a seamless user experience for those new to technology. The testing team must be equipped to deal with the constraints of low-end hardware, such as small memory and slower processing, while also managing platform differences, caching issues, and screen resolutions.

Extensive UX testing is essential to cater to users unfamiliar with technology, and special care must be taken to account for cultural differences in design. By preparing for these challenges, maintaining thorough documentation, and implementing creative workarounds, testers can ensure that Lite apps deliver a reliable and enjoyable experience for all users, regardless of their device or tech expertise.

Want to ensure your application works on all types of devices? With over 3,500 test devices—from the latest releases to lower-end legacy devices, we can help you navigate the unique challenges of mobile app testing, from checking performance on lower-end devices to ensuring a positive user experience across various regions and network conditions. Contact us to learn more about our software testing services.