Test form validation field by field

1. Empty.
2. One required field missing.
3. An invalid email.
4. A password below the minimum.
5. A 5,000-character value in a short text field.
6. Leading and trailing whitespace.
7. Pasted input instead of typed input, which skips some keystroke-based validation entirely.
8. A double-click on submit.

Find the main form on the site. Submit it empty, then with invalid values in each field in turn, then with valid values. Report which fields lack validation, whether errors are announced clearly, and whether the submit button can be double-fired.

Login forms have their own failure modes, so they get their own prompt:

Go to the login page. Submit the empty form, then a wrong password for test@example.com. Verify clear error messages appear, nothing is submitted twice, and no sensitive data is leaked in error text. Do not attempt to bypass authentication.

A red border with no text. An error message that appears at the top of the page, far from the field that caused it. A message rendered in a div that no assistive technology will ever read out.

Because the model reads the ARIA snapshot as well as the screenshot, "the error is visible but has no accessible name" is a finding it can actually make, rather than one that needs a human with a screen reader.

Every other item on the list produces a bad experience. This one produces duplicate records and, on a payment form, duplicate charges. If you only check one thing from this page, check that the submit button disables itself while the request is in flight.

• 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.

• No server-side validation testing beyond what the UI reveals.
• No fuzzing. It tries the values you describe, not a generated corpus.
• No security testing. It will not attempt SQL injection or XSS payloads.
• A CAPTCHA will usually end the run as blocked.