Visual interface QA

Visual QA

Look at every changed screen in a real browser, fix what is wrong by priority, look again, and report exactly what was checked.

1. Gather

• Run the app with the project's dev or preview command. List the screens in scope: every screen you changed and the screens that share the components you changed.
• Detect the styling method before editing: plain CSS, SCSS, CSS Modules (*.module.css), Tailwind (its config, utility classes), CSS-in-JS (styled-components, Emotion). Fix the style where it is defined.
• Use the browser automation the project or environment offers (Playwright, a built-in browser, DevTools): screenshots, page structure, console.
• Use realistic data and its extremes: very long names and words, many items, none, missing images, the longest language the UI ships.

2. Inspect at 375, 768, 1280 and 1920 px

Plus the project's own breakpoints and 200% zoom. Look for:

• Layout: content overflowing its parent or the viewport, unintended overlap, misalignment, uneven spacing, clipped text, sideways page scroll.
• Responsive: broken phone layouts, jumps at breakpoints, touch targets that are too small.
• Layering: dropdowns, popovers, sticky headers, modals and toasts in the right order; nothing clipped by a parent with hidden overflow.
• States: hover, keyboard focus, active, disabled, loading, empty, error, success; dark mode and other themes.
• Accessibility at a glance: contrast, visible focus, alt text.
• Consistency: fonts, brand colors, spacing between similar items.
• Console and network: no new errors, warnings or failed requests.

3. Fix by severity

Rate each issue with the same values a review's findings use:

• critical, now: breakage that blocks use (hidden content, overlap over controls, an unusable phone layout, invisible focus, unreadable contrast).
• major, next: visible problems that degrade the experience (misalignment, breakpoint jumps, small targets, bad truncation).
• minor or suggestion, if time allows: small inconsistencies and polish.
• One issue at a time, smallest change, in the project's patterns and tokens; screenshot before you change it. If a fix leaks into other areas, roll it back and scope it.

4. Re-verify

• Reload, screenshot the fixed area at the same widths, compare with the before shot, and check the neighbors for regressions. Return to step 2 until no critical or major issue remains.
• After 3 failed attempts on one issue, stop and escalate: the issue, what was tried, the suspected cause.
• Update screenshot baselines in the repo only for intended changes, after looking at the diff.

Report honestly

• Say which screens, widths, states, themes and languages you checked, and with which tool. List issues by severity: fixed ones with the file and change, unfixed ones with the reason and a recommended action. Share key screenshots when you can.
• Say what you did not check and why (no browser tool, missing data or login, an unreachable state). Never claim a visual check you did not do.

Before you finish

• Every changed screen opened at 375, 768, 1280 and 1920 px; console clean.
• Long text, empty data, errors and every theme look right.
• No critical or major issue left, or each one is reported with a reason.
• The report says what was checked and what was not.