Automating Real End-to-End User Flows Across Mobile Apps and Browsers

As a professional mobile app and browser test automation expert with over 10 years of experience across thousands of real devices, one of the most complex areas I am often asked about is automating tests for real end-to-end (e2e) user flows.

Many mobile apps don‘t function in isolation – they integrate with browsers and web apps as part of complete user experiences. Testing these real-world flows across multiple apps poses challenges that standard single-app test automation alone cannot handle.

In this post aimed at those new to multi-app e2e test automation, I will teach you how to leverage Appium to automate tests for real user flows spanning both native mobile apps and mobile web browsers.

What Exactly is a Real E2e User Flow?

A real e2e user flow refers to an integrated process chain spanning multiple apps that replicates steps real users would perform to accomplish goals. For mobile apps, this often includes:

1. Launching the native mobile app
2. Completing actions within the mobile app
3. Triggering something that opens the mobile web browser (Chrome, Safari etc)
4. Executing workflow in the browser – logging into a web app, filling a form etc
5. Switching back to the mobile app to complete remaining actions

Testing these interdependent multi-app user journeys is crucial for ensuring high quality, seamless omnichannel user experiences.

However, standard single-app test automation frameworks can only handle parts of the equation. They fail to support switching between native app and mobile browser contexts during tests.

This is what makes automating real mobile e2e user flows complex.

Why Automated Testing Matters

With mobile app usage growing exponentially year-over-year, continuously testing real user flows across the expanding combination of devices, operating systems and browsers is critical for developers.

Year	Mobile App Downloads	Growth
2020	230 billion	20%
2021	258 billion	12%

Manual testing struggles to keep pace with the velocity of changes in the mobile landscape and user expectations. Teams that rely solely on manual testing tend to miss critical issues that impact user experience.

The impact of mobile app issues can be severe:

• A 2021 study found a single poor mobile experience makes 60% of users less likely to use that app again.
• 79% of users who encounter problems using apps in the first 6 months will churn rather than find fixes.
• Buggy mobile apps cost companies over $100 billion annually in lost revenue and added costs.

By leveraging test automation for mobile apps and browsers, teams can shift their focus to innovation while ensuring continuallydelightful user experiences across key e2e flows.

Automating Real E2e User Flows with Appium

Appium is an open source test automation framework purpose-built for automating tests across native, mobile web and hybrid applications on iOS, Android and Windows platforms.

The key value Appium provides for automating real mobile e2e user flows is its ability to handle:

1. App Context Switching: Launching or activating multiple required apps – the native mobile app and required browser apps (Safari, Chrome etc).

2. Automation Context Switching: Seamlessly switching testing context between the native app elements and the browser app‘s webviews to replicate real user flows.

This powerful combined mobility and test context support makes Appium unmatched for automating real multi-app mobile user journeys.

Now let‘s explore patterns for leveraging Appium to automate tests spanning mobile apps and browsers using simple code examples in Java.

The workflows apply similarly for other languages/bindings like Python, JavaScript, C# etc. The core principles remain the same.

Automating Mobile E2E Flows: Android Example

For this Android example, we will use:

Native App: Wikipedia Sample App
Browser App: Chrome Mobile

The end-to-end flow will consist of:

1. Launching the Wikipedia App
2. Performing certain actions in the Wikipedia App
3. Opening Chrome Mobile browser
4. Logging into a website on Chrome
5. Switching back to the Wikipedia App to complete remaining actions

Here are the basics we need to automate this flow with Appium:

App               | Package Name              | Main Activity
-----------------------------------------------------------------------------
Wikipedia Sample  | org.wikipedia.alpha      | org.wikipedia.main.MainActivity   
Chrome Mobile     | com.android.chrome       | com.google.android.apps.chrome.Main

With Android, we leverage package name and main activity details to activate apps.

Launching the First App

We will configure the Wikipedia App details in desired capabilities to launch it automatically when tests start:

//Desired Capabilities
caps.setCapability("appPackage", "org.wikipedia.alpha");
caps.setCapability("appActivity", "org.wikipedia.main.MainActivity");

