How to test a signup flow: one prompt per failure mode, no scripts

Signup is the worst flow to break, for one specific reason: the people who hit the bug are, by definition, not your users yet. They don't file a ticket. They don't email support. They close the tab, and your only evidence is a dip in a conversion chart someone checks on Thursdays.

It's also one of the most bug-dense flows in a typical web app, because it touches everything at once — client validation, server validation, the database's uniqueness constraints, an email service, a session layer, and a redirect. Six systems, one form.

This is the playbook for testing all of it without writing a line of test code: what "testing signup" actually has to cover, and the plain-English prompts to cover it. The same structure we used for magic-link auth, applied to the flow that feeds it.

What "testing the signup flow" actually means

The happy path — valid email, valid password, lands on dashboard — is maybe a fifth of the surface. A real check covers:

1. Input validation, both sides. Empty fields, malformed emails, weak passwords — rejected with errors a human can act on. And critically: the client and the server must agree on the rules.
2. Password policy sanity. NIST SP 800-63B says passwords must be at least 8 characters and that verifiers should permit at least 64, so passphrases work. The classic shipped bug is a mismatch: client allows 200 characters, server (or its bcrypt call, which truncates input at 72 bytes) effectively doesn't. The user signs up successfully and can never log in again.
3. Duplicate accounts. Signing up twice with the same email fails cleanly the second time — including with case variations (Bob@example.com vs bob@example.com) and Gmail-style plus-aliases if you treat those as equivalent.
4. Account enumeration. The duplicate-email error shouldn't be a user-existence oracle. OWASP's Authentication Cheat Sheet covers this under response discrepancy: wording and timing shouldn't reveal whether an address is registered. (There's a real tension here with usability — many products deliberately accept the leak on signup and mitigate with rate limiting. The point is to decide, not to ship the leak by accident.)
5. The verification email. It arrives, the link works, the link works only once, and an unverified account is in the state you intended — blocked, limited, or grace-period — not some accidental fourth state.
6. Post-signup state. The session is live, the dashboard renders for a brand-new user (empty states!), and the welcome email doesn't fire twice.
7. The double-submit. Two fast clicks on "Create account" make one account, not two — and not one account plus one unhandled 500.

Most teams test items 1 and 6 manually, ship, and discover items 2, 4, and 7 from production weirdness over the following year. The prompts below are ordered to catch the expensive ones first.

Prompt 1: validation, both sides of the wire

Test signup validation on https://staging.yourapp.com/signup.

Try each of these and confirm the form rejects it with a clear,
specific error message:
1. Empty email, empty password
2. "not-an-email" as the email
3. A valid email with a 4-character password
4. A valid email with a password of only spaces

Then try a password of exactly 100 characters with a valid email.
If signup succeeds, IMMEDIATELY try logging in with that same
email and password on /login. If login fails after a successful
signup, flag it as a critical bug.

Watch the network tab throughout: flag any request that returns
4xx/5xx without a corresponding visible error in the UI.

That second paragraph is the client/server mismatch test — the silent account-killer from item 2. The agent signs up and then verifies the credential round-trips. A scripted suite almost never checks this because the signup test and the login test are different files with different fixtures.

Prompt 2: duplicates and what the error reveals

On https://staging.yourapp.com/signup:

1. Sign up with "dup-test@yourapp.test" and a valid password.
   Confirm it succeeds.
2. Open a fresh incognito window and sign up again with the exact
   same email. Confirm it fails with a sensible error.
3. Try once more with "DUP-TEST@yourapp.test" (different casing).
   Report whether this creates a second account or is treated as
   a duplicate.
4. Record the exact wording of the duplicate-email error. Note
   whether it confirms the account exists, and how long the
   response took compared to a successful signup.

Step 3 finds the case-sensitivity bug that creates two accounts for one human, which surfaces months later as "I logged in and all my data is gone." Step 4 gives you the evidence to make the enumeration call from item 4 deliberately — wording and timing, recorded, per OWASP's guidance.

Prompt 3: the verification email

Same setup requirement as the magic-link playbook: a test inbox the agent can read — a catch-all domain or a hosted inbox service — passed in via your scenario config rather than hardcoded.

Sign up on https://staging.yourapp.com/signup with
"verify-test@yourapp.test" and a valid password.

1. Note what the app says happens next (e.g. "check your email").
2. Before verifying: try to use the app. Report exactly what an
   unverified account can and cannot do.
3. Open the test inbox at {{INBOX_URL}}, find the verification
   email, and click the link. Confirm the account becomes verified
   and the UI reflects it.
4. Click the same verification link a second time. Report what
   happens — it should fail gracefully or no-op, not error.
5. Sign up with another address, request a resend of the
   verification email if the UI offers it, and confirm the resend
   arrives and works.

Step 2 is the one that finds real product bugs: the unverified user who can somehow reach billing, or the opposite — the unverified user stuck on a dead-end page with no resend button at all.

Prompt 4: post-signup state and the double-submit

On https://staging.yourapp.com/signup, sign up with a fresh email
and watch closely:

1. On the form, click "Create account" twice in rapid succession.
   Report whether the UI disables the button, and check the network
   log for duplicate POST requests. If two requests fired, report
   whether both returned success.
2. After landing in the app, inspect the first-run experience:
   does the dashboard render correctly for a user with no data?
   Any empty-state screens that are broken, blank, or show
   placeholder text like "undefined"?
3. Reload the page. Confirm the session persists.
4. Log out and log back in with the same credentials. Confirm it
   works and lands somewhere sensible.

Report all console errors seen at any point, even ones that didn't
visibly break anything.

New-user empty states are the most under-tested screens in SaaS, because everyone on the team has a ten-month-old account full of data. The agent's account is always brand new — that's an advantage no fixture-seeded test suite has. (It's the same reason agents catch the bugs scripts miss in general; the longer argument is here.)

Reading the results

Each run comes back as a session, not a pass/fail bit: screenshots at every step, the network log with the actual signup POST and its response, console output, and the agent's reasoning where it made a judgment call. The triage habit that pays off: read the network log even when the run passes — signup flows love to swallow a failed analytics call or a 500 from the welcome-email service without telling the UI. The run docs cover pulling session details; how to test a web app without writing code covers the general read-the-session workflow if this is your first rodeo.

Make it a habit, not an audit

Four prompts, roughly two to four minutes of agent time each, a few cents per run. The leverage isn't in running them once — it's in running them on every deploy that touches auth, accounts, email, or the dashboard shell, which in a young codebase is most deploys. Save each prompt as a Test Scenario, pin them to your staging Project, and wire them into CI against every preview deploy.

The prompts survive your redesigns, because nothing in them references a selector, an ID, or a DOM path. Rename the button, move the form, add a step — the intent didn't change, so the test didn't either.

The one to run right now

If you only run a single check today, run the credential round-trip — it's the cheapest test with the worst failure mode:

On https://staging.yourapp.com/signup, create an account with a
fresh email and a 100-character password. If signup succeeds, log
out and log back in with the same credentials on /login. If login
rejects the password that signup accepted, flag it as a critical
bug with screenshots of both attempts. Also report any console
errors or failed network requests along the way.

Your first run on Monito is free — point it at staging, paste the prompt, read the session. If it comes back clean, you've earned the Thursday conversion chart looking boring.