← back to the section

Different people open the same site in different ways: one on Chrome on a big monitor, another on Safari on an iPhone, another in an older browser on a budget Android. And it may look different for all of them: somewhere a button is in the right place, somewhere it's slid off the edge, somewhere text has overlapped an image. Verifying that a product works properly everywhere — that's cross-browser and mobile testing.

Checking every possible combination of browsers and devices is impossible — there are infinitely many. That's why it's especially important to choose a sensible test set rather than trying to cover everything.

the same page at three screen widths desktop · 1280 pxCatalog Orders Profiletable 720 pxthree columns, all fits tablet · 900 pxCatalog Orderstable 720 pxtable barely fits breakpoint 768 pxphone · 390 px tableedge runs off screen below 768 px the columns collapsed into one — the table stayed 720 pxits edge runs off screen: horizontal scrolling on the phone

The same page at three widths. The layout does not change smoothly — it switches at a set width: below 768 pixels the three columns collapse into one and the menu moves into a "hamburger". Only what can reflow does: a table with a hard width of 720 pixels stays as it is and runs past the right edge. That is where horizontal scrolling on a phone comes from — the first thing to look for when checking responsiveness.

Why a site looks different

Causes of different behavior:

  • Different browsers (Chrome, Safari, Firefox, Edge) render pages slightly differently and support different features. Something that looks perfect in Chrome may break in Safari.
  • Different screen sizes. A large monitor, a laptop, a tablet, a phone — all have different widths, and the layout adapts to them. It does not adapt smoothly: it switches at set widths (often 768 and 1200 pixels), so it is worth looking at both sides of such a border — these are the same boundary values.
  • Different devices and operating systems. iPhone and Android don't behave the same way: the keyboard, gestures, fonts, and field behavior all differ.

A site's ability to adapt to the screen size is called responsiveness (or adaptivity), and checking it is a big part of mobile testing.

What to check

A checklist for different browsers and screen sizes:

  • The layout doesn't break. Nothing overlaps, nothing is cut off, nothing goes past the edge, no horizontal scrollbar on a phone.
  • Everything is accessible and tappable. Buttons and links aren't too small for a finger (the usual reference is a side of about 44 points), nothing is obscured.
  • Features work. Forms submit, menus open, payments go through — not just "looks nice," but "actually works."
  • Phone-specific things: is it comfortable to type with the on-screen keyboard, do gestures (swipes) work, does it behave correctly when rotating the screen.

Phones also have slow internet all the time: it is worth seeing whether the product breaks while everything is loading, and whether it shows a loading state.

How to test: emulators and real devices

The approaches complement each other rather than replace one another.

  • Browser emulation. DevTools has a mode that shows the page as it would look on a phone of a chosen size. It's fast and free, and it's great for checking layout responsiveness. But it's only an imitation of screen size — it doesn't reproduce actual iPhone or Android behavior.
  • Real devices. Testing on a real phone is the most honest check: a real keyboard, real Safari, real gestures. Ideal, but keeping a dozen devices on hand isn't realistic.
  • Cloud device farms. Services (search for "device farm") where you connect remotely to hundreds of real browsers and devices for a fee. Knowing they exist is enough.

A sensible order: catch responsiveness and obvious problems with DevTools emulation; re-verify key scenarios on a couple of real devices (usually one iPhone and one Android).

How to choose a test set

The set is chosen based on what your actual audience uses. Usually the team has analytics: which browsers and devices the users have. From those, you take the most popular ones plus a couple of "problematic" ones (for example, Safari on iPhone is a frequent source of quirks). This is where pairwise testing helps: not all combinations, but a covering minimum.

Where this applies

Important scenarios are run on at least a few browsers and on a phone: automated tests usually run in a single browser, so this part of the work stays with manual checking.

Where beginners stumble:

  • Only testing in their own browser on their own laptop and assuming it "works." For a user on a phone it may be different.
  • Trusting the emulator like a real device. The phone mode in DevTools simulates screen size, but not real behavior — key scenarios are worth re-checking on an actual device.
  • Trying to cover everything and drowning. Pick a set based on your real audience, not "all browsers in the world."

In short

  • The difference comes from three places: the browser renders its own way, the screen is a different width, the phone's system behaves differently.
  • The layout switches at set widths: you look at both sides of the border, not only at 1280 and 390.
  • Horizontal scrolling on a phone is a sign of a block that cannot shrink: a table or an image.
  • DevTools emulation is honest only about screen size: it does not reproduce the keyboard, gestures, or real Safari.
  • The set comes from audience analytics plus a couple of "problematic" devices, and the combinations are cut down by pairwise selection.