Nobody has a closet full of every phone, laptop, and browser version a real visitor might show up with. User agent testing exists to close some of that gap cheaply — not to replace real device testing, but to catch a specific, common category of bug before it ever reaches a real device.
What user agent testing actually catches
Anything a site decides based on that one header: serving a mobile-optimized layout versus a desktop one, branching a feature check for an older browser, or redirecting app-store traffic differently from browser traffic. If your site's logic reads the user agent and makes a decision, testing with different user agent strings will exercise that decision path. If your site doesn't read the user agent at all — most modern responsive layouts don't — this kind of testing won't tell you much, and the bug you're chasing is probably elsewhere (real viewport size, touch support, actual rendering behavior).
A practical order of operations
Start by identifying whether your site actually branches on user agent at all — check server logs or code for any user-agent string matching, redirect rule, or conditional. If it doesn't, skip straight to responsive testing tools that emulate viewport size instead, since that's what's actually driving your layout.
If it does branch on user agent, build a short list covering the combinations that matter for your audience: your top two or three browsers, each on both a common desktop OS and a common mobile OS, plus one deliberately older version to check that your minimum-supported-browser fallback still works. Five to eight user agent strings usually cover the meaningful paths without turning into a combinatorial project.
Set each one in your browser's developer tools (most have a network conditions or device toolbar panel for this) or via a request-modifying browser extension, then walk through your site's key paths — homepage, main conversion flow, anything with user-agent-based redirects — under each string. Note anything that looks wrong: a redirect loop, a layout that didn't switch, a feature that silently failed instead of degrading.
Where this workflow stops being enough
User agent testing can't catch problems that depend on real rendering behavior, actual touch input, genuine screen dimensions, or device-specific performance characteristics — an emulated mobile user agent on a desktop browser will not reproduce a real mobile Safari rendering quirk, a slow network condition, or a low-memory crash. For anything customer-facing and high-traffic, treat user-agent testing as the fast first pass that catches obvious branching bugs, and follow it with testing on a small set of real devices (owned, borrowed, or through a device-testing service) before shipping.
A minimal checklist
Confirm the site actually branches on user agent before investing time here. Cover your top browsers on both a desktop and mobile OS. Include one older browser version to verify the fallback path. Check redirects and layout switches specifically, since those are what user-agent branching usually controls. And treat a clean pass here as a first filter, not a final sign-off — real-device testing still catches what this workflow structurally can't.