//Initialize driver 
AndroidDriver driver = new AndroidDriver(new URL("https://USER:[email protected]/wd/hub"), caps);

We can now perform test actions directly on the Wikipedia App using Appium driver commands.

Launching the Second Mobile App

To launch Chrome Mobile, we create an Activity object with the required Chrome browser app details:

Activity activity = new Activity("com.android.chrome", "com.google.android.apps.chrome.Main");

activity.setStopApp(false); //Don‘t reset app state

driver.startActivity(activity); //Launches Chrome mobile

Switching Automation Context

At this point we have opened Chrome Mobile but can only access native Chrome app elements.

To tap into webview elements and test browser workflow we need to switch automation context:

//Check multiple contexts available 
Set<String> contextNames = driver.getContextHandles();

for(String contextName : contextNames) {
   if(contextName.contains("WEBVIEW_chrome")) {
      driver.context(contextName); //Set context to Chrome‘s webview
   }
}

Now we can automate required actions in Chrome browser using Selenium browser commands.

Returning to the Original App

Once browser steps are complete, we need to return to the Wikipedia App to finish remaining test actions:

Activity returnActivity = new Activity("org.wikipedia.alpha", 
                                       "org.wikipedia.main.MainActivity");

returnActivity.setStopApp(false);

driver.startActivity(returnActivity); //Re-launch Wiki App

//Switch context back to native app
driver.context("NATIVE_APP");  

This completes our end-to-end test flow spanning the two apps!

Automating Mobile E2E Flows: iOS Example

For iOS apps, the bundle ID uniquely identifies apps instead of package name.

The process remains similar – we activate our required apps and switch automation context between native and webview elements.

Let‘s see an example flow between:

Native App: BrowserStack Sample App
Browser App: Safari

Launching the First iOS App

We configure the BrowserStack Sample App‘s bundle ID to launch it on test start:

//Desired Capabilities 
caps.setCapability("bundleId", "com.browserstack.Sample-iOS");  

//Initialize driver
IOSDriver driver = new IOSDriver(new URL("https://USER:[email protected]/wd/hub"), caps);  

Now we can automate test actions directly in the BrowserStack Sample App.

Enabling Safari Webview Access

Unlike Android, iOS does not expose Safari webviews by default which blocks context switching.

We need to enable Safari access by setting a capability:

caps.setCapability("includeSafariInWebviews", true);

Additional Safari webview details also help identify it correctly:

caps.setCapability("fullContextList", true);  

Launching Safari Browser App

With Safari web access enabled, we activate it using bundle ID:

driver.activateApp("com.apple.mobilesafari"); 

Switching to Safari Webview

We now need to switch context to Safari‘s webview before we can test browser workflow:

//Iterate over available contexts
for(Context context : driver.getContextHandles()) {

   //Select context with Safari‘s bundle ID 
   if(context.getBundleId().equals("com.apple.mobilesafari")) {
      driver.context(context.getId());
   }
}

We can now automate our browser test steps using Selenium browser commands.

Returning to the Original iOS App

Upon completing the browser workflow, we activate the initial BrowserStack Sample App again:

driver.activateApp("com.browserstack.Sample-iOS");

//Switch back to native app context
driver.context("NATIVE_APP");

This completes our sample end-to-end test automation spanning the iOS apps!

Key Takeaways and Next Steps

We walked through example test automation flows spanning native mobile apps and browser apps on Android and iOS powered by Appium.

Here are some key highlights:

• Appium enables reliable switching between multiple required apps during tests
• It allows switching automation context between native app elements and browser webviews
• This makes Appium ideal for automating real mobile e2e user flows across apps

To quickly experience the power of Appium test automation for complex, real mobile user journeys, get started on BrowserStack App Automate with a free trial.

BrowserStack provides instant access to 3000+ real Android and iOS devices plus a host of other Appium capabilities via the cloud for test automation.

I hope this post helped demystify how to approach automating mobile e2e flows. Feel free to reach out if you have any other questions!