Home/ Grad/ Learning
Grad Level · Learn by Doing

Mobile & Responsive Testing

One in three NZ users browse on mobile. Test across devices, screen sizes, orientations, and touch interactions to ensure your app works for everyone.

Grad ~8 min read

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?

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.

Self-Check

  1. 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.
  2. What is the minimum touch target size?
    44×44 CSS pixels (WCAG). Smaller targets cause tapping errors, especially for users with motor control issues.
  3. 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.
  4. 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.
  5. 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.