Responsive testing on laptop, tablet and phone from one prompt

Dragging your browser narrow changes one thing: the width. A real phone differs in three ways that change what the page does.

• Touch events. Hover states, :hover menus and drag interactions behave differently, or not at all.
• The user agent. Servers and frameworks branch on it, so a desktop UA can be served entirely different markup.
• Device pixel ratio. At DPR 2 the browser picks different image sources, which is where layout shift and blurry assets show up.

ZeusQA applies all three before the first navigation rather than after, so the page is built as a mobile page from the start.

430x790 is the *visible viewport* of a large modern phone, not its 932-pixel screen. Roughly 140 pixels go to the status bar and browser chrome. Most responsive bug reports are written against the screen height, which is why a layout that looks fine in a mockup still cuts off the primary button in the hand.

• Laptop — 1440x900, landscape, no touch.
• Tablet — 834x1060, touch, iPad user agent, portrait or landscape.
• Phone — 430x790, touch, mobile user agent, portrait or landscape.

See the viewport size reference for the full list and where each number comes from.

Check the layout on every device. On laptop, then tablet (portrait and landscape), then phone (portrait and landscape): scroll the full page, open the navigation, and report anything that overflows, overlaps, gets cut off or becomes unreachable. Use computer.setDevice() to switch and say which device and orientation each finding belongs to.

Mobile navigation deserves its own run, because that is where the worst of it lives:

On phone: open the hamburger menu, check every entry is reachable and tappable, close it again by the button and by tapping outside, and verify the page does not scroll behind the open menu. Then rotate to landscape with computer.rotate() and repeat.

Because the prompt asks the model to say which device and orientation each finding belongs to, the report reads as a per-device list rather than a pile of observations you then have to reproduce.

• Model — a fast model (Claude Haiku 4.5, GPT-5.6 Luna) is fine for a flow you run often. Reach for a deeper model when a run keeps getting stuck on the same step.
• Devices — laptop is enough for a first pass. Add phone when the flow is mostly used on mobile.
• Step budget — 30 scripts covers most flows. Raise it for long, multi-page journeys.
• Reasoning effort — passed straight through to the model. Higher effort costs more and thinks longer before acting.

• A verdict: pass, fail or blocked.
• Named checks, each marked passed or not, so you can see what was actually asserted.
• Findings rated critical, high, medium, low or info, with the evidence behind each one.
• A screenshot for every step, and one session video for the whole run.
• Console errors, uncaught page errors and failed or 4xx/5xx requests, collected automatically.

Worth knowing before you point it at something important.

• Chromium only. Safari-specific layout bugs will not show up here, and iOS Safari is the browser most likely to have them.
• No pixel diffing against a baseline screenshot. Findings are described, not diffed.
• This is device emulation in the same sense as Chrome DevTools device mode, not a real handset.