Mobile Website QA Checklist: Test the Experience Real Customers Get

Choose representative mobile environments#

Build a small matrix from actual product traffic and risk: iOS Safari, Android Chrome, key embedded browsers, older supported operating systems, and at least one smaller or slower device. Device emulation is fast for layout checks, but real hardware is necessary for keyboards, touch, browser UI, media, permissions, and performance behavior.

Record screen size, pixel density when relevant, OS, browser version, orientation, connection, account state, and whether the app is standalone or inside another app. This makes a finding reproducible and prevents “mobile” from becoming an undefined environment.

Test layout with real content extremes#

Check narrow widths, landscape, browser zoom, dynamic text size, long names, long translated copy, empty states, large result sets, and error messages. Content should reflow without horizontal scrolling except where a data surface intentionally requires it.

Watch fixed headers, cookie banners, chat widgets, bottom navigation, and sticky CTAs. They must not cover form controls, validation, or browser controls. Rotate during a task and verify the page preserves input, scroll context, and the currently open surface.

• No clipped text, controls, dialogs, or off-screen actions
• Images and video keep useful crops and intrinsic space
• Safe areas and browser bars do not hide fixed controls
• Loading skeletons and late content do not cause destructive shifts

Exercise touch, focus, and the virtual keyboard#

Tap every interactive element near edges and adjacent controls. Verify that labels activate their fields, gestures have visible alternatives, drag interactions are not the only path, and hover-only information is available through focus or tap. WCAG 2.2 includes criteria relevant to target size and dragging movements.

Complete every form with the virtual keyboard. Check input types, autofill, password managers, one-time codes, next/submit actions, keyboard dismissal, scrolling to errors, and whether the keyboard covers the active field or CTA. Confirm that focus returns sensibly after dialogs and route changes.

Test interruptions and constrained networks#

Mobile journeys are interrupted. Send the app to the background, lock and unlock the device, switch networks, deny a permission, open an external payment or authentication page, and return through the documented path. The product should preserve safe progress and explain any expired state.

Run the journey on a slower or unstable connection. Prevent duplicate submissions, retain entered data when a retry is safe, and communicate whether an action completed. A spinner that disappears into a timeout is not a recovery experience.

Check accessibility and platform conventions#

Use the platform screen reader for the critical path, review focus order and announcements, and test increased text size and reduced motion. Native browser behaviors such as link context menus, back navigation, form controls, and autofill should work unless the product has a justified alternative.

Document failures with a device recording when touch position, keyboard, rotation, or browser chrome matters. Include the orientation and input state in the report; a desktop screenshot cannot preserve those conditions.

Is responsive mode enough for mobile QA?#

No. It is useful for fast layout checks, but real devices are needed for touch, keyboards, browser UI, media, permissions, interruptions, and realistic performance.

Which mobile browsers should be tested?#

Use product analytics and support policy to define the matrix. At minimum, cover the dominant iOS and Android browser engines for the audience and any embedded browser that carries meaningful traffic.

What is the highest-value mobile test?#

Complete the primary conversion or first-value journey on the riskiest supported real device, including keyboard input, a failure-and-retry state, and return from any third-party handoff.