porabuild/poracode/web-app-verification

Web App Verification

A change is not verified because the code looks right or the build passed. Drive the real flow and report what the app did.

Set the baseline

Call browser.enable once, then open the exact target the user named — their local dev URL, their preview deployment. Do not substitute a different URL or a web search when the page is unreachable; say it is unreachable.

Capture the starting state with browser.snapshot plus the current URL, and clear the console with a reload so pre-existing noise is not mistaken for your change. Note any errors that survive the reload — those are the baseline, not your regression.

Exercise the flow

Walk the path a user would take, one action at a time, using the refs from the snapshot rather than coordinates. After each navigation or state-changing action, wait for the expected URL, text, or element before continuing.

Test the boundaries the change actually touched: the empty state, the error path, the second submit. A single happy path proves very little.

Collect the evidence

For every claim you intend to make, hold one artifact:

• Visual — a screenshot when layout, spacing, or appearance is part of the requirement.
• Console — browser.console after the flow, separating new errors from the baseline.
• Network — failed or unexpected requests from browser.requests, with status codes.

Verdict

State plainly what you verified, what you observed, and what you could not check — a flow behind a login you do not have, a path that needs data you cannot create. "Works" without evidence is not a verdict.

Call browser.disable before you stop or hand back to the user.