Test a sign-up flow without writing a script

Four states, in this order, plus a fifth that almost nobody checks by hand.

1. Empty submit. The form should refuse, and say why next to the field that is wrong.
2. Invalid values. A malformed email and a password below the minimum should each produce a clear, specific message.
3. A valid submission. An account is actually created, and the button cannot be fired twice while the request is in flight.
4. Where you land. The app should put a brand-new user somewhere deliberate, and the copy on that screen should match what actually happened.
5. The console. What the page logs while you do all of the above. This is the one a human tester almost never opens.

ZeusQA collects console errors, uncaught page errors and failed or 4xx/5xx requests on every run whether or not you asked for them, so the fifth one comes free.

Test the sign-up flow end to end. Find the primary sign-up call to action, check the form fields and validation (empty submit, invalid email, weak password), create a throwaway account with the email qa-saas-{timestamp}@example.com and the password QaSaas!2026test, report what happens after submitting, and check computer.diagnostics() for console errors and failed requests.

{timestamp} is replaced with the current Unix time when the run starts, so re-running the same prompt never collides with an account you already created.

When we ran this against llmgateway.io, the sign-up succeeded and every assertion a normal script would make passed. The interesting finding was a contradiction: the toast said to check your email and verify before signing in, yet the session was redirected straight into onboarding with a working API key. Verification was not actually enforced.

A recorded script asserts on selectors. It has no opinion about whether the sentence on screen matches what the application did. Reading the copy and the behaviour together is the part that needs a model.

Runs act on the real site. A sign-up test creates a real account, so point it at staging, or use an address pattern you can clean up later. The {timestamp} placeholder exists for exactly this.

• 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 inbox access, so it cannot click a verification link. It reports what the app said about verification and whether the session was actually restricted.
• No third-party sign-in. It will find and click a Google or GitHub button and report where it lands, but it cannot complete a consent screen on someone else's domain without real credentials.
• No SMS or authenticator codes.
• A CAPTCHA will usually end the run as blocked, and the report says so.