Browser and UI verification workflows
Verify user-facing behavior with real page loads, route checks, and observable UI evidence.
Reliable verification loop
A reliable UI check starts from the user-visible route and ends with evidence another operator can replay. Do not stop at “the build passed” when the change affects layout, navigation, text, forms, or browser-only behavior.
- Open the exact URL or navigation path a user will use.
- Name the expected heading, text, control, link, or visible state before checking it.
- Observe the actual page result, including status, console errors, and visible failures.
- Capture durable evidence such as a screenshot, snapshot, console output, or route/status note.
- Fix the issue if needed, then rerun the same check and one adjacent path before calling the UI verified.
What to check
Browser checks should match what a user will actually do.
- Open the route directly and confirm the page title or primary heading.
- Click the navigation path users will follow, not only the route under test.
- Verify forms, buttons, and links that changed in the batch.
Evidence to capture
A useful UI validation tells the next person exactly what worked or failed.
- Record the URL, status, and visible page result.
- Capture the console or server error when the page fails.
- Retest after fixes and report the final passing evidence.
Concrete passing evidence
Loaded /docs/browser-and-ui-verification-workflows, observed the expected H1, no console errors, screenshot saved, and the related links rendered.
Concrete failing evidence
Loaded the route, expected the “Next” section, observed a 404 on a related link, captured the URL and screenshot, then retested after the link was corrected.
Good user requests
Open the docs page at /docs/browser-and-ui-verification-workflows, verify the H1 and “Next” links, capture a screenshot, and report the URL, observed result, and any console errors.
Navigate from the docs index to the target page, confirm the breadcrumb and primary heading, click one related link, and include screenshot or snapshot evidence for each route.
After the UI fix, rerun the failing path and one adjacent navigation path. Show expected text, observed text, status, screenshot evidence, and whether the issue is complete or still blocked.
Save the screenshot or snapshot as a session artifact and report the artifact path along with the URL and browser state it proves.
Verification checklist
Record the check in a compact evidence table so future sessions can distinguish expected behavior from observed browser results.
| URL | Expected text or element | Observed result | Screenshot or snapshot evidence |
|---|---|---|---|
| Exact route or navigation path. | Heading, link text, form field, button, status, or visible state. | What the browser actually showed, including failures. | Screenshot path, snapshot path, console capture, or session artifact. |
- Include viewport or device context when layout is part of the risk.
- Name whether evidence is from a direct route load, navigation path, or retest after a fix.
- If no screenshot is possible, record the snapshot text or console/server evidence that proves the result.
Failure triage
When a browser check fails, capture enough context to decide whether the problem is route, data, auth, or rendering.
- Record the exact URL, expected page, and the visible failure before retrying.
- Check whether the route needs login, seeded data, a running worker, or a specific environment.
- Compare browser console errors with server logs so client and server failures are not mixed together.
- After a fix, rerun the same path and one adjacent navigation path before calling the UI verified.
When to use browser automation
Use browser automation when build output is not enough.
- Use it for layout, navigation, login, settings, docs, and workflow routes.
- Use it when JavaScript or server routing affects the result.
- Do not let browser checks replace build and link validation when those are also relevant.