Responsive layouts, screen sizes and rendering

A web app's window can be almost any size — a wide desktop monitor, a laptop, a tablet held either way, a phone browser, a window dragged to half-width, the page zoomed to 150%. The layout must cope with all of it, and responsive design is how a web app adapts. Testing that it adapts correctly — that nothing breaks, overlaps, clips or becomes unusable at any size — is a core web-QA concern. This lesson is responsive and rendering testing.

Responsive design, and why it needs testing

Responsive design means the layout adapts to the available width — columns stack on a narrow screen, a navigation menu collapses into a "hamburger", text reflows, tables scroll or reformat. It works via CSS breakpoints (rules that apply at certain widths). Because the developer usually builds and views at one size (their monitor), the other sizes are under-tested, and that is where responsive bugs live:

• Layout breaks at some widths — elements overlap, overflow off the screen, clip, or bunch up between breakpoints (the "in-between" widths the developer did not check).
• Content becomes unreachable — a button pushed off-screen, a table whose right columns are cut off with no scroll, a menu that does not open on a narrow screen.
• Text and touch targets — text too small to read, or buttons too small/close to tap on a narrow (touch) layout.
• The hamburger / collapsed nav — the menu that appears only on narrow screens (so the desktop-testing developer never opens it) is frequently broken.

Responsive bugs are common precisely because there are many widths and the developer checks one. The QA tests the app across the range of sizes real users have.

What sizes to test

You test a representative range of widths, driven by what your users use:

• Desktop — a typical wide monitor and a smaller laptop; and the app in a non-maximised window (users drag windows to half-width — a common break).
• Tablet — around tablet width, both orientations.
• Mobile browser — narrow phone widths (many users open web apps on their phone browser, separate from a native app).
• The breakpoints and just around them — the widths where the layout switches (columns stack, the menu collapses) are where bugs cluster, exactly like boundary values (the test-design lesson): test at each breakpoint and just either side.
• Zoom — some users run the browser zoomed (100%, 125%, 150%) for readability; check the layout survives zoom, which effectively changes the layout width.

As with browsers and devices, use analytics for the real distribution, but always cover the extremes (very narrow, very wide) and the breakpoints — those are where responsive layouts break.

How to test responsive layouts

The browser's dev tools make this efficient (the testing-web-apps lesson's toolkit):

• Responsive/device mode in dev tools — every browser's dev tools (Chrome's device toolbar, etc.) let you set an exact width, pick common device presets, and drag to resize continuously. Dragging the width slowly from wide to narrow is the single best responsive test — you watch the layout reflow and catch exactly the width where it breaks.
• Resize the real browser window — drag the actual window from full to half to narrow; catches things device-mode presets miss.
• Test at the breakpoints — set the width to each breakpoint and one either side.
• Zoom — Ctrl/Cmd-+ to 125% and 150% and check the layout holds.
• Real devices — a real phone browser and tablet for the true rendering (device mode approximates, but real is real — the fonts, the touch, the actual browser).

The drag-to-resize technique is worth emphasising: slowly narrowing the window and watching for the moment something overlaps, overflows, or disappears finds responsive bugs faster than checking a few fixed sizes, because it covers the in-between widths too.

Rendering and visual bugs

Beyond layout adapting to width, there are rendering bugs — the page just looks wrong — that a QA must notice and report precisely:

• Overlap, overflow, clipping — elements on top of each other, text spilling out of its box, content cut off.
• Alignment and spacing — misaligned columns, inconsistent gaps, wonky padding.
• Broken or missing images, wrong fonts, wrong colours.
• Content that does not fit — long names, large numbers, or lots of data breaking a layout that assumed short content (test with long and large content — a boundary of a different kind).
• Scroll issues — horizontal scroll that should not exist, or content unreachable because it cannot scroll.

A useful discipline: test with realistic and extreme content, not just the tidy demo data. A dashboard that looks fine with "Asha" breaks with a very long name; a total that fits at ₹100 overflows at ₹10,00,000. Rendering bugs are visual, so look carefully — and report them with a screenshot (the bug-reports lesson), because a picture communicates a layout bug far better than words.

Check your work

Responsive design and why it breaks. The layout adapts to width via CSS breakpoints; the developer builds at one size, so other sizes are under-tested. Bugs: layout breaks at some widths (overlap/overflow/ clip, esp. in-between breakpoints), content unreachable, text/touch targets too small, the collapsed/ hamburger nav broken.

What sizes. A representative range from analytics — desktop (incl. non-maximised window), tablet (both orientations), mobile-browser widths, the breakpoints and just around them (boundary values), and zoom levels. Always cover the extremes and breakpoints.

How to test. Dev-tools responsive/device mode — drag the width slowly to catch the break point; resize the real window; test at each breakpoint ±; check zoom (125%/150%); confirm on real phone/tablet.

Rendering/visual bugs. Overlap/overflow/clipping, alignment/spacing, broken images/fonts, and layouts that break with long/large content (test realistic and extreme data, not tidy demo data). Look carefully; report with a screenshot.

Practice

1. Open a web app in dev-tools responsive mode and drag the width from wide to narrow; find the width(s) where something overlaps, overflows, or disappears.
2. Test a dashboard at desktop, tablet and mobile-browser widths, and in a half-width window; note what breaks.
3. Find the layout's breakpoints (where it switches) and test at each and just either side.
4. Zoom the browser to 125% and 150% and check the layout survives.
5. Put a very long name and a very large number into a screen built for short content; find the rendering break, and capture a screenshot for the bug report.
6. Open the collapsed/hamburger menu on a narrow width and check it works — the nav the desktop developer never opens.

Official documentation

• MDN — Responsive design — How responsive layouts work and adapt.
• Chrome DevTools — Device mode — Testing responsive layouts and resizing.
• MDN — Testing responsiveness — Finding and diagnosing layout bugs.

Next: data-heavy screens — dashboards, tables, filters, forms and reports.