Mobile App Testing on a Real Android Phone, Without Code
Mobile app testing on a real Android phone: what emulators miss, what to test, and how to record and run tests on your own phone with no code and nothing added to your app.
10 min readBy the GUI Test Studio team
Why test on a real phone?
Definition
Mobile app testing checks that an app works on the phones your users really have.
- An emulator, a virtual phone on your computer, is quick to start and fine for early checks.
- A real phone is where your users meet your app, and some bugs only live there.
An emulator misses what each phone adds on its own.
- Manufacturers change the system's look, its dialogs and its keyboard, and your app's screens sit beside them.
- A mid-range phone is slower than your computer, and a screen that waits for nothing on an emulator may not be ready in time.
- A long label that fits on a large virtual screen is cut off on a small real one.
- Permission requests, notifications and the real network all behave a little differently on a device in a hand.
| Question | Emulator | Real phone |
|---|---|---|
| Quick to start? | Yes, on your computer. | Plug it in by USB. |
| The manufacturer's own screens and keyboard? | No: a plain system. | Yes, as your users get them. |
| Real speed? | Your computer's. | The phone's own. |
| Best for | Early checks, many screen sizes. | Critical journeys before a release. |
What to test in a mobile app
A mobile test suite covers four kinds of things.
Journeys
The journeys users take every day, from opening the app to the result they came for: sign-in, search, checkout.
Texts and values
The texts and values they read: a confirmation, a total, a date, an error message when a field is wrong.
Screen sizes
The layout on small and large screens, where labels are cut off and buttons pushed off the screen.
The phone's own screens
The system's own screens your app relies on: a permission request, the keyboard covering a field, a notification on top of the app.
How mobile tests are usually automated
Most teams try one of three ways, and each has its price.
| Way | How it works | The price |
|---|---|---|
| Manual testing | A tester goes through the app on a phone before each release. | Slow, repeated by hand every release, and the first thing cut when time runs out. |
| Coded mobile tests | A developer writes test code that drives the app through a driver installed beside it, and finds buttons by the ids the app exposes. | It needs a developer, ids on every element, and repairs whenever the screens change. |
| A device farm in the cloud | Tests run on phones in someone else's data center. | Your app and its test data leave your company, and every minute is billed. |
Your user never sees an element id.They see the screen.
Test an Android app on a real phone, without code
GUI Test Studio takes another way: it tests the app through the phone's screen, as a person uses it.Nothing is added to your app, nothing is installed on the phone, and nobody writes test code.
- 1
Turn on USB debugging, once
In the phone's settings, under About phone, tap Build number seven times to show the developer options, then switch on USB debugging.Plug the phone in, and tap Allow when it asks whether to trust this computer.
- 2
Open the screen where your test starts
On the phone, open your app on the screen where the journey begins.The recording starts from what the phone shows.
- 3
Click Record, then pick A phone
In GUI Test Runner-Recorder, click Record.The question that follows offers A phone (Android): it shows the phone as ready, or says what is still missing.The phone's screen then appears in a window in the middle of your screen.
- 4
Use your app in the phone's window
Click, drag and type in that window with the mouse and the keyboard: everything happens on the phone.Go through the journey the way a user would, then stop the recording.What you do on the phone itself is not recorded, so keep to the window.
- 5
Save the test
Choose what the test should verify, and save it.Open it in GUI Test Studio to see every step and check on the timeline.See Record a test.
What a test checks on the phone
While you record, GUI Test Studio adds checks of what the phone shows: the element each tap was aimed at, and what appeared after it, a dialog, a message, a new screen.You can add your own on the timeline afterwards.
Visual Assert
The Pay button looks as recorded
Text Assert
"Order confirmed" is written on the screen
Dynamic Text Assert
A total of any amount, shaped like a price
Checks look at the screen, not at the app's code.
- A redesign of the code behind a screen does not break them, as long as the screen looks right.
- A changed word, a missing button or a wrong total fails them.
- Slight rendering differences that no person would notice are ignored.
Which check suits which element is explained in Choose a check.
Run it again, on this phone or any phone
A recording on a phone starts with a Connect Phone step, added by itself.When the test runs, it puts the phone's window back in the middle of the screen at the size it was recorded, replays every step on the phone, and takes the window down at the end.
You choose which phone a test runs on.
- Keep Any phone plugged in to run on whichever phone is there, or pick one phone so the test always runs on it.
- When the phone is missing or not allowed yet, the run says so before it starts, instead of failing half way.
On your build machine
Plug the phone into the Windows build machine and add the test to your pipeline. gtr-cli runs it like any other test: a failed check fails the build, with the expected and found pictures kept.
gtr-cli run tests\mobile --countdown 0 --junit results\junit.xmlThe options and the CI tools are in Run tests in your pipeline.
Phone plugged in
USB debugging on, once
Connect Phone
Its screen appears on the computer
Steps replayed
On the phone, for real
Confidence Report
Every check, with pictures
Other phones, tablets, web pages and iPhones
Another phone model, another look
A phone of another size or brand may show your app slightly differently: another font, another spacing.For the checks that compare pictures, keep one version per phone model with baselines, and choose which one a run uses.
A web page on phones
A web app is tested differently: record it once in a browser on your computer, and GUI Test Studio makes the same test for phones and tablets held either way, in Chrome, Edge and Firefox.See cross-browser testing.
iPhone and iPad
Stream the iPhone or iPad screen to Windows with a screen-mirroring app, and record that app's window like any other app.Whether clicks reach the device depends on the mirroring app you choose.
Or ask your AI assistant
Describe the journey to Claude, ChatGPT or a local AI model, one we provide or your own, and add "on my phone": the assistant records the test in the phone's window for you.See Create a test from a prompt.
Do
- Critical journeys on a real phone before every release
- Open the starting screen on the phone before you record
- Use the phone's window, with the mouse and the keyboard
- One baseline per phone model for picture checks
Avoid
- Testing only on emulators
- Tapping the phone itself while recording
- Leaving the phone locked when a run starts
- Expecting a picture taken on one model to match another
Key takeaways
- 1Emulators for early checks, a real phone before every release: some bugs only live on real devices.
- 2Test what users see, the journeys, the texts and the layout on the screen, not the ids in the code.
- 3Nothing in your app, nothing on the phone: USB debugging once, and the phone's screen appears on your computer.
- 4Record in the phone's window with the mouse and the keyboard, and it becomes a test that replays on the phone.
- 5Run it on any phone, and on your build machine with gtr-cli.
Questions
Should I test mobile apps on a real device or an emulator?
Both have a place.An emulator is quick to start and good for early checks.A real phone shows what your users really get: the manufacturer's own system screens and keyboard, real speed on a mid-range phone, real touch and real network.Test your critical journeys on at least one real phone before every release.
Can I automate Android app testing without code?
Yes.With GUI Test Studio, plug the phone in by USB, click Record and use your app in the phone's window on your computer.The clicks, the typing and the checks of what appeared become a test, which replays on the phone by itself.
Do I need to change my app or install anything on the phone?
No.Nothing is added to your app and nothing is installed on the phone.Turn on USB debugging once in the phone's developer options and allow the computer when the phone asks.Everything else comes with GUI Test Studio's installer.
Can the same test run on another Android phone?
Yes.A test can run on whichever phone is plugged in, or always on one phone you choose.A phone of another size or brand may show your app a little differently, so keep a baseline per phone model for the checks that compare pictures.
Can I run mobile app tests in a CI/CD pipeline?
Yes.Plug the phone into the Windows build machine and run the test with gtr-cli.The run puts the phone's screen up, replays the test, takes it down again, and fails the build when a check fails.
Does an Android emulator work too?
Yes.A running Android emulator counts as a phone: GUI Test Studio records and runs on it exactly as on a real one.
Can GUI Test Studio test iPhone apps?
Through a screen-mirroring app that streams the iPhone or iPad screen to Windows.The test records that app's window like any other app, and its checks see the iPhone's screen as it is shown.Whether clicks reach the device depends on the mirroring app.
Android, Chrome, iPhone, iPad, Edge, Firefox, Claude and ChatGPT are trademarks of their respective owners.
Ready to record your first test?
Every feature, for 15 days.
Rather see it on the kind of app you test?Book a free 30-minute call with our team.