Mobile automation testing has every problem web testing has, and a few of its own. Before you write a single test you need devices: emulators, simulators, real phones, or a device cloud. Every build has to be installed before it can be tested. Android and iOS find elements differently. And a test that passes on one phone can still fail on the next.
This guide walks through a complete mobile automation workflow in Testver, from connecting a first device to a suite that runs on its own, and shows where AI saves time at each step. It covers native Android and iOS apps and hybrid apps with webviews, all through Appium.
Mobile testing in Testver is in beta. Everything below works today. We're adding to it with every release, so tell us what you need next.
Before you start
You need four things:
Testver running on your test project. Run testver serve in the project folder (new here? start with Meet Testver).
Testver switched to Mobile. Choose Mobile Testing during first-time setup, or later under Settings → General → App Mode. The Runner, AI Record and the AI Assistant then show devices and app builds instead of browsers.
An Appium test project. Testver works with the Appium frameworks teams already use: Java with TestNG, Kotlin, Python with pytest, C# with NUnit, Ruby with RSpec, WebdriverIO, and Robot Framework with AppiumLibrary. No project yet? The AI Assistant can create a complete Appium frameworkfor your app, with screen objects that prefer accessibility ids.
An AI connection. Testver cloud AI (the free Starter plan needs no card) or a local model through Ollama or LM Studio.
Step 1: Connect your devices
Tests need somewhere to run, and Testver gives you two kinds of places.
Devices on your own computer. Under Settings → Connectors → Local Devices (Appium), Testver checks what your machine already has: the Appium server, Android's ADB and SDK, and the UiAutomator2 and XCUITest drivers. Each item shows green, amber or red, and anything missing comes with a command you can copy to install it. When everything is green the section says Ready. It then lists phones plugged in over USB, running Android emulators and iOS simulators. Emulators you've set up but haven't started appear too, and start when you pick them. Local devices use no cloud minutes and give the fastest feedback while you're writing tests. iOS testing on your own machine needs a Mac.
A device cloud. If you'd rather not keep phones on your desk, connect BrowserStack, LambdaTest or Sauce Labs under Connectors. Testver uploads your app and adds the device settings for you, with no changes to your test code. An unchanged build isn't uploaded twice.
Tip: use an emulator while you write a test, then run it on real devices in the cloud before a release.
Step 2: Record a test on a real device
Open AI Record and choose Record Mobile App Interactions. Pick a Provider (your local devices or a device cloud), a Device and an App, or upload a new .apk or .ipa. Press Start Recording. A live mirror of the device appears beside the recorder.
Tap through your app in the mirror, or pick up the phone and use it by hand: every tap, swipe and text entry becomes a numbered step. The Back, Home, Enter, volume and power buttons are there too. Add assertions so the test checks what's on screen, not just that the taps worked.
Hybrid apps work too. When you move into a webview, a WEBVIEW marker appears and Testver records web-style locators inside it. The generated test switches between the native and web parts of the app on its own.
When you're done, press Stop, then press Generate. The AI writes the test in your project's language and style, reusing the screen objects you already have.
Step 3: Or ask the AI Assistant
Some tests are faster to describe than to tap through. Switch the AI Assistant to Mobile mode. A Mobile session bar lets you choose a provider, a device and an app; press Start session and the panel on the right mirrors the device. Then ask, for example:
Write a test that signs in with a valid account and checks that the home screen shows the user's name.
The assistant reads your project, works with the real app on the device to find the right elements, writes the test and runs it. It can scroll to an element, wait for it, handle system pop-ups, rotate the screen, and switch between the native and webview parts of a hybrid app. In Manual mode, the default, it asks before it writes a file or runs a command.
Starting from nothing? Describe the framework you want and the assistant builds it:
Create an Appium framework in TypeScript with WebdriverIO for my Android app (apps/shop.apk) on an Android emulator.
Step 4: Run it on any device
Open the Test from Test Explorer and choose where to run next to Run on: Local Devices, or one of your device clouds. Then pick a device with Select a device and a build with Pick app or upload. The same device and app pickers appear wherever you start a run: on a test in Test Explorer, in a suite's run options, in a test cycle's run settings, and in a schedule.
Give your builds names, such as Dev, QA or Prod, and pick them by name instead of hunting for files. While a test runs, a live view of the device mirrors the screen, so you can watch it work.
Step 5: Read the results
Every run lands in Results, labelled with the device it ran on, alongside the full history of each test. For device cloud runs, Testver brings back the provider's video and logs, with a link straight to the session in BrowserStack, LambdaTest or Sauce Labs.
Step 6: When a test fails
The app changed and a locator broke. A renamed resource id or a changed accessibility label is the most common cause of red mobile builds. Auto-Heal reads the app's live screen layout, proposes a new locator in your framework's own style (a resource id, accessibility id, UiSelector or iOS predicate), then re-runs the affected tests to prove the fix. Nothing is kept unless that run passes. Start in Suggest mode (Settings → General → Auto-Heal) and apply verified fixes from Results with one click.
Something else went wrong. Failure analysis groups failures by root cause and explains each one in plain English. Fix in AI Assistant opens the failure in Mobile mode, ready to investigate on a device.
Step 7: Make it run without you
Schedules run your mobile suite on a timer, a daily smoke test on a local emulator or a nightly regression on cloud devices, with pause, resume and run now. Choose Run On → Local Devices or a device cloud, then the device and app, exactly as in the Runner.
Tips for mobile tests that stay reliable
Prefer accessibility ids. They're the most stable locator on both Android and iOS, and they make your app more accessible too.
Start each test from a clean app. For Android on local devices, turn on Fresh start (clear data), and let Testver grant app permissions automatically so permission pop-ups don't interrupt the test.
Name your builds and test against the same named build in every run, so a failure means the app changed, not the file.
Mix emulators and real devices. Emulators are fast for everyday work; real devices catch what emulators miss.
Keep one session per device. A local device runs one test at a time, so add devices, or use a device cloud, when you need more in parallel.
Turn on Auto-Heal in Suggest mode and review its fixes in Results for the first few weeks.
Wrapping up
The whole loop is the same as on the web: connect a device, record or describe a test, run it anywhere, read what happened, let Auto-Heal handle UI changes, and put the suite on a schedule. Your tests stay plain Appium code in your own repository throughout.
Learn more in the docs: Local Devices setup, AI Record, device clouds and Auto-Heal. And if you test the web too, read web automation testing with Testver.