How Does Your Mobile Application Handle Internet Connection Issues? You Might Be Surprised…

How Does Your Mobile Application Handle Internet Connection Issues? You Might Be Surprised…

Testing a mobile application? Have you thought about connection latency issues?

As more companies launch their own mobile applications, a lot of former web-based testers are moving towards testing mobile applications. As testers make this switch, there are seemingly minor issues which can get completely neglected, like unstable Internet as users move through mobile applications (I’ll call these “user journeys” below). 

Do you know how well your mobile application handles errors or latency issues caused by unstable Internet connectivity? 

Testing mobile applications is, in particular, a specific and acquired skill. While there are many nuances of crafting the best user experience for your mobile application users, I will bring out this often ignored aspect of it. In this article testers will get a clearer idea of how these issues affect quality and how you can assess their impact. 

Assessing The Effect Of Connection Issues On Your Application

While testing on a test device or running an automated test on a simulator, a tester might not consider the fact that the users are going to use the application over mobile data on a network which is prone to Internet speed fluctuations. In general, mobile internet users don’t stay in a single place even while using the mobile device.

Documenting the present state of mobile applications under test is important to understand where the mobile application stands in handling server-side issues like latency. 

Here are ways in which you can analyze its present state: 

Examining Error Handling: API Calls

  1. List the API calls your application makes as you step through important workflows. You should look only at the API request first. You’ll look at user interface responses in the next section.
  2. Bring the server down or mock the server response if a server outage is not feasible. Then, for each API request, check if the application has handled server-side errors (and if so, how they were handled). Common errors here include request timeouts and service unavailable. 

Tip: Use Flipper ( to debug and see requests sent from a connected mobile device or simulator.

Examining Error Handling: User Journeys 

  1. List the important user journeys (workflows) an end user might make through the application’s user Interface.
  2. Account for the API calls made in each journey.
  3. As you did above, bring the web server down or mock a server failure. Then, see how the application’s user interface handles error conditions. You might see empty pages, clocking / page loading that doesn’t end, or generic “an error occurred” messages.
  4. While exploring the app, try switching off the Internet before submitting forms, setting filters, or selecting checkboxes and buttons which lead to different endpoints. If you have to exit and restart the application to get out of an error condition, that’s noteworthy. And that’s just an example of what can go wrong.

Take note of all these issues and prepare detailed documentation to show the application’s behavior, highlighting the important user journeys and API endpoints issues.

Reporting The Issues And Suggesting Solutions

Now that the issues have been documented, present them to your product and development teams for review and proper action to be taken. The team could choose to handle the issues in a few ways: making user stories for them or filing enhancement requests. 

As you present documentation of the issues, it's also advisable to present possible solutions if that is within your role on the team. (If you are not sure if suggesting solutions is within your scope of responsibility, have a chat with the team and with your manager.) These suggestions for solutions can also be documented and put forward as the best course of action, depending on the mobile application experience the product team wants to offer to end users.  

Here’s how you might present the issues and suggestions for solution:

In the list of user journeys and API endpoint issues, add a “suggested solution” column of and specify what can be done to handle it better. For example: a timeout from the server-side should not lead to an empty page. Instead, the user should be prompted to resubmit the form and the application should save the user’s existing entries so that they do not need to be retyped. 
There are also combined solutions to this problem wherein, users can be shown a “No Internet” page so as to save and freeze the user flow at that point and not let users interact with it until the Internet connection is back. Another way is simply to put a banner on the top stating that the user has an unstable Internet connection at the moment.

After you have identified the present issues with the application and the solutions have been coded, you can reuse the scenarios you identified in the steps above to test the changes. 

Note: Other solutions may be available, as per product needs and feasibility to implement them.


Your application testing should identify real user problems related to backend errors and service failure errors. This way you add value to your application by providing a better user experience.

Happy testing!

For More Information

Ashutosh Mishra's profile
Ashutosh Mishra


QA Engineer with diverse experience

Mobile Test Management Done Right

0h 45m 32s

Re-running the ‘Are you a Mac or a PC? battle … for iOS and Android – Sally Goble & Jon Hare-Winton

0h 32m 37s

Automating Mobile Testing and Drastically Reducing Maintenance with AI

0h 15m 31s

60 Powerful Heuristics to Bust a Testing Groove With By Simon Knight
Moving from Gui to Api Testing: Challenges Faced & Lessons Learnt - Shivani Gaba

0h 26m 2s

Learning to Ask for Testability - Nicola Owen

0h 25m 14s

Revisited: The Tester’s Survival Guide to Joining a Continuous Delivery Project - Amy Phillips

1h 0m 32s

The Tester’s Survival Guide to Joining a Continuous Delivery Project

0h 41m 49s

A Practical Guide to Testing in DevOps - Katrina Clokie

1h 2m 5s

Is this on your radar?

Learn more with MoT