Test your login flow before it locks everyone out

Signup is the flow every customer completes once. Login is the flow they complete every single time after that. When it breaks, you do not lose a prospect, you lock out a paying customer who was already sold, and they are far angrier about it. Login is also the flow you are structurally worst positioned to test, because you are always already logged in. Your session works, so login "works," right up until a returning user with a cold browser cannot get in.

Why login breaks where you cannot see it

Login sits on top of session handling, cookies, redirects, and often a third-party identity provider. Any of those can fail for a returning user while looking perfect to you.

• Sessions and cookies. A change to cookie settings, a SameSite attribute, a domain mismatch, or a token format can mean the login succeeds and the session immediately does not stick. The user logs in, gets bounced back to the login page, tries again, and loops.
• OAuth redirect loops. "Sign in with Google" depends on a redirect URI that has to match exactly, a callback route that has to handle the response, and a provider config that has to stay in sync. One mismatch and the user ping-pongs between your app and the provider forever.
• Lockouts and rate limits. The rate limiting that protects you from brute force can also lock out a legitimate customer who fat-fingered their password twice, especially if the error message does not tell them what happened.
• Expired or invalidated sessions. A deploy that rotates a signing key, or a change to session storage, can silently invalidate everyone's existing session, so your entire logged-in user base gets kicked out on your next ship.
• The password-manager path. Real users log in with autofill, not by typing. A field renamed or a form restructured can break autofill even when manual entry works, and you will never notice because you type.

Because you test from an authenticated browser, none of this is visible to you. The only way to see it is to log in the way a returning user does: from scratch, in a clean session.

What good coverage looks like

A useful login test starts with no session and behaves like a returning customer:

1. Open the app in a fresh, logged-out state.
2. Go to login, enter valid credentials, and submit.
3. Confirm the session actually sticks: land on the real logged-in home, reload the page, and confirm you are still in.
4. Confirm the logged-out and error states work too: a wrong password shows a clear message and does not loop or lock instantly.
5. Watch the console and network throughout, so a failed session request or a redirect that quietly 404s is caught even when the page looks fine.

That third step, reloading to confirm the session persists, is the one that catches the nastiest login bugs, the ones where login appears to succeed and the session evaporates a moment later.

How VeriWasp fits

A VeriWasp playtest runs in a real browser with a clean session, so it logs in exactly the way a returning customer does, not the way you do from your already-authenticated tab. You describe the flow in plain English, and Claude drives it: loads the login page, enters the credentials, submits, and confirms the logged-in state actually holds. It captures every console error and failed request along the way, so a session that silently fails to persist comes back as a clear finding instead of a green check.

Run it on every deploy, and the change that would have logged out your whole user base gets caught by you first. You can test your own login flow with a few free runs, no card required.

The flow your customers use every day is the one you can least afford to break and are least able to see. Test it from the outside, cold, the way they do.