Cross-device testing
Cross-device testing is checking that a website or application works correctly on the range of physical devices its users hold: phones, tablets, laptops and desktops of different screen sizes, pixel densities, input methods and performance. It differs from cross-browser testing, which varies the rendering engine; cross-device testing varies the hardware and the way a person touches it.
The longer version
A device changes four things a page has to cope with. Viewport width decides which layout breakpoint applies and whether the navigation collapses. Pixel density decides whether images and text render sharp or blurred. Input decides whether hover states exist at all and how large a tap target has to be. Performance and memory decide whether an animation stutters or a large page gets killed by the operating system. A page can pass on every browser on a developer's laptop and fail on all four counts on a mid-range phone.
Cross-browser testing holds the device steady and swaps the rendering engine to catch CSS and JavaScript differences between engines. Cross-device testing holds the engine steady where it can and swaps the hardware. The two overlap, since a phone brings its own browser, and search results tend to blend them, but the bugs are different. An unsupported CSS property is a browser bug. A menu that opens on hover and cannot be opened by touch is a device bug and reproduces in every browser on that phone.
The report leaves out the property that mattered. A tester writes that the checkout button is cut off, the developer opens the page on a desktop at full width, and nothing is wrong. Without the viewport size, the screen size, the device and the browser in the report, the first round trip is spent establishing which of the four properties was different. Emulators reproduce the viewport and density and simulate touch with a mouse, but not the phone's performance, memory or on-screen keyboard, so at least the most common real devices have to be in someone's hand.
Teams choose the set from analytics rather than from what the office owns: the handful of device classes that carry most sessions, plus the smallest viewport and the slowest device the product still claims to support. That list is the device axis of the test matrix, and it is revisited when the traffic changes rather than when a new phone launches.
Common questions
What is the difference between cross-device and cross-browser testing?
Cross-browser testing varies the rendering engine on one machine to find CSS and JavaScript that behave differently between engines. Cross-device testing varies the hardware: screen size, pixel density, touch versus mouse, and performance. A hover menu that cannot be opened by touch is a device bug and shows up in every browser on that phone.
Which devices should you test on?
The device classes that carry most of the product's real sessions, taken from analytics, plus the narrowest viewport and the slowest device the product still supports. That set is short enough to keep in hand and covers the layouts and input methods most users meet; emulators fill in the long tail.
Can emulators replace real devices for cross-device testing?
Emulators reproduce viewport and pixel density well and are the right tool for checking breakpoints quickly. They simulate touch with a mouse and do not reproduce real network conditions, memory limits or the way a phone's browser handles its on-screen keyboard, so the most common real devices still need to be tested physically.
When should cross-device testing be done?
Whenever a change touches layout, navigation, forms or anything a finger interacts with, and again as a pass before release on the devices in the supported set. Running it only at the end of a release means a breakpoint bug introduced in the first week is found in the last, when the fix competes with everything else waiting to ship.
Can cross-device testing be automated?
Part of it. Automated suites run the same tests at several viewport widths in a headless browser and catch layout and breakpoint regressions on every build. Touch interaction, on-screen keyboards, memory limits and the performance of a budget phone are not reproduced by a headless run, so those checks stay manual or run on a farm of real devices.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.