Browse the Knowledge Hub32 resources
Test cases
Registration test cases, including the identity cases
Twenty eight cases for a signup form: field validation, password rules, duplicate accounts, verification link handling, bot protection and accessibility. The cases that find real defects here are about identity, not about empty fields.
All 28 test cases, ready to copy
Free to use and adapt, no sign-up. Download as CSV or Markdown, or copy it straight into your own tooling.
Last updated
28 worked examples
Register successfully with valid details
TypeFunctionalPriorityHigh- Test data
- Unused email, compliant password, all required fields
- Expected result
- Account created in unverified state, verification email queued, user informed to check email. No session granted yet if verification is required first.
Reject registration when a required field is empty
TypeNegativePriorityHigh- Test data
- Each required field left blank in turn
- Expected result
- Submission blocked, error shown against the specific field, previously entered values preserved.
Reject a malformed email address
TypeNegativePriorityHigh- Test data
- user@, @domain.com, user@domain, user domain.com, user@@domain.com
- Expected result
- Each value rejected with a field level message. No account created.
Accept valid but unusual email formats
TypeBoundaryPriorityMedium- Test data
- [email protected], [email protected], unicode local part if supported
- Expected result
- Accepted. Plus addressing and subdomains are valid and are wrongly rejected by many hand written validators.
Attempt to register an email that already exists
TypeSecurityPriorityHigh- Test data
- Email belonging to an existing account
- Expected result
- No new account created. Response does not confirm the address is registered. Preferred behaviour is a neutral message plus an email to the existing owner telling them a signup was attempted.
Check registration does not leak account existence through timing or wording
TypeSecurityPriorityHigh- Test data
- Existing email versus unused email, compare responses and timings
- Expected result
- Message text, status code and response time are indistinguishable between the two cases.
Reject a password below the minimum length
TypeBoundaryPriorityHigh- Test data
- Minimum length minus one character
- Expected result
- Rejected with the rule stated. Requirements shown before submission, not only after.
Accept a password at the maximum supported length
TypeBoundaryPriorityMedium- Test data
- Maximum allowed length, then maximum plus one
- Expected result
- Maximum accepted and login with it succeeds. Maximum plus one rejected clearly rather than silently truncated, because silent truncation breaks the next login.
Reject a password that fails complexity or breach checks
TypeSecurityPriorityHigh- Test data
- password123, the user own email as password, a known breached password
- Expected result
- Rejected with guidance. Breach list checking is preferred over arbitrary character class rules.
Confirm password mismatch is caught
TypeNegativePriorityMedium- Test data
- Password and confirmation differing by one character
- Expected result
- Blocked with a message on the confirmation field. Neither value cleared.
Verify the account through the emailed link
TypeFunctionalPriorityHigh- Test data
- Fresh verification link
- Expected result
- Account moves to verified, link is consumed, user lands on a signed in state or a clear next step.
Reuse a verification link that has already been used
TypeSecurityPriorityHigh- Test data
- Link opened a second time
- Expected result
- Rejected as already used. No state change. Message does not expose account details.
Use an expired verification link
TypeBoundaryPriorityHigh- Test data
- Link older than the configured expiry
- Expected result
- Rejected with an option to request a new link. Old token invalidated.
Attempt privileged actions before verification
TypeSecurityPriorityHigh- Test data
- Unverified account attempting the actions verification is meant to gate
- Expected result
- Blocked server side, not only hidden in the interface. This is the most commonly missed case on this feature.
Request a new verification email repeatedly
TypeSecurityPriorityHigh- Test data
- Resend requested ten times in a minute
- Expected result
- Throttled after a small number of attempts, with a stated wait. Prevents using your service to spam a third party.
Submit the form twice in quick succession
TypeStatePriorityHigh- Test data
- Double click submit, or replay the request
- Expected result
- Exactly one account created. Second attempt is rejected or treated as idempotent, never producing a duplicate record.
Register with leading or trailing whitespace in the email
TypeBoundaryPriorityMedium- Test data
- " [email protected] "
- Expected result
- Trimmed and accepted, and the same normalisation applied at login so the account remains reachable.
Register with mixed case in the email
TypeFunctionalPriorityHigh- Test data
- [email protected] then [email protected]
- Expected result
- Treated as one identity. The second attempt is a duplicate, not a second account.
Enter names with apostrophes, hyphens and non Latin characters
TypeBoundaryPriorityMedium- Test data
- O'Brien, Anne-Marie, non Latin script names, names of one character
- Expected result
- Accepted and stored without corruption, and displayed correctly afterwards. Overly strict name validation is a real accessibility and inclusion defect.
Attempt script and SQL payloads in text fields
TypeSecurityPriorityHigh- Test data
- <script>alert(1)</script>, ' OR 1=1 --, template expression payloads
- Expected result
- Stored safely and rendered as text everywhere it appears later, including admin views and emails. No execution, no query error.
Bypass client side validation
TypeSecurityPriorityHigh- Test data
- Direct request to the registration endpoint with invalid values
- Expected result
- Server rejects with the same rules as the interface. Client validation is convenience only.
Register while a required consent or terms checkbox is unchecked
TypeNegativePriorityHigh- Test data
- Terms unchecked, marketing consent unchecked
- Expected result
- Terms enforced server side. Marketing consent defaults to off and is stored as given, since consent records are a compliance artefact.
Complete registration with the automated bot protection active
TypeFunctionalPriorityMedium- Test data
- Normal user completing the challenge, then a scripted submission
- Expected result
- Genuine user passes without excessive friction. Scripted submission is blocked. Verify the challenge has an accessible alternative.
Navigate the whole form by keyboard only
TypeAccessibilityPriorityHigh- Test data
- Tab, Shift Tab, Space and Enter only
- Expected result
- Logical focus order, visible focus indicator, all controls reachable, form submittable with Enter.
Check errors are announced to a screen reader
TypeAccessibilityPriorityHigh- Test data
- NVDA or VoiceOver with a deliberately invalid submission
- Expected result
- Errors are programmatically associated with fields and announced. Colour is not the only indicator of an invalid field.
Verify password manager and autofill behaviour
TypeCompatibilityPriorityMedium- Test data
- Browser and mobile password managers
- Expected result
- Autocomplete attributes allow a generated password to be saved. Paste is not blocked, since blocking paste actively discourages strong passwords.
Interrupt registration mid form on mobile
TypeStatePriorityMedium- Test data
- Background the app or rotate the device with the form half complete
- Expected result
- Entered values preserved, no duplicate submission on resume.
Register when the email service is unavailable
TypeNegativePriorityHigh- Test data
- Mail provider returning errors or timing out
- Expected result
- Either the account is created with a clear path to resend verification, or the transaction fails cleanly with nothing half created. An account that exists but can never be verified is the failure to avoid.
What goes in each field
ID
RequiredStable identifier, prefixed by module.
Test case
RequiredWhat is being verified, in one line.
Type
Functional, negative, boundary, security, state, performance, accessibility or compatibility. Use it to check coverage is spread rather than clustered on the happy path.
Priority
Risk based. Duplicate account handling, enumeration and verification bypass are High regardless of how unlikely the path looks, because each one has a direct security or data integrity consequence.
Test data
The specific values, including the invalid and boundary ones.
Expected result
RequiredThe precise observable outcome, including message text where the wording itself is the requirement.
Start with duplicates and verification
Empty field validation is caught by anyone using the form once. These four areas are where signup actually breaks.
Test the duplicate path first
What happens when the email exists is the single most consequential behaviour on this form, for both users and security.
Try to act before verifying
Call the endpoints an unverified account should not reach. Interfaces hide those actions; servers often still allow them.
Submit twice, fast
Double submissions create duplicate accounts, duplicate welcome emails and duplicate analytics events.
Break the email provider
An account that exists but can never be verified is a support ticket you cannot resolve. Test with mail failing.
Where registration defects actually live
The duplicate email case is where correctness and security collide. Telling the user the address is already registered is friendly and also confirms to anyone who asks that an account exists, which is the first step of a credential stuffing campaign. The behaviour that satisfies both concerns is a neutral response plus an email to the real owner, and it is worth deciding deliberately rather than inheriting whatever the framework does.
The verification bypass case is the one we find most often on client work. The interface hides the features that require a verified account, and the endpoints behind them accept requests anyway. Test at the API layer, with a token from an unverified account, and check every action verification is supposed to gate.
Case sensitivity and whitespace on the email field cause a specific and confusing bug: registration normalises the address one way, login normalises it another, and the account becomes unreachable. Register with mixed case and trailing spaces, then log in with the clean value, and confirm they resolve to the same identity.
Finally, name validation. Rules that reject apostrophes, hyphens or non Latin characters are a genuine defect that excludes real people, and they show up in almost every hand written validator. Include those cases and treat failures as bugs rather than as edge cases.
Suggest an improvementBuilding authentication?
QAble tests signup, login and account recovery as one flow, including the security cases that only appear when you call the API directly.
Functional testing servicesMore test case sets
View allTest cases for a login page
Test cases25 cases across functional, negative, boundary, security, session and accessibility paths, including account enumeration and lockout.Test cases for search functionality
Test cases28 cases across relevance, partial and fuzzy matching, filters, pagination, empty states, injection attempts and performance under load.Test cases for a shopping cart
Test cases27 cases on quantity limits, price recalculation, stock changes, coupon stacking, guest to account merge and cart persistence.Test cases for checkout and payment
Test cases30 cases including 3D Secure, declines, timeouts, duplicate charges, idempotency, refunds and partial captures.Test cases for file upload
Test cases28 cases on size and type limits, spoofed content types, malicious filenames, progress, resume, virus scanning and storage limits.Test cases for forgot password
Test cases26 cases on reset token expiry, single use enforcement, session invalidation and the enumeration and rate limit gaps that are routine here.Test cases for OTP verification
Test cases26 cases on expiry, resend throttling, attempt limits, code reuse, delivery failure and the brute force window teams forget to close.Test cases for user roles and permissions
Test cases26 cases on horizontal and vertical privilege checks, direct object access, role changes mid-session and permission inheritance.Test cases for form validation
Test cases27 rules-based cases on required fields, length and numeric boundaries, client and server parity, hidden field tampering and error accessibility.Test cases for a date picker
Test cases26 cases on timezone shifts, ambiguous day and month order, impossible dates, min and max limits, leap years and keyboard operation.Test cases for pagination
Test cases24 cases on ordering stability, records changing mid-session, page size caps, deep offset cost, permission-filtered totals and state restore.Test cases for push notifications
Test cases26 cases on app states, deep link routing, token release on sign out, lock screen privacy, preferences, provider failures and platform differences.Test cases for reports and data export
Test cases25 cases on permission filtering in the file, spreadsheet formula injection, encoding, typed numbers and dates, row limits and audit logging.Test cases for a chatbot
Test cases28 cases on paraphrased intents, context, fallback loops, human handoff, policy grounding, prompt injection and data scoping.Sources
- OWASP ASVS verification requirements for authentication, session and access control.
- OWASP Web Security Testing Guide test procedures for enumeration, injection and authorisation.
- WCAG 2.2 the success criteria behind the accessibility cases.
Want your signup flow tested properly?
QAble covers authentication end to end with ISTQB-certified engineers. Start with a free QA audit of your product.