Mobile & Responsive Testing

The Hook — Mobile Failure in Production

A Wellington e-commerce site passed QA on desktop. It shipped. Within hours, a tester tried booking on their iPhone and the checkout button was hidden behind a chat widget. Payment failed silently. Another user on Android couldn't tap the "Add to cart" button because it was 32×32 pixels — below the recommended 44×44 touch target. The site worked perfectly on desktop and failed for half its users.

Desktop testing alone is insufficient. Mobile is not "desktop, smaller." It is a different interaction model (touch vs click), different networks (4G vs wifi), different contexts (quick scan vs focused work), and different breakpoints (viewport 375px vs 1920px).

The Rule

Responsive testing verifies that layout, interaction, and content adapt correctly to different screen sizes, orientations, and input methods. It covers:

Layout reflow: Does the layout stack, resize, or hide elements cleanly at each breakpoint?
Touch targets: Are buttons and links at least 44×44 CSS pixels (WCAG recommendation)?
Orientation: Can users rotate between portrait and landscape without losing state or crashing?
Mobile-specific UX: Hamburger menus, modals, bottom sheets, swipe gestures.
Network variance: Does the app load and function on 4G, wifi, and poor connections?

Senior engineer insight

The moment that changed how I think about mobile testing: watching a real user try to book something on TradeMe on a Pixel 6 with one hand, thumb-stretching to reach a "Confirm" button at the top of the screen. Everything about our viewport tests had been desktop-brained — we measured width, not reachability. Thumb zone is the design constraint mobile testing should start from, not end at. Once you internalise that the bottom third of a phone screen is prime real estate and the top corners are dead zones, you start catching layout bugs before they even hit the test environment.

Most common mistake: treating mobile testing as "run the same test cases but at 375px" — it is a fundamentally different interaction model, and your test cases need to reflect that.

From the field

On a NZ government services project, the team assumed that because the site passed automated accessibility scans and Chrome DevTools mobile emulation, it was mobile-ready. When we ran exploratory sessions on a mix of real devices — including an older Samsung Galaxy A series running Android 11 — we discovered the date-picker polyfill was completely non-functional on Chrome for Android: the native date picker never appeared, the custom widget didn't render, and users were left with a plain text input expecting a format that wasn't shown anywhere on screen. DevTools emulation had shown it working perfectly. The fix was straightforward once found, but it had been in production for three months before a real device caught it. From that project on, we added a "real device smoke test" gate before every release — five minutes on each of iOS Safari and Android Chrome on a physical handset, not a simulator.

Watch Me Do It

Scenario: You are testing a NZ insurance quote form on mobile. The form works on desktop but you suspect mobile issues.

Test Plan: Insurance Quote Form

Device	Test	Expected	Result
iPhone SE (375px)	Load form, scroll to submit	All fields visible without horizontal scroll; submit button visible without scrolling past the fold	✓ Pass
iPhone 15 (393px)	Tap on "Date of birth" field	Native date picker appears; keyboard does not hide the field	✓ Pass
Pixel 8 (412px)	Rotate to landscape	Layout adapts; fields remain accessible; no state is lost	✓ Pass
iPhone 15 (3G)	Load form on slow network	Form renders progressively; user can start typing while images load	✗ Fail — Text fields not interactive until all images loaded

Mobile & Responsive Checklist

Device coverage (minimum):

iPhone 12 mini (375px) — smallest recent iPhone
iPhone 15 Pro (393px) — current flagship
Pixel 8 (412px) — current Android flagship
iPad Air (820px) — tablet
Desktop (1440px+) — sanity check

Layout & content:

☐ Text does not overflow container or require horizontal scroll
☐ Images scale proportionally and do not distort
☐ Navigation is accessible (hamburger menu, bottom nav, or visible on small screens)
☐ Form labels are visible above inputs (not as placeholders only)
☐ No content is hidden or unreachable at any breakpoint

Touch & interaction:

☐ Buttons and links are at least 44×44 CSS pixels (WCAG standard)
☐ No hover-only interactions (buttons without visible focus states)
☐ Dropdowns, modals, and menus are touchable and dismissible
☐ Form fields don't jump or scroll unexpectedly when focused (keyboard does not hide field)
☐ Swipe gestures (if present) have obvious visual affordances

Orientation:

☐ Rotating device does not crash or lose form state
☐ Layout reflows appropriately in both portrait and landscape
☐ Orientation lock (if intentional) is documented

Network & performance:

☐ App loads and is usable on 4G (use DevTools throttling)
☐ Images load progressively; form is usable while images load
☐ No large uncompressed assets block interaction

