Responsive testing isn't about checking one phone and calling it done. It's about finding the exact moment a layout starts behaving strangely—and fixing it before anyone else notices.
Test the full range
- •Desktop, tablet, mobile, and landscape. Yes, landscape. People rotate their phones.
- •Test immediately above and below each breakpoint. That's where layouts break.
Use realistic content
- •Long names, long headings, real-length paragraphs. "Test" hides problems; a long name reveals them.
- •Watch text wrapping and unexpected horizontal scrolling.
- •Check fixed and floating elements—do they cover content on small screens?
Layout trouble spots
- •Overlapping content, especially with sticky headers and bottom navigation.
- •Stretched cards and accidental empty space where a grid collapses awkwardly.
- •Image cropping and aspect ratios at different widths.
- •Safe areas on mobile (notches, home indicators).
Accessibility isn't optional
- •Keyboard navigation—can you reach every interactive element?
- •Focus visibility—if you can't see the focus ring, neither can keyboard users.
- •Tap-target sizes—buttons should be comfortably tappable, not tiny.
- •Zoom and text scaling—does the layout survive 200% zoom?
- •Respect reduced-motion preferences. Animation is a feature, not a requirement.
Visual plus automated
Automated accessibility tools catch real issues, but they don't replace human testing. A tool can tell you an image is missing alt text; it can't tell you the alt text is wrong. Use both.
Record what you find
For each issue, note: the route, the viewport, the problem, and the expected result. "It looks weird on mobile" is not a bug report.
Recheck after the fix
After a repair, revisit the affected route at the viewport that broke. Fixes sometimes introduce new breaks at adjacent widths.
Takeaway
Responsive QA is a hunt for the breakpoint where things go wrong. Be the person who finds it before launch, not the visitor who finds it after.