Test Cases for Signup Page: Registration QA Checklist

The most damaging signup defect is often invisible on the form. A timeout leads the user to submit again, two account records are created, one verification email points at the wrong record, and later login behavior depends on which record an API happens to find. The page may have validated every field correctly.

Registration tests should follow identity creation from the first input through uniqueness, consent, verification, session establishment, profile defaults, and recovery. Field cases matter, but durable account state and privacy decide whether the flow is safe.

Define the Account Lifecycle

List the states an account may occupy: pending, contact unverified, active, invited, disabled, deleted, or awaiting approval. Define when the durable user record is created, when a username or email becomes reserved, when login is allowed, and how abandoned registrations expire.

Record required and optional fields, normalization rules, supported identity providers, password policy, verification lifetime, consent requirements, age or region rules, and post-signup destination. Decide whether an existing federated identity and a new password signup should link, reject, or request proof.

For social or enterprise signup, test provider cancellation, denied consent, missing required claims, changed email, unverified provider email, and callback replay. The application must validate state and redirect data, bind the external identity once, and recover without creating a local account that the user cannot later access.

Test Fields as Normalized Identity Data

Cover empty, whitespace-only, minimum, maximum, and just-over-maximum values for each text field. Include leading and trailing spaces, repeated internal spaces, accents, non-Latin names, apostrophes, hyphens, emoji according to policy, control characters, and markup-like text. Validation should preserve legitimate names while treating content as data.

For email, test casing, surrounding spaces, plus addressing if supported, long local and domain parts within policy, malformed separators, missing parts, and internationalized domains if the product claims support. Store and compare email using a documented normalization rule rather than blindly changing user-visible data.

For phone signup, cover country code, national formatting, leading zeros, pasted separators, unsupported countries, and a number already tied to another account. Never convert identifiers through numeric types that remove + or leading zero.

Prove Uniqueness Under Races

Submit the same normalized email from two browsers at nearly the same time. Exactly one account or pending identity should own it. A database uniqueness constraint or atomic identity service decision must enforce this, not a pre-submit availability check.

Repeat with case and whitespace variations that normalize to the same value. Test an address on an active, pending, disabled, deleted, and invited account. Each state needs a product-specific recovery path without exposing unnecessary account status to an unauthenticated user.

Click submit repeatedly, refresh during the request, retry after a timeout, and use browser back. Associate retries with an idempotent registration attempt where possible. Email, profile creation, welcome automation, and analytics should occur once or be safely deduplicated.

Validate Password Creation and Handling

Exercise every published rule at its boundary: length, character support, breached-password policy, similarity restrictions, and password history if applicable. Include long passphrases, spaces, Unicode, pasted input, and values that password managers generate. Do not impose hidden composition rules that the interface cannot explain.

Confirm password and confirmation comparison, show and hide behavior, Caps Lock guidance if provided, strength feedback, and accessible error association. Errors must not echo the password. Refresh, navigation, validation failure, crash reports, analytics, and logs must not retain the value.

Inspect transport and approved server-side behavior without accessing raw production credentials. Passwords should be handled only by the intended credential service and never returned in APIs, emails, support panels, or account events.

Complete Email or OTP Verification

Verify the delivery contains the correct product, destination context, secure owned link or code, expiry guidance, and an action for an unintended signup. Test immediate use, expiry boundaries, altered token, wrong account context, one-time use, browser back, and concurrent redemption.

Request resends before, at, and after cooldown. Decide whether older tokens remain valid, then prove the chosen rule. Delayed messages should not activate the wrong pending record. A resend must not create another user or send unlimited messages.

Open verification on the original device, another browser, and mobile. After success, verify the correct account state, session policy, default profile, roles, tenant membership, and onboarding route. Client-side success alone is not evidence that activation committed.

For invitation-based signup, test a valid invitation, expired invitation, revoked invitation, wrong email, existing account, and invitation consumed concurrently. The invite must bind the resulting membership and role on the server. Editing hidden tenant or role fields must not increase privilege. If an existing user accepts, the system should add the intended membership without replacing their profile or creating a duplicate identity.

Check Consent, Age, and Regional Rules

Test required terms acceptance separately from optional marketing choices. Required consent cannot be preselected where policy forbids it, and optional consent must not block registration. Record version, timestamp, source, and user choice according to the product's legal requirements.

Follow links to terms and privacy information by keyboard and on mobile without losing entered data unexpectedly. Change locale or region and verify the correct text and required controls appear. If age gates or guardian flows exist, test exact boundary dates using a controlled current date.

Withdraw optional consent after signup and confirm downstream messaging changes. A failed analytics or marketing integration must not prevent account creation or silently change the user's choice.

Resist Bots, Enumeration, and Injection

Exercise rate limits by destination, account, device, and source in an approved environment. A distributed attacker should not generate unlimited verification messages, while shared networks should have an accessible recovery path. CAPTCHA or risk challenges must be testable, localized, and usable without excluding assistive technology.

Compare duplicate and unknown identity responses for account enumeration. Product needs may require directing an existing user to login, but avoid returning private provider, lock, or activity details. Test timing and API fields as well as visible text.

Submit script-like values, SQL-like text, oversized payloads, extra JSON fields, altered role or plan fields, and direct requests that skip the UI. The server must allow-list account properties. A new user must not choose privileged roles, verified state, tenant ownership, or internal flags through crafted input.

Recover From Partial Failure

Simulate identity-store timeout, email-provider rejection, profile-service failure, tenant provisioning failure, and welcome-event processing failure. Define the transaction boundary. The user should either receive one recoverable pending account or a clear failure with no active partial identity.

Retry after each failure. Reconciliation should complete missing noncritical work or clean up according to policy without creating another account. If email delivery fails after record creation, offer resend against the same pending registration.

Test expired pending records, reused invitation links, deleted accounts, and a user returning weeks later. Support tooling and audit events should explain state transitions using correlation IDs while keeping passwords, verification secrets, and unnecessary personal data out of logs.

Make Registration Accessible on Every Viewport

Navigate labels, inputs, password controls, consent, errors, verification, and submit by keyboard and screen reader. Required state, format hints, and errors must be programmatically associated before and after submission. Focus should move to a useful error summary or first invalid field without trapping the user.

At high zoom and narrow widths, ensure password guidance, consent links, challenge widgets, and validation remain visible. Preserve entered nonsecret data through orientation changes and recoverable errors. Test autofill and password managers, since incorrect autocomplete attributes can overwrite email or expose confirmation fields.

Use translated long labels, right-to-left layout, reduced motion, high contrast, and slow network. Loading state should prevent accidental duplicate submission while remaining understandable to assistive technology.

Assemble the Registration Release Gate

Automate one complete signup and verification flow, each required-field boundary, normalized duplicate identity, concurrent submission, password-policy boundaries, token expiry and replay, unauthorized role injection, and a recoverable delivery failure. Use unique addresses and an approved test inbox or provider stub.

Add manual checks for password managers, email-client rendering, CAPTCHA accessibility, responsive layout, and localized consent. Verify cleanup prevents test accounts from polluting production-like messaging or quotas.

Finish with an identity-race scenario. Start two registrations for the same normalized identity, interrupt one after account creation, and complete the other through verification. The only acceptable result is one correctly permissioned account, one auditable lifecycle, and one usable login, even though the user-facing requests overlapped and one path failed midway.