Responsive Design QA: Testing a Site Across Real Devices

Responsive design testing is the final check that a new site works on the phones, tablets and screens your customers actually use, not just on the designer's monitor. A sound process combines a written device matrix, checks at and between every breakpoint, Arabic right to left review, foldable and orientation tests, and a sign off record. This guide sets out that process for the last weeks of a build.

Why browser resizing is not enough for responsive design testing

Dragging a desktop browser window narrower catches obvious layout breaks, but it misses a lot. Real phones have touch input, on screen keyboards, notches, browser toolbars that appear and disappear, different font rendering and their own quirks in Safari, Chrome and Samsung Internet.

Emulators help. Chrome's own documentation describes DevTools device mode as a first order approximation of the mobile experience, and recommends running the page on an actual device through remote debugging when in doubt. See Chrome DevTools device mode. Use emulation for speed during the build, then confirm on hardware before launch.

Step 1: build a device matrix from real data

Cross device testing starts with a short list of the devices and browsers that matter. Pull the last few months of analytics and group sessions by device category, operating system, browser and screen width. If the site is new, use data from the old site or from similar sites the business runs.

A practical device matrix

Keep the matrix to a size the team will actually complete. A smaller list tested properly is more useful than a long list nobody finishes.

Step 2: test at and between responsive breakpoints

Responsive breakpoints are the widths where the layout changes. Bugs cluster at the breakpoint itself and in the awkward space just before the next one.

The breakpoint sweep

1. Open each page template in a desktop browser with responsive mode on.
2. Start at the narrowest supported width and widen slowly to the largest.
3. Pause one step either side of every breakpoint.
4. Note overflow, overlapping elements, orphaned buttons, cramped cards and lines of text that become too long to read comfortably.
5. Repeat with the browser zoomed in, since many visitors enlarge text.

What to look at on each template

• Header and navigation, including the menu open state.
• Hero sections, especially text placed over images.
• Tables, which should scroll inside their container or reflow, never push the whole page sideways.
• Forms, including error messages and success states.
• Sliders, tabs and accordions.
• Footer, cookie banner and any sticky bars together, since they often collide.

Step 3: the browser testing checklist on real phones

This is the core of the QA pass. Run it on every Tier 1 device and the key tasks on Tier 2.

Layout and content

• No horizontal scrolling on any page.
• Images are sharp, correctly cropped and not stretched.
• Text is readable without pinching.
• Nothing important is hidden behind the notch, the home indicator or browser toolbars.
• Content does not jump as images, fonts or banners load.

Touch and interaction

• Buttons and links are easy to tap without hitting a neighbour. WCAG 2.2 sets a Level AA minimum target of 24 by 24 CSS pixels, with exceptions; primary actions should be larger. See the W3C note on target size.
• Menus open and close reliably, and close after a link is chosen.
• Hover only effects have a touch alternative.
• Phone, WhatsApp, email and map links open the right app.

Forms and keyboards

• The correct keyboard appears for phone, email and number fields.
• The page does not zoom unexpectedly when a field is focused.
• The on screen keyboard does not cover the field being typed in or the submit button.
• Autofill works for name, email and phone.
• Submissions arrive in the inbox or CRM, with the right source details.

Orientation

Rotate each Tier 1 phone sideways on the home page, a long content page and the main form. Sticky headers and bottom bars can take up most of a short, wide screen, so check that real content remains visible.

Step 4: RTL layout testing for Arabic pages

Arabic pages need their own pass. A site can look perfect in English and still break in Arabic, because the layout must mirror and Arabic text has different lengths and line heights.

RTL checks

• The page sets right to left direction and Arabic language correctly, so text, alignment and punctuation behave.
• Navigation, breadcrumbs and step indicators read from right to left.
• Arrows and icons that imply direction, such as next, back and carousel controls, are mirrored. Icons that do not imply direction, such as a phone or search icon, stay as they are.
• Spacing and borders sit on the correct side. MDN explains that CSS logical properties describe layout in terms of start and end, so it adapts to writing direction; see CSS logical properties. Code that uses fixed left and right values is a common cause of RTL bugs.
• Mixed content, such as English brand names, phone numbers and prices inside Arabic sentences, displays in a sensible order.
• Forms accept Arabic input and show Arabic error messages.
• The language switcher leads to the equivalent page, not the home page.

Typography in Arabic

Arabic fonts often need more line height than Latin fonts at the same size. Check that headings do not clip, that buttons with longer Arabic labels still fit, and that the Arabic font loads on all Tier 1 devices rather than falling back to a system font.

Step 5: foldable phone layouts and unusual screens

Foldable phones change width when opened and closed, sometimes while a page is in use. The minimum check is that the page reflows cleanly in both states without losing scroll position or form input.

Chrome DevTools includes dual screen and foldable posture settings for emulation. Browsers are also developing a Viewport Segments API that lets a page detect a fold or hinge, but MDN marks it as experimental and not yet supported in major browsers, so most business sites should simply make sure the layout works on any width, folded or open.

Other screens worth a glance

• Very large monitors, where content should stop stretching at a sensible maximum width.
• Tablets in both orientations, which often fall between phone and desktop layouts.
• Small older phones, which reveal crowding first.

Step 6: log, fix and retest

Every issue needs enough detail for a developer to reproduce it. A consistent bug format saves time.

Group severity into three levels: blocks launch, fix before launch if possible, and fix after launch. Anything that stops a visitor buying, calling or submitting a form belongs in the first group.

Hypothetical example: a late catch

Hypothetical example: a retailer in Sharjah is days from launching a new online store. Desktop and iPhone tests pass. On a mid range Android phone, the sticky "Add to basket" bar overlaps the cookie banner, and on the Arabic checkout page the delivery address fields appear in the wrong order. Both issues are logged as launch blockers, fixed and retested on the same devices before sign off.

Sign off before launch

Responsive design testing ends with a written record, not a verbal "looks fine". The sign off should list:

• The device matrix used and who tested each device.
• Templates and key tasks covered, in both languages.
• All launch blocking issues closed and retested.
• Known minor issues, with an owner and a date for fixing.
• A post launch check plan for the first week, including form submissions and analytics.

If you are earlier in the project, the guide to mobile first or responsive design covers decisions that make QA easier. When choosing a partner, the guide to shortlisting web design companies suggests asking how they test. The trade offs in template or custom design also affect how much QA a build needs, and user research shows which tasks deserve the most testing.

Launch with a tested build from Codeeo

Codeeo's team of 80+ across Dubai, Riyadh and Karachi builds and tests sites across real devices and both languages as part of website design and development. If you already have a site, a website audit can surface responsive and RTL issues, and Core Web Vitals work addresses speed on phones. Contact Codeeo to plan your QA or review a site before launch.