Synthetic testing is one of the most common ways teams check that their websites, apps and mobile journeys are working. It’s fast, repeatable and easy to schedule. But a green dashboard doesn’t always mean customers can complete what they came to do.
At World Telemedia Marbella 2026, GTT President Stephen Levenson put it simply: synthetic testing tells you what is healthy in a controlled environment, while real devices tell you what customers actually experience. This article explains the difference and how to use both.
What Is Synthetic Testing?
Synthetic testing, often called synthetic monitoring, uses scripts to run through a website or app on a schedule. The script follows a set path, such as loading a page, logging in or adding an item to a cart, and reports whether each step passed.
Because the script runs the same way every time, synthetic testing is good at:
- Checking that key pages and services are available
- Catching obvious errors quickly, often before customers notice
- Running the same test many times, around the clock
- Supporting development teams during build and release
These are real strengths, and most teams should keep using synthetic testing.
What Synthetic Testing Misses
The challenge is that synthetic tests run in a controlled environment. They often use a predictable location, a predictable browser setup and a predictable sequence of steps. Real customers don’t behave that way.
Here are the main gaps:
Device and browser variety. Customers use many different handsets, operating systems, browser versions, screen sizes and keyboards. A script usually covers only a few combinations.
Real network conditions. Synthetic tests often run on clean, fast connections. Customers use busy mobile networks, switch between Wi-Fi and mobile data, and lose signal.
Interruptions. A customer receives a call or a text, switches apps, presses Back or refreshes the page. A clean script rarely does any of this.
What the customer sees. A script can confirm a button exists in the page code. It can’t tell you that the keyboard is covering that button on a particular phone.
Local conditions. A script running from one location doesn’t show how a journey behaves in another country, where networks, payment methods and devices can all differ.
The result is a gap between “the system is up” and “the customer can complete the journey.” That gap is where lost sign-ups, failed payments and support tickets come from.
Where Emulators Fit In
Emulators sit between synthetic scripts and real devices. They copy the software of a phone on a computer, which lets teams check many configurations quickly and at a lower cost.
But an emulator is still a stand-in. It doesn’t fully reproduce touch behavior, keyboard behavior, screen rendering, memory limits or the way a real phone behaves on a local mobile network. Emulators are best used for scope, meaning broad coverage early on, rather than as final proof of the customer experience.
What Real Device Testing Adds
Real device testing checks the journey on actual phones and tablets, on real networks, the way customers use them. It shows:
- How the page looks and responds on specific handsets and screen sizes
- Whether the keyboard, permissions or pop-ups block any step
- How the journey behaves on slower or unstable connections
- Whether verification codes and confirmations arrive and display correctly
- How the journey performs in each country where you operate
When real device testing is done in-country by local testers, it also shows how the journey behaves on local networks, with local devices and local payment methods. That’s the view GTT provides through live testing in 200 countries.
Synthetic Testing vs. Real Device Testing at a Glance
Synthetic testing: Fast and repeatable. Best for availability checks and catching obvious errors early. Limited to the devices, browsers and conditions in the script.
Emulators: Quick and low cost. Best for checking many configurations during development. Can’t fully show real device behavior.
Real device testing: Shows the actual customer experience. Best for high-value journeys like login, checkout and payment, and for each market you serve. Takes more planning, so focus it where it matters most.
How to Combine Them
The goal is not to replace one method with another. It’s to use each one for what it does best. A practical approach looks like this:
- List your most important journeys. Start with registration, login, authentication, checkout, payment and account recovery.
- Use synthetic testing for speed. Keep scripts running for availability and early warning.
- Use emulators for scope. Check layout and function across many configurations during development.
- Use real devices for confidence. Confirm the high-value journeys on the devices and browsers your customers actually use, in the countries where they are.
- Test again after changes. Re-test after new releases, payment changes and major browser or operating system updates. Browser updates alone can change how sign-in, cookies and redirects behave.
- Learn from real failures. When something fails for customers, add that scenario to your test plan.
Signs Your Synthetic Testing Isn’t Enough
You may need real device testing if:
- Your dashboards are green, but customers still report problems
- Support tickets mention a step “not working” that your tests say is fine
- Completion rates differ a lot between countries or devices
- Problems appear after a browser or operating system update, with no new release on your side
- Payment disputes or duplicate charges are increasing
Related reading: Why Manual URL Testing Still Outperforms Automation
How GTT Can Help
Global Telecom Testing has been providing live, in-country testing since 2007, with more than 800 local testers in 200 countries. We help businesses see their mobile journeys the way customers do, on real devices and real local networks.
Our services include mobile app testing, URL testing, OTP testing and SMS testing, as well as our Automated Testing Platform.
Want to see how your journeys perform for real customers? Request a free trial test.
FAQs
What is synthetic testing?
Synthetic testing uses scripts to run through a website, app or mobile journey on a schedule and report whether each step passed. It’s fast, repeatable and useful for checking availability and catching obvious errors.
What is the difference between synthetic testing and real device testing?
Synthetic testing runs scripted checks in a controlled environment. Real device testing checks the journey on actual phones and networks, the way customers use them. Synthetic testing shows whether the system works; real device testing shows whether customers can complete the journey.
Should I stop using synthetic monitoring?
No. Synthetic monitoring is valuable for speed and early warning. The strongest approach combines synthetic testing, emulators and real device testing, each used for what it does best.
Why do customers report problems when synthetic tests pass?
Customers use different devices, browsers and networks, and they get interrupted, switch apps and refresh pages. These real conditions can cause failures that a clean, scripted test never meets.
How often should I run real device tests?
Focus on your highest-value journeys and test them before launch, after significant changes and after major browser or operating system updates. Testing in each market you serve helps you find local issues before customers do.
