Cross-Device and Responsive Testing

A layout that looks perfect on a 1920×1080 desktop monitor can be completely broken on a 375px-wide mobile screen — overlapping elements, unreadable text, buttons so small they cannot be tapped, and content that scrolls sideways when it should not. Responsive testing verifies that the application adapts correctly as viewport size, device type, and interaction model change.

What responsive testing covers

Standard breakpoints and the gaps between them

Most design systems define breakpoints at round numbers — 480px, 768px, 1024px, 1280px. Bugs, however, do not respect round numbers. They appear at 540px, at 900px, at any width that sits between the breakpoints where the layout transitions were designed.

Common breakpoint conventions:

• Mobile: 320–480px (small phones: iPhone SE, older Android)
• Large mobile: 480–767px (modern phones in portrait)
• Tablet: 768–1023px (iPad, Android tablets in portrait)
• Tablet landscape / small desktop: 1024–1279px
• Desktop: 1280–1920px
• Wide / 4K: 1920px+

Testing strategy: always drag the viewport slowly through the full range, not just snap to breakpoint values. Layout breaks most often at the transition points — just before a breakpoint fires, when a component is at its narrowest before the layout switches.

What breaks in responsive contexts

Layout shifts and overlaps. Fixed-width elements that do not scale, absolutely positioned elements that escape their containers, and flex/grid configurations that do not handle narrow viewports gracefully all cause visible breakage at certain widths.

Hover-only interactions. Dropdown menus that only appear on hover, tooltips that only show on mouse-over, content that is accessible only via hover states — none of these work on touch devices. Every interaction that exists must be reachable by tap.

Form usability on small screens. Date pickers designed for mouse interaction are often nearly unusable on a touchscreen. Number inputs with increment/decrement arrows are too small to tap. Dropdowns with many options are frustrating to scroll through on a soft keyboard. Test every form element on mobile.

Soft keyboard behaviour. When the mobile keyboard appears, it reduces the visible viewport. Fixed-position footers, CTAs, or "sticky" elements can overlap the focused input field. On some devices, the keyboard pushes the content up; on others, it overlays it — both variants need testing.

Images and media. A hero image that loads as a 2MB full-width desktop image and scales down visually on mobile still downloads at full file size. Responsive images (srcset, picture element) should serve appropriately sized assets. Test with DevTools network throttling set to "Slow 3G" to make oversized assets obvious.

Touch targets. The minimum recommended touch target size is 44×44px (Apple HIG) or 48×48dp (Material Design). Smaller targets cause missed taps and user frustration — especially for users with motor impairments.

Testing approaches

Browser DevTools emulation is the fastest first pass. Chrome's device toolbar and Firefox's responsive design mode let you test any viewport size instantly. DevTools is accurate for layout and dimensions but does not replicate actual touch behaviour, device fonts, or hardware sensor interactions.

Real devices are the gold standard for anything touch-related, orientation-related, or involving native UI elements (date pickers, file upload sheets, camera). A small device lab — two iOS devices, two Android devices — covers the majority of mobile bugs that emulation misses.

Cloud device platforms (BrowserStack, Sauce Labs, LambdaTest) give access to a large catalogue of real devices without hardware cost. For organisations without a physical lab, these are the right solution for systematic mobile testing.

Automated responsive testing can be done in Playwright by setting viewport per test configuration. Snapshot or visual testing tools (Percy, Chromatic) can flag visual regressions across breakpoints automatically.

Mobile-specific considerations

Mobile is not just "a smaller desktop." The experience involves different input modalities and different contexts:

• Orientation: test portrait and landscape — some layouts that work in portrait collapse in landscape.
• Pinch and zoom: WCAG requires that zooming to 200% cannot be disabled by the page. Test that user-scalable=no is not set in the viewport meta tag.
• System font size: users can increase their device's font size in accessibility settings. This affects text-based layouts independently of browser zoom.
• Native browser UI: the browser's address bar, bottom tab bar, and safe area insets (iPhone notch, home indicator) reduce available screen space. CSS env(safe-area-inset-*) must be used to prevent content appearing behind device hardware elements.

⚠️ Common mistakes

• Only testing at exact breakpoint values. Snap to 320, 768, and 1280 and call it done — this misses the bugs at 540px, 900px, and every intermediate width. Always drag slowly through the full range.
• Treating DevTools emulation as a substitute for real device testing. It is not. Touch behaviour, native UI elements, orientation transitions, and hardware-triggered layout events (keyboard, notch) require a real device.
• Forgetting landscape orientation. Many testers test mobile in portrait only. A navigation bar that collapses cleanly in portrait may overlap content in landscape. Orientation matters especially for forms and media players.

🎯 Practice task

Run a structured responsive test on one page of a product you test — a landing page, a checkout, or a form-heavy screen.

1. Open the page in Chrome and activate DevTools device emulation. Slowly drag the viewport width from 1400px down to 320px. Note every point where the layout visibly breaks or changes.
2. Snap to mobile (375px) and attempt to complete the page's primary action (submit the form, complete the checkout) using only tap — do not use keyboard shortcuts or mouse.
3. If you have access to a real phone, repeat step 2 on the device. Note any differences from emulation.
4. File one bug report for the most significant issue you found, including a screenshot at the affected viewport width and the steps to reproduce.

The cross-browser and cross-device testing content in the Manual Software Testing course covers browser selection strategy, device lab setup, and cloud testing platform comparison in depth.