Test what your users actually use "It works on my machine" is still the most expensive sentence in software. But testing every browser on every device is not realistic either. The goal is to pick the smallest set that covers your real users and to know what usually breaks.
Start from your analytics, not from a list
Pull the last ninety days of sessions and sort by browser, operating system and screen width. In most projects, four or five combinations cover the large majority of traffic, plus one or two that matter because they belong to high-value customers. That is your required set. Everything else is best-effort.
What actually breaks between browsers
- Safari remains the most common source of real bugs: date inputs, video autoplay, storage limits in private mode, and scroll behaviour.
- Firefox tends to expose layout assumptions, especially with flexbox and grid gaps and with fonts.
- Older Edge and Chrome versions inside corporate networks often lack a JavaScript feature the build assumed was safe.
- In-app browsers in Instagram, Facebook and LinkedIn behave differently again, and a lot of paid traffic arrives through them.
What breaks between devices
Small screens expose overflow, tap targets that are too close together, sticky headers that cover the content they scroll to, and forms that get hidden by the on-screen keyboard. Large screens expose the opposite: layouts that stretch, images that pixelate, and a hero that pushes every call to action below the fold. Landscape on a phone is the size everybody forgets.
Emulators are for layout, real devices are for behaviour
A browser's device emulation is fine for catching layout and overflow problems and is cheap to run on every build. It will not tell you the truth about touch gestures, camera and file pickers, push notifications, real network conditions or Safari on iOS. Those need a real device, at least once per release.
A practical routine
- Automated layout checks at a fixed set of widths on every build, with screenshots compared against the last approved version.
- The critical journeys run automatically in Chromium, Firefox and WebKit.
- A manual pass on real iOS and Android devices before each release, focused on the flows that involve typing, uploading or paying.
Apex Automation Team runs this as part of software testing and QA, and reports every finding with the exact browser, version, device and viewport so it can be reproduced. Ask for a coverage matrix for your app.
Quick checklist
- Build the required browser list from your own analytics
- Always include Safari on iOS and one in-app browser
- Check phone landscape, not just portrait
- Use emulation for layout and real devices for behaviour
- Compare screenshots against the last approved version
- Record browser, version, device and viewport in every bug
Frequently asked
Do we need a device lab?
No. A small set of real devices for the release pass plus automated runs in Chromium, Firefox and WebKit covers almost everything that matters.
How many combinations do you normally test?
Typically four to six required combinations from your analytics, plus any that belong to important customers.