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. Let's look at why differences occur and how to check for them.
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 needs to adapt to each.
- 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). On a wide screen — three columns; on a phone — one, with the menu hidden behind a "hamburger" icon. Checking responsiveness is a big part of mobile testing.
What to check
A typical 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, 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.
Keep in mind: phones often have slow internet. It's worth checking how the product behaves when everything loads slowly — does it break, does it show a loading indicator.
How to test: emulators and real devices
There are two approaches, and they complement each other.
- 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. There are services (search for "device farm" or "cross browser testing") where you can connect remotely to hundreds of real browsers and devices for a fee. For now, knowing they exist is enough.
A sensible beginner's approach: 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
Testing every browser and phone isn't realistic. 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 a case where pairwise testing helps: not all combinations, but a covering minimum.
Where this applies
Cross-browser and mobile testing is needed on almost any product with a web interface: something polished on your laptop in Chrome may look broken for a user on an iPhone. That's why important scenarios are always run on at least a few browsers and on a phone. This is a noticeable and valued part of a manual tester's work — something that automated tests and developers often miss.
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."
What to learn next. Tools and practice covered. Next — how all of this fits into team work: QA in Agile and Scrum.