BrowserStack device and browser coverage
BrowserStack is not a test framework, and buying it does not make your tests good. It answers one question: which real browsers and devices your existing suite gets to run on. That is a recurring bill, so three things decide it. What your visitors actually use. How many sessions you will pay to run at once. And what you are willing to leave uncovered.
01Capabilities
Coverage you can point at real traffic
A device cloud is infrastructure, so the engineering is in what you point at it and how often. We treat it as one input to a test automation strategy rather than as the strategy, and the framework stays your choice: Selenium, TestCafe or anything else that talks to a remote browser. Our QA engineers are ISTQB certified and sit in every sprint.
- Matrix
A target list built from your own analytics
Browser and operating-system share in your own traffic decides what gets checked on every change, what runs overnight, and what is honestly not worth testing. Most matrices we inherit were copied from a blog post and nobody has revisited them since.
- Concurrency
How many run at once, and what that costs
Remote sessions, splitting the suite and sensible retries wired in so a full run finishes inside a duration your team tolerates. How many sessions run at once is the real cost lever, which makes this a planning decision as much as a pipeline one.
- Long tail
Consumer flows where an old browser costs revenue
Checkout, booking and signup journeys of the kind behind our e-commerce work, where a layout break on one older phone browser is money not taken rather than a cosmetic complaint.
- Repro
The bug report you cannot reproduce
A live session on the exact device and version from the support ticket, then a pinned test so it cannot come back quietly. This is often the highest-value use of a device cloud, and it belongs inside full-cycle testing and QA.
02Fit
A recurring bill, priced as a coverage decision
A device cloud is easy to buy and easy to over-buy, because the pitch is coverage and the invoice is a subscription. The question is not whether real devices beat emulators, they do. It is whether device coverage is the thing standing between you and confidence in a release. Each of the six rows below puts the budget where it does the most good, from a device cloud to a headless browser or a stabilised suite.
| Your situation | What we recommend |
|---|---|
| A consumer product, a wide spread of devices in your traffic, and no hardware lab | Use a device cloudBuying, charging and updating a shelf of phones costs more than it looks, and nobody ever owns the right ones by the time they are needed. |
| A defect that only reproduces on one device and one operating-system version | A live session, todayGuessing at this from a screenshot is how a week disappears. One session on the right device usually ends the argument before lunch. |
| An internal tool used on issued laptops with one managed browser | A headless browserA headless browser in your pipeline, or a containerized Docker grid, covers you for close to nothing per month. |
| Your suite is unreliable and the plan is to run it on more targets | Stabilise the suiteThe answer here is fewer tests, not more targets. Unreliable tests on a wider matrix produce wider unreliable results and a much larger bill. |
| Deep hardware behaviour: peripherals, camera pipelines, background location | Physical devicesSome of this cannot be exercised over a network, and a small shelf of physical devices earns its keep. See iOS and Android. |
| Residency rules, or a system unreachable from outside your own network | Read the terms firstCheck the tunnelling and residency conditions before committing to an annual plan. Where they do not fit, a self-hosted grid is the boring correct answer. |
Scope
We own the matrix and its cost. Which targets earn a place, what triggers a run against them, and a written record of what is not covered so nobody assumes it is. Our QA engineers are ISTQB certified and sit in every sprint. unicrew has built and tested software since 2012. We have 100+ senior in-house engineers across six countries. We work under an ISO 27001:2022 certified information-security management system. Where the suite is a better investment than the subscription, that is the plan you get before you sign anything.
03Delivery
Sizing a matrix from analytics and a budget
Coverage here is a budgeting exercise as much as a technical one, and this is the order that keeps both honest.
- Start from your analytics, not the device listPull the real browser, operating-system and screen-size spread for your own traffic, then cut it at a threshold you can defend to somebody who asks. A matrix that covers everything is a matrix nobody maintains once the first invoice arrives.
- Set the concurrency budget before the matrixHow many sessions run at once, rather than how many tests exist, determines both wall-clock time and cost. Deciding that number early makes every later scoping question answerable instead of open-ended.
- Split the matrix by triggerA short run on two or three targets for every change, the full matrix overnight or before a release. Putting everything on every push is how teams end up switching the whole thing off during a busy week and never switching it back on.
- Write down what is not coveredThe uncovered targets, the journeys that stay manual, and the hardware behaviour no cloud can exercise, all recorded where somebody will find them. Unstated gaps get read as coverage, and that assumption is what becomes a production incident.
04Stack
What runs against the devices
The four neighbours of a coverage decision, each with its own page if that is the call you are really making.
05Questions
Questions before signing an annual plan
The six that come up while somebody is still deciding how much coverage to buy. If yours is not here, it is a good first message.
Yes, as part of our QA engineers' toolkit rather than a specialty of its own. Our engineers own the coverage decision as well as the tests, because that decision is what you are really paying for and it has a recurring cost attached. The matrix and the suite design get reviewed by an engineer outside the delivery team. Team extension is managed teams; the outcome is QA and test automation.
A self-hosted Selenium grid in containers is cheaper and perfectly adequate when you need a handful of desktop browser versions and nothing else. A device cloud earns its money on two things a grid cannot give you: real phone hardware, and old operating-system versions you would otherwise buy and maintain. Plenty of teams run both, the grid for quick checks and the cloud for breadth before a release.
No, and it can make the symptom worse. Remote sessions add network latency and startup variance, so tests that were marginally unstable locally fail more often against a cloud. The causes are still waiting on durations instead of conditions, brittle selectors and shared test data. Fix those, then add targets, otherwise you are paying by the minute to generate noise nobody reads.
Yes. A build can be uploaded and driven on real devices, which covers most of what a mobile regression suite needs. The exceptions are worth knowing early: peripherals, camera pipelines, background location, and anything depending on a specific carrier or sensor. For those we keep a small set of physical devices in the loop, and the trade-offs sit on our iOS and Android page.
A scoping call with a QA engineer. Two things make it useful: your browser and device analytics, and whatever the suite covers today. What comes back is a proposed matrix, a concurrency figure, and a plain statement of what stays uncovered and why. The cloud subscription remains your own commercial arrangement. Most engagements start within two to four weeks.
Three shapes, and which one fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based, and we offer it once the first read is done, because a fixed number on a suite nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer.
Paying for devices your visitors do not use?
Send us your traffic breakdown and what the suite covers today. You get a matrix proposal with the reasoning attached, and the cheapest setup that covers your traffic, from a local grid to a device cloud.