Fingerprint and face authentication, NFC, camera capture, touch responsiveness and screen refresh behaviour either differ from the emulator or do not exist on it at all.
Stop testing on emulators. Validate on real hardware.
Mobile and cross-browser QA automation on physical iOS and Android devices, wired into the pipeline you already run. The handsets your users actually hold — chosen from your analytics, not from a catalogue.
Playwright and Selenium · suites running inside regulated banks · testing-led since 2010
The problem
Emulators miss what real users experience
One UI, MIUI, HyperOS and ColorOS change permission dialogs, notification behaviour and background execution limits. Skin differences bite harder than Android version differences, which is the part teams consistently get wrong.
Thermal throttling, low-RAM process kills, interruptions from calls and notifications, and a connection that is present but useless. None of it reproduces on a workstation with 32GB of RAM.
What we run
Real-device automation, inside your pipeline
Parallel execution with Playwright, Selenium and Appium across emulators for breadth and physical handsets for the paths that need them.
Biometric login, SMS and OTP autofill, device binding, Play Integrity, root and emulator detection, screenshot blocking. These are the flows that refuse to run anywhere but a real device.
Incoming calls, notifications, network handover, location behaviour, and what happens when the app is backgrounded by an aggressive battery manager.
Memory growth, CPU spikes, battery drain and thermal behaviour captured on the handset rather than inferred from a desktop run.
Coverage
Eight to twelve devices, chosen from your analytics
A hundred-device matrix is a procurement decision rather than a testing one. We pull ninety days of your own sessions by model and OS, cover down to roughly 80% of real users, then add the floor you still support deliberately.
| Tier | Where it runs | What it covers |
|---|---|---|
| Broad regression | Emulators and a cloud device farm | Functional coverage across many models, overnight |
| Authentication | Physical devices with live SIMs | Biometrics, SMS and OTP, device binding |
| Integrity and anti-fraud | Physical devices | Play Integrity, root and emulator detection, screenshot blocking |
| Degraded conditions | Physical devices | Thermal throttling, low-RAM kills, cell handover |
| Manufacturer skins | Physical devices | One UI, MIUI, HyperOS, ColorOS behaviour |
| Desktop browsers | Cloud grid | Chrome, Safari, Firefox and Edge across Windows and macOS |
What an emulator cannot reproduce, and how the device list is built: real device coverage in detail.
How we engage
Four steps to a suite that runs itself
-
Device coverage audit
Your own analytics, ninety days, by model and OS. We come back with the device list and what each one is there to catch.
Your users, not market share -
Framework and pipeline setup
Suites written in Playwright, Selenium or Appium against your stack, wired into the CI you already run rather than a new one.
-
Parallel execution and capture
Runs execute across devices with video, network logs, crash reports and traces captured on every failure.
-
Reproducible reports, then verification
Each defect arrives with the telemetry needed to reproduce it, and the fix is verified on the device that found it.
Reproducible or it is not a bug report
Track record
Fifteen platforms, in the domains where failure is expensive
Fintech, healthcare, legaltech, e-commerce and Web3 — web, mobile, API and performance. Named, because the work stands up.
| Platform | Domain | Stack |
|---|---|---|
| Under NDA | Fintech — lending, invoice factoring, savings | Cypress, WDIO + Appium, Postman, k6 |
| Under NDA | Fintech — payment gateway | Cypress, manual |
| CreditBook | Fintech — lending and savings | Jest, Appium, Selenium + Cucumber (Java) |
| Foree | Fintech — peer-to-peer payments | Selenium + Cucumber, Appium, RestAssured, JMeter |
| Foree Business | Fintech — billing aggregation | Playwright |
| Medtel | Healthcare | Playwright (TypeScript) |
| Castor EDC | Healthcare — clinical data capture | Cypress, Appium |
| DocsInk | Healthcare | Selenium + Cucumber (Node) |
| YouMedico | Healthcare | JMeter |
| GreenSign | LegalTech | Cypress, API automation |
| Myco | Web3 OTT platform | Cypress, JMeter |
| Ren’s Pets | E-commerce — Salesforce Commerce Cloud | Manual, exploratory |
| Mailtale | AI customer support | Manual |
| BoatBot | AI marine service platform | Manual, Android |
| GrapheneOS provisioning | Device automation | WDIO + Appium, RethinkDNS, Syncthing |
A portable suite that provisions Pixel phones running GrapheneOS from scratch — WDIO and Appium driving the handset, with RethinkDNS and Syncthing configured as part of the run. Device automation below the app layer, on hardware rather than an image.
Playwright, Cypress, Selenium, Appium, WDIO, Jest, RestAssured, Postman, JMeter and k6 — across TypeScript, JavaScript and Java. We fit the tool to your codebase rather than to our preference.
Appium and WDIO run through most of this list. Real-device mobile testing is not a line we added to a web practice — it is where a large share of the work has always been.
Common questions
Questions we get asked
Do you use a cloud device lab or physical hardware?
Both, for different jobs. A cloud farm is right for breadth — a regression run across many models overnight, or reproducing something on a handset nobody owns. It is wrong for anything needing a live SIM, enrolled biometrics, or where latency to a remote device changes what you are measuring. Those run on physical devices.
Can you work with our existing Playwright or Selenium suite?
Usually, and that is the preferred start. Rewriting a working suite is rarely justified. We assess what you have, extend it to the device tier, and wire it into the pipeline you already run rather than introducing a second one.
How do you handle security and data privacy?
Test data is synthetic or masked by default, and anything touching production data stays inside your environment. For regulated clients we work against your systems with your credentials and your approvals rather than exporting anything to ours. NDAs are routine and we sign yours rather than asking you to sign ours.
How many devices do we actually need?
Most teams land between eight and twelve, plus the floor they still support. The audit produces the specific list from your own session data — and it is almost never the handset anyone in the room is carrying.
Ready to stop shipping device-specific failures?
We will build you a device coverage matrix from your own analytics and tell you what it would take to run it. No obligation to proceed.