Authentication and access

29 sign-up form test cases, including the ones that only fail in production

Twenty-nine test cases for a sign-up form — verification, duplicate accounts, account enumeration, and the double-submit that quietly creates two users.

29 cases
8 coverage types
Last verified Sep 16, 2026

Download CSV Jump to the cases

Registration is the one form where a bug costs you the user before you ever have them. They cannot sign in to report it, and they will not email you about it. They will just leave.

Two failures show up again and again, and neither is a validation problem. The first is the double submit that creates two accounts, which only appears on a slow connection — exactly the connection the user is on when they press the button twice. The second is the duplicate-email message that politely confirms which addresses already have accounts, which is the same information leak the login page is usually careful about.

These twenty-nine cases cover the form, the verification email behind it and the account it creates.

Showing 29 of 29 cases

29 test cases for Test cases for a registration form
ID	Test case	Type	Priority	Preconditions	Steps	Test data	Expected result
REG-01	Create an account with valid details	Functional	High	No account for the address used	Fill every required field Accept the terms Submit	[email protected] / Correct-Horse-9	Account created, and the user is told to check their email.
REG-02	A verification email arrives	Functional	High	An account was just created	Check the inbox for the address used	[email protected]	One email arrives with a working verification link and a stated expiry.
REG-03	The verification link activates the account	Functional	High	An unverified account exists	Open the link from the email Sign in	—	The account is verified and the sign-in succeeds.
REG-04	Optional fields can be left empty	Functional	Medium	—	Fill only the required fields Submit	—	The account is created. Optional means optional.
REG-05	The password strength meter reacts as you type	Functional	Low	—	Type a weak password then a strong one	abc then a 16-character passphrase	The meter changes and never blocks a password that meets the stated rules.
REG-06	The terms checkbox must be ticked	Functional	Medium	—	Complete the form without ticking terms Submit	—	The form is refused and the checkbox is marked, not a generic banner.
REG-07	A duplicate email address is refused	Negative	High	An account already exists for the address	Register again with the same address Submit	[email protected]	The submission does not create a second account.
REG-08	A duplicate does not confirm the account exists	Security	High	An account already exists for the address	Register with the existing address Read the message and watch the inbox	[email protected]	The page says a verification email has been sent, and the real owner gets a "someone tried to register" email instead of a new account.
REG-09	An invalid email address is refused	Negative	High	—	Enter an address with no domain part Submit	user@	Refused at the field with a message naming the problem.
REG-10	Mismatched password and confirmation are refused	Negative	High	The form has a confirm field	Enter two different passwords Submit	Correct-Horse-9 / Correct-Horse-8	Refused at the confirm field. The first field keeps its value.
REG-11	A common password is refused	Negative	Medium	A breached-password check is in place	Enter a password from the common list Submit	Password123!	Refused with a message explaining it is too common, not too short.
REG-12	An already-used verification link is refused	Negative	Medium	The link has been opened once	Open the same verification link a second time	—	Refused with an explanation and an offer to sign in, not a server error.
REG-13	An expired verification link is refused	Negative	Medium	A link older than the stated expiry	Open the expired link	—	Refused, with a working control to send a new one.
REG-14	Name length is enforced at both ends	Boundary	Medium	—	Submit a one-character name, then one at the documented maximum	1 and 100 characters	Both are handled per the stated rule, and the maximum is not silently truncated.
REG-15	A 254-character email address is accepted	Boundary	Medium	—	Register with the longest legal address	254-character address	Accepted and stored whole.
REG-16	A 64-character password is accepted	Boundary	Medium	—	Register with a 64-character password	64 random characters	Accepted, and the same password signs in afterwards.
REG-17	A password one character under the minimum is refused	Boundary	Medium	Minimum is 8	Enter 7 characters Submit	7 characters	Refused, with the minimum stated.
REG-18	Pressing submit twice creates one account	Data integrity	High	Network throttled to a slow connection	Submit the form Press the button again before the response returns	[email protected]	Exactly one account exists and one verification email was sent.
REG-19	A role or plan field in the request body is ignored	Security	High	Request can be edited in a proxy	Add a role field set to admin to the sign-up POST Send it	role=admin	The account is created with the default role. The extra field is not bound to the model.
REG-20	Script in a name field is stored and rendered safely	Security	High	—	Register with a script tag as the display name Open any page that shows the name	a script tag	The name is shown as literal text. No script runs anywhere it appears.
REG-21	Sign-ups are rate limited	Security	High	—	Submit twenty sign-ups in a minute from one address	—	Later attempts are throttled or challenged, and the limit is applied server-side.
REG-22	The account cannot be used before verification	Security	Medium	An unverified account exists	Attempt to sign in before opening the link	—	Refused, with the reason given and the option to resend.
REG-23	The verification token is single-use and unguessable	Security	High	Two verification links captured	Compare the tokens Attempt to alter one and open it	—	Tokens are long and random with no visible pattern, and an altered token is refused.
REG-24	The password is never returned or logged	Security	High	Proxy and server log available	Register while capturing traffic Search the response and the log for the password	Correct-Horse-9	The password appears in the request body only.
REG-25	Every field has a label and required state a screen reader can read	Accessibility	High	—	Inspect the accessibility tree for each control	—	Each has a programmatic name, and required fields expose that state rather than relying on an asterisk.
REG-26	Errors are summarised and announced	Accessibility	High	Screen reader running	Submit an empty form Listen	—	A summary names each problem, is announced through a live region, and each entry moves focus to its field.
REG-27	The form can be completed with the keyboard alone	Accessibility	High	—	Complete and submit the form using only the keyboard	—	Focus order matches the visual order, focus is always visible, and the terms checkbox is reachable.
REG-28	A password manager offers to save the new credentials	Compatibility	Medium	Browser password manager enabled	Complete a registration	—	The save prompt appears, meaning the autocomplete attributes are username and new-password.
REG-29	An address with a plus tag is accepted	Localisation	Medium	—	Register using a tagged address	[email protected]	Accepted. Plus addressing is legal and common.

Case IDs are positional within this set, not stable identifiers. Import the set, then let your own tool assign its IDs.

How to use this set

Run the whole thing once when the form changes, and the seven high-priority cases on every release. The double-submit case (REG-18) is the one worth wiring into automation first — it is invisible in manual testing on a fast connection and it produces support tickets for months.

What we deliberately left out

Signing in, password reset and two-factor enrolment are separate screens with their own failure modes, so they get their own sets. Social and SSO sign-up is worth its own set too, because the interesting cases there are about identity linking rather than validation.

Questions about this set

Can I use these in my own project?

Yes. Copy them, change them, no attribution needed.

Our form is three steps, not one. Does this still apply?

Mostly. Keep everything here and add the wizard cases — back and forward without losing data, refresh in the middle, and a direct link to step two.

Why is a mass assignment case in a form test set?

Because the sign-up endpoint is usually the one place an unauthenticated user can write to your user model, which is exactly why it gets probed.

Somewhere to keep these once you have run them

Tesbo holds the cases, the runs and the results in one place, so the next release starts from what the last one proved.

Start free Self-host it