Common Mistakes

❌ Testing Only on Desktop in a Mobile Browser

Resizing a desktop browser to 375px does not simulate mobile. Desktop browsers have different memory, rendering, network, and input handling than real devices. Always test on actual devices or a device emulator (DevTools, BrowserStack, Appetize).

❌ Assuming Tablet Layout Works for Mobile

A tablet (800px+) layout is often a scaled-down desktop. Mobile (< 600px) requires a different approach: single-column layout, touch-friendly targets, simpler navigation. Test each breakpoint independently.

❌ Not Testing Network Variance

Your test device on Wifi loads instantly. Real users on 4G in rural areas wait 5+ seconds. Use DevTools Network Throttling (Fast 3G, Slow 3G) or test on a real 4G connection. Missing this causes "works on my machine" failures.

❌ Testing Only Orientation You Care About

Users rotate devices mid-task. If your app locks orientation (e.g., portrait only for a game), verify state is preserved if they force rotate. If it's responsive, rotate frequently and check for layout reflow bugs.

Why teams fail here

Over-reliance on Chrome DevTools emulation — it does not replicate Safari rendering, WebKit quirks, or iOS virtual keyboard behaviour, which is where a disproportionate number of mobile bugs live
Testing only the newest flagship devices — a huge portion of NZ mobile traffic still comes from mid-range Android handsets and older iPhones (SE, iPhone 11) where performance and CSS support differs materially
Skipping orientation mid-flow — teams test portrait on load then sign off, but users rotate during long forms or video; the state-loss and layout-break bugs only appear when you rotate at step 3 of 4, not at the start
No test coverage for the virtual keyboard — on mobile, the soft keyboard reduces the visible viewport by 30–50%; fixed footers, floating CTAs, and sticky elements can obscure form fields or become untappable when the keyboard is open

Key takeaway

Mobile testing is not desktop testing with a smaller screen — it is a different device class, a different input model, and a different user context, and your test coverage needs to be designed for it from the ground up.

Interview Questions

What NZ hiring managers ask about Mobile & Responsive Testing at the Grad level.

Q1. What is responsive design, and what are the key things you test for it?

Strong answer: Responsive design means the layout adapts to different screen sizes and orientations using CSS media queries. Key test points: layout at common breakpoints (320px, 375px, 768px, 1024px, 1440px), text readability (not too small, not overflowing containers), tap target sizes (minimum 44x44px for buttons), images scaling correctly without distortion or overflow, forms usable with virtual keyboard (input fields not hidden behind keyboard), and horizontal scrolling (should not appear on mobile widths).

Q2. Why is it important to test on real devices, not just browser DevTools device emulation?

Strong answer: DevTools emulation simulates screen size and basic touch events but cannot replicate actual hardware performance (slower CPU/GPU), real network conditions, operating system rendering differences (iOS Safari vs Chrome on Android), device-specific browser quirks (Safari on iOS implements some CSS differently), physical touch interaction accuracy, or hardware-specific issues like notch/cutout interference. For a NZ government site subject to accessibility requirements, I test on at least one real iOS device and one real Android device.

Q3. What should you do if a feature works on desktop but not on mobile?

Strong answer: First reproduce it consistently on mobile to confirm it is not intermittent. Note the exact device, OS version, browser version, and orientation. Check whether it fails on all mobile browsers or only Safari/Chrome. Check DevTools for mobile-specific CSS media query issues or JavaScript errors. Report as a mobile-specific bug with device details and screenshots/recording. Mark severity based on the percentage of mobile users (check analytics) who would hit this — a broken checkout on mobile is critical if 60% of users are on mobile.

Self-Check

Why is testing on a real device better than resizing a desktop browser?
Real devices have different rendering engines, memory constraints, and network conditions. Desktop browser resizing does not simulate these.
What is the minimum touch target size?
44×44 CSS pixels (WCAG). Smaller targets cause tapping errors, especially for users with motor control issues.
Your form works on iPad but breaks on iPhone. Why?
Breakpoints. iPad at 820px may use a 2-column layout; iPhone at 375px needs 1-column. CSS media queries may not account for all sizes.
A user says "the app won't load on 4G." You tested on Wifi and it works. What's the issue?
You didn't test network variance. Use DevTools Throttling (Fast 3G) or test on a real 4G connection. Assets may be too large or render-blocking.
Scenario: A modal appears on desktop with close button in top-right corner. On mobile, the button is off-screen. Fix?
Test orientation and ensure the close button is always visible, or provide a swipe-to-dismiss gesture that works on mobile.