Blog
160 Test Cases for Registration Page, With Examples
Table of contents
Lorem ipsum
Lorem ipsum
Lorem ipsum
Lorem ipsum
Lorem ipsum
Test cases for a registration page check that new users can create an account easily, that bad or malicious data is rejected, and that personal data is protected from the first keystroke. Below are 160 of them, grouped by area, with examples, test data and automation code you can use straight away.
A sign-up form looks simple. A few fields, a button, a confirmation email. But it's where your product makes its first promise, collects personal data under privacy law, and faces bots, fake accounts and attackers looking for a way in. A bug here doesn't just lose a user. It can leak whether someone has an account, store a consent you never had, or let a script create ten thousand accounts overnight.
This guide goes further than a checklist. Alongside the 160 test cases, you'll find the tricky test data that breaks most forms, a fully written test case, a smoke set for every release, and examples in Playwright, Gherkin and plain English.
What a Registration Page Usually Contains
Most registration forms combine some of these fields. Test the ones yours uses, and skip the rest.
Identity: full name, or first and last name, and sometimes a username.
Contact: email address, and often a mobile number for verification or two-step sign-in.
Credentials: password and confirm password, or a passkey, or a social sign-up button.
Eligibility: date of birth, country or postcode, where the service has age or location rules.
Consent: terms and privacy acceptance, and a separate marketing opt-in.
Protection: a CAPTCHA or invisible bot check.
Action: the "Create account" button, and a link to sign in for existing users.
160 Test Cases for Registration Page
Mandatory Fields and Instructions
All mandatory fields are clearly marked
Required fields show an asterisk and the word "required" for screen readers, not colour alone, and the form explains what the asterisk means.
Submitting a completely empty form
Every mandatory field shows its own error at the same time, and focus moves to the first one.
Submitting with one mandatory field empty
Leave each mandatory field empty in turn. Only that field shows an error, and the message names it.
Optional fields left blank
Registration succeeds when every optional field is empty.
Entered data survives a failed submission
After an error, valid data stays in the form so users don't retype it. If your policy clears passwords, the message says so.
Inline validation timing
Errors appear when the user leaves a field, not on every keystroke before they've finished typing.
Errors clear once fixed
Each error disappears as soon as the field is corrected, without needing to resubmit.
Rules shown before typing
Format rules, like password requirements, are visible before the user starts, not only after they get it wrong.
Name Field Test Cases
Apostrophes and hyphens
Names like O’Brien and Smith-Jones are accepted and stored exactly as typed.
Accented and non-Latin characters
Names like José, Zoë, Nguyễn and 王芳 are accepted, stored and displayed correctly in the app and in emails.
People with one name
If the form asks for first and last name, people with a single name can still register, or the form offers a single full name field.
Maximum length
A name at the maximum length is accepted, and one character over is rejected with a clear message. Nothing is cut off silently.
Leading and trailing spaces
Extra spaces are trimmed before saving.
Only spaces
A name made of spaces is rejected as empty.
Markup in the name
A name like <b>Jane</b> is stored safely and shown as plain text everywhere, including the welcome email and admin screens.
Email Field Test Cases
Standard email address
jane@example.com is accepted.
Plus addressing
jane+news@example.com is accepted. Many forms wrongly reject the + sign.
Subdomains and newer domains
jane@mail.example.co.uk and jane@example.studio are accepted.
Missing @
janeexample.com is rejected with a message explaining the format.
More than one @
jane@example@example.com is rejected.
Missing domain or ending
jane@ and jane@example are rejected.
Spaces inside the address
jane doe@example.com is rejected.
Dots in the wrong place
Addresses starting with a dot, ending with a dot before @, or with two dots in a row are rejected.
Very long address
An address at the 254-character limit is handled, and longer ones are rejected with a clear message.
Letter case
User@Example.com and user@example.com are treated as the same account for duplicate checks.
Spaces before or after
Pasted addresses with extra spaces are trimmed, not rejected.
Confirm email field, where used
A mismatch shows a clear error, and the error clears once the two match.
Phone Number Test Cases
Use reserved fictional numbers for testing, like 07700 900123 in the UK or 555-0123 in the US, so test messages never reach real people.
Valid number with country code
A valid number with the right country selected is accepted and stored in an international format, like +44 7700 900123.
Common formats
Spaces, brackets and dashes are accepted and cleaned up, so (555) 010-0123 and 555 010 0123 are stored the same way.
Letters in the number
Letters are rejected, or blocked as the user types.
Length by country
Too short or too long numbers for the selected country are rejected.
Changing the country
Switching the country code updates the validation rules and the example placeholder.
Optional phone left blank
If the phone is optional, registration works without it.
Password Field Test Cases
Password rules have changed. NIST's latest digital identity guidance favours longer passwords, checks against known breached passwords and allowing password managers and pasting, over forced mixes of symbols and numbers. Test against the policy your product actually uses.
34. Minimum length
A password at the minimum length is accepted. NIST's current guidance recommends at least 15 characters when a password is the only sign-in factor.
35. Below minimum length
One character short is rejected, and the message says the minimum.
36. Long passphrases
A 64-character passphrase is accepted in full.
37. Spaces and any characters
Spaces, symbols and Unicode characters are allowed and stored correctly.
38. Common and breached passwords
Passwords like password123 or Spring2026! are rejected because they appear in breached password lists.
39. Password contains the email or name
A password that includes the user's email or name is rejected or warned against, as your policy says.
40. Strength meter
The strength indicator updates as the user types and matches what the server actually accepts.
41. Masked by default
The password is hidden as it's typed, and the show and hide toggle works both ways.
42. No silent truncation
An 80-character password works at sign-in with all 80 characters, not just the first 72 or 64.
43. Pasting and password managers
Pasting works, and the field uses autocomplete="new-password" so password managers can generate and save a strong password.
44. Confirm password mismatch
Different values in the two fields show a clear mismatch error.
45. Confirm password match
Matching values pass, and the mismatch error clears straight away.
46. Same rules everywhere
Registration, password reset and change password all enforce the same policy.
Date of Birth and Age Test Cases
Future dates
A date of birth in the future is rejected.
Below the minimum age
Users under your minimum age, often 13, 16 or 18 depending on the service and country, are stopped with a clear, non-judgemental message.
Exactly at the minimum age
Someone who turns 18 today is accepted, and someone who turns 18 tomorrow is not. This is the boundary most often wrong.
Leap day birthdays
29 February dates are accepted.
Date format by region
03/04/2010 is read as 3 April in the UK and 4 March in the US, depending on the user's locale, or the form uses separate day, month and year fields to avoid confusion.
Implausible dates
A birth year like 1890 is rejected or questioned.
Address and Location Test Cases
Postcode and ZIP formats
UK postcodes like SW1A 1AA, US ZIP codes like 90210 and German postcodes like 10115 are each accepted for the right country.
Address lookup
Searching a postcode fills the address fields correctly, and manual entry is still possible if the address isn't found.
Changing country
Switching country updates the fields shown, like state for the US or county for the UK.
Browser autofill
Autofill puts each part of the address in the right field.
Username Test Cases
Only relevant if your form asks for a username.
57. Allowed characters
Only the permitted characters are accepted, and the rules are shown up front.
58. Reserved names
Names like admin, root, support and system are blocked.
59. Availability check
The form says whether a username is taken before the user submits.
60. Case-insensitive uniqueness
JaneDoe and janedoe can't be registered as two different accounts.
61. Impersonation and offensive names
Names that impersonate staff or break your content policy are blocked, if your policy requires it.
Every limit on this form, from password length to minimum age, deserves a test on each side of it, which is exactly what boundary value analysis is designed to find.
Form Submission and Duplicate Account Test Cases
Successful registration
With valid data in every field, the account is created and the user sees the right confirmation or next step.
Double-clicking the button
Clicking Create account twice quickly creates one account, not two.
Refreshing after submitting
Refreshing the confirmation page doesn't resubmit the form or create a duplicate.
Back button after success
Going back after registering and submitting again doesn't create a second account.
Duplicate email
An email that's already registered doesn't create a new account. The message to the user is covered in the security cases below.
Duplicate phone number
If phone numbers must be unique, a registered number is handled the same way as a duplicate email.
Re-registering after deleting an account
A user who deleted their account can register again, or is told what to do, as your policy says.
Email already used through social sign-up
Someone who signed up with Google and now tries a password sign-up is guided to sign in or link accounts, without a duplicate being created.
Session expires mid-form
If the user takes a long time, their data is kept, or they're told clearly what happened.
Network drops on submit
The user sees a clear message and can retry, and retrying doesn't create a duplicate account.
Each of these has a matching "should fail" case, and planning them as pairs is the habit positive vs negative testing builds.
Email and Phone Verification Test Cases
Verification email is sent
An email arrives with the user's name, a working link and your branding, and doesn't land in spam on major providers.
Clicking the link twice
The first click verifies the account. The second shows a friendly "already verified" message, not an error.
Expired link
An expired link explains what happened and offers to send a new one.
Tampered link
A link with a changed token is rejected, and nothing is verified.
Resending the email
Resend works, is rate limited, and makes older links stop working if your policy says so.
Using the account before verifying
An unverified account can only do what the design allows, like browsing but not purchasing.
SMS code received
A one-time code arrives by SMS, and the correct code verifies the number.
Wrong SMS code
A wrong code is rejected, and attempts are limited.
SMS code expiry
An expired code is rejected, with an option to send a new one.
Changing the email before verifying
A new verification link goes only to the new address, and the old link stops working.
Consent, Terms and Privacy Test Cases
This is where registration testing meets privacy law. GDPR and UK GDPR set rules on consent, PECR covers UK marketing emails and texts, and US laws like COPPA and the California privacy rules add their own checks.
Terms and privacy links
Links to the terms and privacy notice open the current versions, in a way that doesn't lose form data.
Terms acceptance required
If accepting the terms is required, the user can't register without it, and the error says why.
Marketing consent is separate and unticked
The marketing opt-in is its own checkbox, unticked by default, and isn't bundled with accepting the terms.
Consent is recorded
The database records what the user agreed to, which version, and when.
Children under the minimum age
Users under 13 in the US are blocked or routed to parental consent under COPPA, and younger users elsewhere follow your service's age rules.
Cookie banner doesn't block the form
The cookie consent banner never covers fields or the Create account button, especially on mobile.
Privacy information at the point of collection
The form explains why each piece of personal data is collected, near the fields that collect it.
Privacy choices for California users
Where required, California residents can find how to exercise their privacy rights, including opting out of sale or sharing.
Social Sign-Up and SSO Test Cases
Sign up with Google, Apple or Microsoft
Each provider creates an account with the right name and email, and the user lands in the right place.
Cancelling at the provider
If the user cancels on the provider's screen, they return to the registration page cleanly.
Provider unavailable
If the provider errors or times out, the user sees a clear message and can still register by email.
Apple's Hide My Email
Accounts created with an Apple relay address work, and emails reach the user.
Same email, two methods
Signing up with Google using an email already registered with a password leads to sign-in or account linking, not a duplicate.
Email permission refused
If the user refuses to share their email with your app, the flow asks for it or explains what's needed.
Passkey sign-up, where offered
Creating an account with a passkey works on supported devices, and the user can add a backup method.
