Your product owner sends you a screenshot from Google Play: the app’s rating has dropped from 4.5 to 3.9 in two weeks. Three sentences keep coming up in the reviews: “doesn’t work after the update”, “the payment screen freezes”, “on my phone the buttons are off the screen”. The team is puzzled, because the app passed testing on three phones in the office: two iPhones and one flagship Android. None of them had a small screen, an older OS version or the manufacturer skin that a large share of your customers use.
As tech lead, you are told: “outsource mobile testing so this doesn’t happen again”. The first vendor calls end with questions you have no ready answers to. How many devices? Physical or in the cloud? Manual tests, automated, or both? Security as well? Every answer changes the price, and the quotes that arrive differ so much that they are hard to compare.
This article helps you make those decisions before you send a request for proposal. We do not explain mobile testing from the ground up; Mobile application tests: what they are, how the process works and how to measure their effectiveness does that. Here we deal with buying the service: how to set the scope and device matrix, when a cloud farm is enough, what to automate, what drives the price and what to put in the contract.
What are you buying when you order mobile app testing as a service?
You are buying three things at once, and quotes often price only one of them. The first is tester work: designing and running tests, reporting defects, reporting results. The second is device access: physical phones and tablets, or a cloud device farm. The third is platform knowledge: understanding how iOS and Android differ, how manufacturer skins behave, how permissions, notifications, background execution and store publishing work.
Mobile testing differs from web testing in several ways that translate directly into cost. The app has to be checked on two platforms with different rules. On Android, the number of combinations of manufacturer, model, OS version and screen size is very large. The app runs in conditions a desktop browser never meets: interruptions from calls and notifications, loss of signal, moving to the background, low battery, screen rotation. Then there is the release process: test builds, TestFlight, Google Play testing tracks, store review.
That is why the cheap version of the service usually means “manual tests on whatever devices the vendor happens to have”. That can be enough for a simple app with a narrow user base, but it will not solve the problem from the introduction, because it does not start by asking which devices your customers use.
Before you compare quotes, write down three things: what problem you want to solve (failures after releases, poor store ratings, preparing for launch, security requirements), how often you release the app, and whether testing is one-off or ongoing. The whole scope follows from those answers.
What test scope does your app need?
The full list of mobile test types is long, but not every app needs all of them. Below are the areas worth considering, each with a question that helps decide whether it applies to you.
Functional and regression testing. Does the app do what it should, and has the new release broken what used to work? This is the core of every service. Question: which journeys generate revenue or block the user when they fail?
Compatibility. Does the app work and look right on different devices, OS versions and screen sizes? This is the area most often behind “doesn’t work on my phone” reviews. Question: how varied is your users’ hardware?
Real-world conditions and interruptions. Weak signal, switching between Wi-Fi and mobile data, airplane mode, an incoming call during payment, the app going to the background and coming back. Question: do users use the app on the move?
Performance and resource use. Launch time, scrolling smoothness, memory and battery use, app size. Question: do your users have lower-end phones, and does the app run in the background for long?
Usability and accessibility. Is the interface clear, are targets large enough, does the app work with screen readers and larger text? Question: is your app subject to accessibility requirements, for example as a service covered by the European Accessibility Act?
Security. Data stored on the device, communication with the API, authentication, tamper resistance. The reference point is OWASP MASVS, the mobile application security verification standard, which groups requirements into eight areas: storage, cryptography, authentication and authorisation, network communication, platform interaction, code quality, resilience against reverse engineering and tampering, and privacy. Question: does the app process personal, financial or health data?
Hardware integrations. Camera, Bluetooth, NFC, GPS, biometrics, contactless payments. Question: does the app use anything beyond the screen and the network?
Release readiness. Compliance with store guidelines, permissions, store listings, first-launch behaviour and upgrade from the previous version. Question: how often is the app rejected or broken by an update?
Choose the areas that answer your questions and list them in the request. A quote for “full mobile testing” without a list of areas cannot be compared or accepted.
How many devices should you test, and how do you choose them?
The number of devices is the most common question and the most common source of overpaying in both directions. Too few devices and testing misses the problems customers see. Too many and you pay for regression on hardware nobody uses.
A device matrix is built from data, not intuition. Start with your own app analytics: Firebase, App Store Connect, Google Play Console or another tool will show which models and OS versions your users have. If the app does not exist yet, start from market data. According to StatCounter, in October 2026 Android held 63.7% of the mobile operating system market in Europe and iOS 36.3%. Shares vary by country, so check the figures for the markets you actually serve. Either way, neither platform can be treated as an afterthought, and Android device diversity will be the main challenge.
A typical matrix has three layers. The core is a handful of devices on which you run full regression before every release: the most popular models among your users on both platforms, on the most common OS versions. Edge cases are the devices that most often expose defects: the smallest supported screen, the oldest supported OS version, the weakest hardware, a tablet if the app supports one, and phones from manufacturers whose Android skins handle background work and notifications differently. The wide pool is dozens of models on which you run quick automated tests or an install-and-launch check, usually in a cloud farm.
The matrix should be a living document. Every quarter, compare it with your analytics and update it: new models enter the core, old ones drop out, and when you raise the minimum supported OS version, some edge cases disappear. The vendor should do this with you, not stick to the list of devices on its shelf.
Cloud device farm or physical devices: which should you choose?
A cloud device farm is a service where you run tests on real phones and tablets in the provider’s data centre, remotely, either manually or automatically. The alternative is physical devices with the tester or in your office. Both have their place, and the decision affects both cost and what can be tested.
Farm prices are public, so you can check them before talking to a testing vendor. AWS Device Farm charges $0.17 per device minute for tests on real devices, or, on the unmetered plan, from $250 per device slot per month; private devices dedicated to your account start at $200 per month. Firebase Test Lab on the Blaze plan costs $5 per hour on a physical device and $1 per hour on a virtual device, with 30 free minutes a day on physical devices and 60 on virtual ones. Commercial testing platforms have their own price lists, usually as subscriptions based on the number of parallel sessions.
A cloud farm wins when you need a wide pool of models, run automated tests in CI, want to check a specific model mentioned in a review or do not want to buy and maintain hardware. It also gives access to new models on launch day without purchasing.
Physical devices win when tests require contact with the hardware: Bluetooth and NFC, accessories, the camera, sensors, contactless payments, field tests on a weak signal, long battery-drain tests and a subjective judgement of smoothness and gestures. Also when your security policy does not allow builds with test data to be installed on shared infrastructure.
In practice a mixed model usually works best: several to a dozen or so physical devices from the core of the matrix for manual testing, and a farm for automation and the wide pool. Ask the vendor which devices it physically owns, which farm it uses, who pays for the minutes and whether the farm cost is included in the rate or invoiced separately. If you pay for the farm directly, you control the cost and keep access after the engagement ends.
When is an emulator or simulator enough, and when is it not?
Android emulators and iOS simulators are free, fast and easy to run in CI. They are a daily tool for developers and have a place in testing, but they do not replace real devices for pre-release testing.
An emulator works well for quick automated tests on every code change, for logic and UI tests across screen sizes, and for testing different OS versions and locales. It is the cheapest way to catch regressions early, before a build reaches testers.
An emulator does not faithfully reproduce real hardware performance, especially on lower-end devices, manufacturer skin behaviour, work with the camera, sensors, Bluetooth and NFC, battery use or real network conditions. The iOS simulator is not a hardware emulator at all; it runs the app compiled for the computer, so some performance and memory problems will never appear on it.
A sensible split looks like this: emulators and simulators in CI for fast feedback on every change, a device farm for automated regression on real hardware before release, and physical devices for manual, exploratory and hardware tests. If a quote bases all testing on emulators, ask how the vendor will catch the problems your users see on specific models.
Manual or automated testing for mobile apps?
It is not an either-or choice. The question is which tests to automate, which to leave to people, and what each decision costs.
Automation pays off for stable critical journeys repeated with every release: sign-up and sign-in, search, basket and payment, key forms. With releases every two weeks on two platforms, manual regression of these journeys on several devices quickly becomes the largest line in the testing budget. Automation lets you run them on a device farm in CI, overnight and on every release candidate.
Manual testing is better for new features that are still changing, usability and gestures, exploratory testing, where a tester looks for problems nobody anticipated, and hardware and field tests. Here automation is expensive to build and maintain, and its value is low.
Mobile automation tools fall into cross-platform and native ones. Appium lets you write tests for iOS and Android with one approach and is among the tools ARDURA lists on its software testing services page. The platforms’ native tools, such as Espresso for Android and XCUITest for iOS, are faster and more stable but require two test suites and closer work with the app’s code. The choice depends on who will maintain the tests, whether the app is native or cross-platform and how many journeys are to be automated.
Remember that automation has a maintenance cost: every UI change requires updating tests. For what building and maintaining automation costs, see How much does test automation cost in 2026?. In your request for proposal, ask for automation to be priced separately from manual testing, with an estimate of maintenance in the following months.
What does the engagement timeline and release rhythm look like?
Mobile testing services usually take one of two shapes: a one-off engagement before a launch or major release, or ongoing work in the release rhythm. Timeline and cost differ in each case.
A one-off pre-launch engagement usually takes two to four weeks. The first week is app analysis, agreeing the device matrix, preparing test cases for critical journeys and test accounts. Weeks two and three are test execution on devices, defect reporting and retesting fixes. The final days are testing the release candidate, checking the upgrade from the previous version and a report with a recommendation: release or not.
Ongoing work follows the release rhythm. With releases every two weeks, a typical cycle is testing new features during the sprint, regression on the matrix core before release, a quick run on the wide pool in the farm, an upgrade test and a post-release check. Over time a growing share of regression moves to automation, and testers focus on new features and exploratory testing.
There is also a third rhythm buyers often forget: new operating system versions. Apple and Google release major iOS and Android updates every year, preceded by public betas. A new OS version can change the rules for permissions, background execution, notifications or UI components, and users install it regardless of your release calendar. A well-planned service includes testing the app on the beta of the new OS before it reaches users and a quick regression after its release. If an ongoing-work quote does not mention this, ask how the vendor handles OS launches and whether that test is included or priced separately. For one-off engagements, simply plan such a test once a year ahead of the new OS release, because that is when the risk of “stopped working after the update” reviews rises.
The release process also affects the timeline and cannot be rushed. New Google Play developer accounts face an extra requirement: according to Google Play Console Help, personal accounts created after 13 November 2023 must run a closed test of the app with at least 12 testers who have been opted in continuously for at least 14 days before the app can go to production. If that applies to you, add those two weeks to the launch plan and ask the vendor whether it can help organise such a test.
What drives the price of mobile app testing?
The price of the service is mostly tester days multiplied by the rate, plus device access. QA rates are similar across quotes; the differences come from the number of days, which depends on the factors in the table below.
| Factor | What lowers the cost | What raises the cost | Check question |
|---|---|---|---|
| Platforms and technology | One platform, or a cross-platform app with a simple UI | Native iOS and Android, separate codebases, tablets | Do both platforms have the same feature set? |
| Number of screens and journeys | A few screens, simple forms | Dozens of screens, multi-step processes, user roles | Which journeys are critical for revenue? |
| Device matrix | A few core devices, uniform user hardware | A dozen or more core devices, wide Android diversity | What do analytics show about users’ devices? |
| Hardware integrations | None, just screen and network | Bluetooth, NFC, camera, GPS, biometrics, payments | Do tests require physical contact with the device? |
| External integrations | One in-house API | Payments, maps, social login, partner systems | Are test environments available for integrations? |
| Security | Basic checks within functional testing | Security test against OWASP MASVS, API tests, build analysis | What data does the app process? |
| Automation | None, or maintaining existing tests | Building a framework from scratch for two platforms | How many journeys will be automated, and who maintains them? |
| Release rhythm | A few releases a year | Weekly or fortnightly releases | How many times a month is regression needed? |
| Device access | Farm paid directly by you, small pool | Large pool, private devices, hardware purchases | Who pays for the farm and the hardware? |
| Localisation | One language | Many languages, right-to-left scripts, regional formats | How many languages does the app support? |
Two factors most often surprise buyers. The first is the dual platform: a native app on iOS and Android is in practice two apps to test, not one app on two phones. The second is the release rhythm: the cost of regression multiplies by the number of releases, so with frequent releases automation stops being an option and becomes the way to contain cost.
What does it cost, and how can you estimate the range yourself?
There is no single price list for mobile testing, but you can work out a range from the rate and the number of days. Start with the rate: in ARDURA’s pricing, a senior QA engineer costs €335–465 per day net, and manual testers start from €130 per day. For a broader view of market rates, see QA outsourcing rates: what to expect in Poland and CEE 2026.
The ranges below are our estimate for typical engagements, not a market fact or a price list; the factors in the table above move them.
- Pre-release test of a simple app (one platform or cross-platform, a dozen or so screens, a matrix of a few devices, manual functional and compatibility testing, a report): about 5–10 days. At the senior rate that is roughly €1,700–4,650, less if part of the work is done by a manual tester at a lower rate.
- Pre-launch test of an iOS and Android app (dozens of screens, several integrations, a matrix of a dozen or so devices, network conditions and interruptions, basic security, retests): about 10–20 days, roughly €3,350–9,300.
- Ongoing work in the release rhythm (regression every two weeks on two platforms, testing new features, gradual automation of critical journeys): billed monthly as the cost of one or more people in the team, plus device farm access.
Add device access to the labour cost. With a farm billed per minute, the cost depends on test duration and the number of devices; for example, a one-hour automated run on 10 devices in AWS Device Farm is 600 device minutes, which at list price comes to $102. With frequent runs, a plan with a fixed number of slots is often better value. If you buy physical devices, spread their cost over several years and add time for OS updates and replacement.
Ask for quotes in days broken down by test area and platform. That shows whether the vendor priced two platforms or one, and how much time it allowed for compatibility and retests.
What should you prepare on your side to avoid overpaying?
As with any testing service, the most expensive days are the ones testers spend waiting. Mobile testing has more sources of waiting than web testing, so preparation on your side has a direct effect on the bill.
Build distribution. Decide how testers receive new versions: TestFlight for iOS, an internal or closed testing track in Google Play, or another distribution tool. Testers must be added to test groups before the start, and builds should reach them automatically from CI.
Test accounts and data. User accounts in different roles and states (new user, user with history, blocked account), payment gateway test cards, data in the test environment. Without them half the journeys cannot be tested.
Back-end test environment. A mobile app is only as stable as the API it talks to. If the back-end test environment is unstable or frequently reset, testers will report defects that are not app defects.
A device matrix from analytics. Export data on your users’ models and OS versions. It shortens week one and protects you from testing on the wrong hardware.
Release criteria. When is a release ready? For example: no open critical or high defects, critical journeys pass on the whole matrix core, upgrading from the previous version loses no data. Without criteria, a test report cannot end with a recommendation.
A defect reporting process. A report template with device model, OS version, app version, steps and a screen recording, and an agreed owner on your side who receives reports and sets priorities.
What should you ask the vendor, and what goes into the contract?
Seven questions help separate a vendor that tests your app from a vendor that tests on its own phones.
How will you build the device matrix? A good answer starts with your analytics. A bad answer starts with the list of devices the vendor owns.
Which devices do you own physically, and which farm do you use? Ask for the list and for who pays for the farm.
How do you split manual and automated testing? Look for reasoning based on risk and release rhythm, not a claim that “we automate everything”.
What experience do you have with both platforms? Testing iOS and Android requires knowing their differences: permissions, background execution, notifications, publishing. Ask to speak to the person who will do the testing.
What do a defect report and a cycle report look like? Ask for an example. A defect report without device model, OS version and a recording is of little use to a developer.
How do you test security? If the app processes sensitive data, ask about alignment with OWASP MASVS and whether the test covers the API.
Who owns the test cases and automation scripts? The answer should be: you, in your repository and tools.
In the contract, set out the test areas in scope, the device matrix with a rule for updating it, the pricing model and how the farm is billed, release criteria, report format, artefact ownership with an explicit transfer or licence of rights to test cases and scripts (in Germany and Austria, an exclusive and unrestricted right of use, since copyright itself cannot be assigned), rules for access to builds and data, and a GDPR data processing agreement if testers will access personal data. For ongoing work, add specialist replacement terms and a notice period. For comparing pricing models in more depth, see How much does software testing outsourcing cost, and for a ready-made coverage list, the mobile app testing checklist for iOS and Android.
Which warning signs in a quote should make you stop?
Some quotes can be judged without a call, from a few signs in the text.
A device count without justification. “Testing on 50 devices” sounds impressive, but if nobody asked about your users, those 50 devices may not include the ones that matter.
No distinction between platforms. A quote that does not say whether it covers iOS, Android or both, and how much time goes to each, usually means one of them will be tested superficially.
Emulators only. A quote based solely on emulators and simulators is cheap, but it will not catch problems with performance, manufacturer skins and hardware.
Billing per reported defect. It rewards quantity, not severity. You will get lots of cosmetic reports and duplicates.
Automation without maintenance cost. A price for building automated tests with no word on maintaining them means you will pay again six months later.
No release criteria and no recommendation. A report that ends with a list of defects and no answer to “do we release?” leaves the decision to you without the information you need.
Scripts and test cases kept by the vendor. If artefacts stay in the vendor’s tools, you start from zero when you change vendor.
None of these signs automatically disqualifies a vendor, but each needs a question and a written answer before you sign.
What are the key takeaways?
Mobile app testing as a service means buying three things: tester work, device access and platform knowledge. Quotes differ in how much of each they include, so compare them only after you have set the scope, the device matrix and the manual-versus-automated split.
Remember six things. First, match the scope to the problem: regression and compatibility for failures after releases, security against OWASP MASVS for sensitive data, hardware tests for device integrations. Second, build the device matrix from user analytics in three layers: core, edge cases and wide pool. Third, combine a cloud device farm with a few physical phones; keep emulators for fast tests in CI. Fourth, automate stable critical journeys and test new features, usability and hardware manually. Fifth, the price is days times rate plus devices; a pre-launch test of an app on two platforms is an estimated 10–20 days. Sixth, set up build distribution, test accounts and release criteria before the start, because waiting testers are the most expensive line on the bill.
You will find more on testing in our Quality Assurance hub. If you are preparing an app launch or want to stop a slide in store ratings, see how we run mobile testing as part of our software testing services, and if you need ongoing support in your team, look at QA engineers through staff augmentation. You can also book a short scoping call: we will work out which test areas and which device matrix make sense for your app and what it will cost.