Automated Mobile Testing: Native and Responsive Apps

In a nutshell

A mobile test simulates a user journey on the native iOS and Android apps and on the mobile version of the website. It runs on farms of real devices, using gestures specific to mobile devices: swiping, long press, rotation, and notifications. Proper rendering in a resized window says nothing about the actual user experience.

You can't test the mobile version by resizing the window

A minimized browser window does not replicate the memory of an entry-level phone, the native keyboard that covers the input field, or the version of Android that your customers are still using. The reverse is also true: a website that passes all validation tests on a computer may have its order button off-screen on an iPhone SE, without any tests having caught it.

True native apps

Your iOS and Android apps tested on real device farms, using your users' OS versions.

The Web for Mobile Devices

The same browser navigation paths replayed at your audience’s screen sizes, revealing where content overflows and unreachable buttons are hidden.

A fleet, not a model

You choose which device and OS combinations to support based on your usage statistics rather than the latest model released.

Mobile-specific gestures

Scrolling, long press, rotation, system back button, resuming after being minimized. These features don't exist on a computer.

Every build is tested before it reaches the app stores

Your mobile tests are triggered from your CI, run on real devices, and report back to where your teams are already working. No need to set up new tools.

1 Triggering Your tools stay in control

GitLab
Jenkins
Microsoft Azure
API Call
Planning

2 Execution

Your scripts run on your production environments

Web Tour
Native iOS and Android Apps
Real Mobile Farms
APIs and Internal Feeds

3 Restitution The results are delivered right to your workplace

Jira
Slack
SMS
Webhook
API

And maintenance that stands the test of time

Reusable blocksA change updates all scenarios that use it
AI-Assisted CorrectionSuggested corrections for scenarios with errors
Grouping IncidentsSimilar anomalies are processed only once

How Automation Is Changing Things, Line by Line

Manual Mobile TestingWith Mr Suricate

Manual Mobile Testing

With Mr Suricate

Two phones on a corner of the desk—let's hope that's enough.

A fleet of actual terminals, covered in every campaign.

You can test the responsiveness by resizing the browser window.

The playthroughs are replayed at their actual resolutions.

A rollback to an older version of Android goes unnoticed.

The OS versions on your devices have been tested.

The app and the website are tested separately by two teams.

Both scopes are contained within the same test suite.

You can find the off-screen button through a notification in the app store.

You can see this in the screenshot of the program running.

Each mobile release goes through another round of manual testing.

The campaign restarts automatically with each build.

ResultYour ad placements verified on the devices and screen resolutions your customers actually use, with every delivery.

On actual terminals

The user experience, interactions, and notifications as the user perceives them

Differences between OS versions and among manufacturers are becoming apparent

Network behavior and permissions are actually enforced

In a resized browser

Sufficient for a layout check

Doesn't mention notifications or permissions

Hides differences between manufacturers

mobile testing, cross-browser testing, dataset: the definitions are in the QA glossary.

WHITE PAPER · TEST AUTOMATIONWhat if your bugs no longer cost your business anything?The true cost of mobile bugs, and how to build an automation strategy that keeps pace with app releases.

Download the white paper

“An easy-to-use, fun tool that’s similar to Scratch. The campaign management feature gives me peace of mind before each deployment.”

Coralie Cebron de LisleSoftware Tester, Optivalue

Your mobile scripts—written by you or by us

With Mr Suricate, your QA team isn't replaced—it's strengthened. You choose what to handle in-house and what to outsource: creating test scenarios, running them, or maintaining them over time.

1Identification of critical paths, front-end and back-end
2Writing Tests Without Code
3Continuous monitoring and alerts
4Scenario Maintenance and Development

ResultYou gain broader coverage without increasing your teams’ workload. And if you’d rather delegate everything, QA outsourcing takes over.

GO FURTHER

Other Types of Tests

Fifteen types of tests, four categories. Each one answers a different question about your application.

Functional TestsVerify that a feature produces the expected result from the user's perspective.Learn more Non-regression testingRe-run all validated test cases before each deployment.Learn more End-to-end testingThe complete user flow, from start to finish, including third-party systems.Learn more Performance testingThe actual response time of your workflows, continuously measured and compared to your thresholds.Learn more Visual testingPixel-by-pixel visual comparison for changes that no assertion can detect.Learn more Accessibility testingAutomatically verifies that your user flows comply with accessibility criteria.Learn more Security testingCheck what a user can actually access: permissions by profile, sessions, authentication, HTTPS.Learn more The 15 types of testsThe big picture: four categories, fifteen types, and where to start based on your situation.Learn more

Is there a term you don't understand? The automated testing glossary defines it.

YOUR QUESTIONS

Frequently Asked Questions

The most common questions we get about mobile testing.

Are you testing the actual native apps, or just the responsive website?

Both. iOS and Android apps are run on actual device farms, and your web experiences are also tested at mobile resolutions. These are two distinct areas—often confused with one another—and they are addressed in the same test plan.

On which devices are the tests run?

On actual devices and across the combinations of models and OS versions you choose. The right criterion is your own audience breakdown, not the latest device released: it’s often an older model that reveals the flaws.

Do you need to write a different script for iOS and Android?

The two platforms do not have the same components or system actions, so the scenario is tailored to each one. However, the workflow logic and test data are shared, and reusable blocks prevent the need to duplicate everything.

Isn't responsive design enough?

It depends on what you're selling. If your native app generates revenue or provides customer service, it needs to be tested on its own: a validated responsive website says nothing about how the app will behave on a phone that's running other apps, has a weak connection, or receives a notification that interrupts the user experience.

Do you need to write code to automate a mobile test?

No. Mobile test cases are built just like any others, either through assisted recording or by assembling test blocks. This is what allows a business profile to keep test coverage up to date as the application is released.

What do the tests actually run on?

On actual device fleets via our partners BrowserStack and LambdaTest, using the model and version selected for the test. We manage this infrastructure for you. We do not operate our own fleet of phones, and the number of concurrent runs depends on the licenses specified in the contract.

Are the blocks the same as on the web?

No, and that’s important. A native app scenario uses a dedicated catalog: tapping an element or a set of coordinates, scrolling on the screen or within an element, gesture chaining, and iOS and Android selectors. The engine is different; you choose it when you create the scenario.

How do we provide the application to be tested?

The application file is stored in the document management section of your account, and the scenario is based on it. A new version replaces the old one in the same location, without affecting the scenarios.

What is covered beyond the nominal term?

Data entry in code, PIN, or OTP fields; limiting network throughput to simulate a degraded connection; bypassing the phone’s calendar and system dialog boxes; and hiding the keyboard. These are the factors that cause a mobile test to fail far more often than the user flow itself.

Mobile Testing: Native Apps vs. Responsive Design— Put to the Test

They trust us