Password Reset Test Cases for the Complete Recovery Loop

The Minimum Password Reset Smoke Test

When release time is limited, begin with these ten scenarios.

The smoke set proves whether the primary recovery loop works. It does not independently prove token unpredictability, secure password storage, complete session revocation or resistance to account takeover.

Define the Recovery State Model First

Password recovery is not one form. It is a sequence of state transitions across the browser, messaging provider, reset-token service, identity store and authentication system.

A common recovery lifecycle is:

No active challenge
-> reset requested
-> challenge issued
-> message delivered
-> proof presented
-> challenge accepted
-> password updated
-> challenge consumed
-> session policy applied
-> normal login restored

Alternative states may include unknown identity, delivery failed, challenge expired, challenge superseded, challenge consumed, challenge blocked, SSO-managed identity, support-assisted recovery and MFA step-up required.

The exact names are implementation-specific. What matters is that each state has a defined trigger, expected account effect, observable result, permitted next action and evidence showing that the transition occurred.

Recovery-state acceptance matrix

Reset Request and Account-Privacy Test Cases

The externally visible response should not become an account directory. Controls should limit excessive recovery requests without changing or locking the account before valid proof is presented.

Recovery Email and Delivery Test Cases

A browser confirmation such as "Check your inbox" proves only that the request screen reached its expected state. It does not prove that a provider accepted the message or that the user received it.

Reset Token and Code Test Cases

Decide What Multiple Reset Requests Mean

A resend button is not a policy. When two reset requests exist, the application must define which challenges remain valid.

Policy A - latest challenge only

Request 1 -> Token A active
Request 2 -> Token A superseded, Token B active

Token A stops working immediately after Request 2. Token B remains valid. Using Token A does not consume Token B, and the older link receives a useful expired or superseded state.

Policy B - all unexpired challenges until one succeeds

Request 1 -> Token A active
Request 2 -> Token A active, Token B active
Successful use of either -> both consumed

Both tokens initially follow the documented validity window. Only one password update can succeed, and successful redemption invalidates every remaining reset challenge.

Policy C - one active recovery transaction

A new request may resend or rotate the delivery mechanism while preserving one underlying transaction. Verify the message count, underlying challenge count, expiration behavior, resend limits and whether the original URL remains valid.

New-Password and Credential-Persistence Test Cases

This section covers only the password rules required to prove recovery. The broader field and boundary matrix belongs in the Form Validation Test Cases: Align UI and API Rules guide.

old password -> rejected
new password -> accepted

A success screen is not proof that the credential was persisted. The decisive functional check is the old/new login pair above.

Session, MFA and Account-Integrity Test Cases

Account recovery is an alternate authentication path. It should not silently become weaker than the controls protecting the account.

Choose and Verify the Session Policy

Password reset can occur because a user forgot a password or because the credential may have been compromised. Session handling therefore requires an explicit decision.

Do not infer session policy merely from whether one browser was redirected to login. Verify server-side session or token state.

Accessibility, Mobile and Operational Test Cases

The Most Important Password Reset Failure Patterns

Neutral confirmation appears, but no message arrives

The request UI passes while the recovery channel is broken. Check the message queue, provider credentials, sender-domain configuration, recipient mapping, suppressed recipients, provider rejection and spam placement.

The email arrives, but the link points to the wrong environment

The form and mail provider pass, but the link still cannot recover the account. Common mistakes include localhost, staging domains, old application domains, HTTP links and truncated token parameters.

A second request invalidates the wrong token

The interface exposes Resend, but the multiple-request policy is undefined. Users receive unexplained errors or several challenges remain usable after one password change.

"Password updated" appears, but the old password still works

The UI may have received a successful response while the identity store was not updated, the wrong account was updated or authentication uses another credential store. Always verify both old and new credentials.

The new password works, but an attacker's session remains active

Changing the password does not necessarily terminate an already authenticated session. Test session consequences separately from password persistence.

Password recovery disables or bypasses MFA

The password changes successfully, but the next login no longer requires the enrolled factor, or recovery itself requires weaker proof than normal authentication.

An SSO account receives a local password

A federated user requests recovery and the application accidentally creates a local credential outside the intended identity provider.

Request flooding locks out the legitimate user

Repeated forgot-password requests should not become a denial-of-service mechanism. Apply controls to requests and delivery without disabling normal account access.

What Each Testing Layer Can Prove

A browser can show that the new-password form submitted. It cannot independently prove token unpredictability, safe storage, complete session revocation or the absence of an enumeration side channel.

How to Select Password Reset Cases After a Change

A large checklist is not a regression strategy. Select the cases that cross the changed component and the recovery states it owns.

Automating Password Reset Test Cases

The browser-visible request cases can reuse one flow:

Open the login page
Click "Forgot password"
Fill {{ACCOUNT_IDENTIFIER}}
Click "Send reset link"
Assert {{EXPECTED_REQUEST_RESULT}}

Named cases can provide existing local accounts, unknown accounts, malformed emails, SSO-managed identities, suspended accounts, repeated requests and provider failures.

A second flow can cover challenge redemption:

Open {{RECOVERY_MESSAGE}}
Follow {{RESET_LINK}}
Fill {{NEW_PASSWORD}}
Fill {{CONFIRM_PASSWORD}}
Click "Reset password"
Assert {{EXPECTED_RESET_RESULT}}

A third flow should verify authentication consequences:

Open the login page
Fill {{EMAIL}}
Fill {{PASSWORD_TO_TEST}}
Click "Log in"
Assert {{EXPECTED_LOGIN_RESULT}}

Keeping the flows separate shows whether the failure occurred in the request, delivery, challenge acceptance, credential update or normal authentication.

For the reusable-flow method, read the Web Form Testing guide.

What Browser Automation Should Not Claim

Browser automation should not be presented as proof of cryptographically secure token generation, sufficient token entropy, safe token or password storage, absence of every timing side channel, deliverability across all email providers, complete session revocation without access to session state, resistance to distributed abuse, correct MFA recovery for every threat model, or protection against host-header injection, token leakage or account takeover.

These properties require API, backend, provider, security or infrastructure checks. Browser automation remains valuable because it proves that a real user can complete the visible recovery path and that observable frontend behavior matches the tested responses.

Safe Production Password Reset Monitoring

Production is where incorrect domains, message credentials, redirect origins and provider settings become visible.

Use a dedicated synthetic account, controlled recovery mailbox, low execution frequency, generated passwords tracked securely by the test system, an identifiable audit marker, no real customer data, explicit session-invalidation handling, and automatic cleanup of messages and expired challenges.

Do not reset a shared team account, use an administrator or high-value customer, flood the mailbox, trigger support or fraud workflows accidentally, expose reset links in logs or reports, leave a production test account with an unknown password, or let monitoring bypass MFA or SSO policy.

Frequently Asked Questions

Should the page say that an email address has no account?

Use an externally consistent response for existing and non-existing identities. Status codes, redirects and meaningful timing differences should also be reviewed.

Should a successful reset invalidate all sessions?

Define the policy explicitly. Test web sessions, remembered devices and every other credential class affected by the reset.

Should a new reset request invalidate the previous link?

There is no universal UI answer. Choose latest-token-only, multiple active challenges until one succeeds, or one underlying transaction, then test concurrency and consumption.

Can a browser test prove that the reset token is secure?

No. It can demonstrate valid, expired, modified and reused behavior from the outside. Randomness, entropy, generation and storage require an authorized security or backend review.

Is password reset the same as password change?

No. Password change starts in an authenticated session and may require the current password. Password reset is an alternate identity-recovery path with different abuse risks.

Password Reset Testing Checklist

Before approving password recovery, confirm that known and unknown identities receive an externally consistent response, malformed input creates no usable challenge, repeated requests are limited without locking the account, the account remains unchanged before valid recovery proof, the message reaches the correct recovery channel, the URL uses the correct trusted HTTPS origin, links survive supported email clients and redirects, expiration is enforced server-side, consumed challenges cannot be reused, modified challenges are rejected, one account's challenge cannot affect another, multiple requests follow a documented policy, concurrent redemption permits at most one update, the new password follows the current policy, transaction failure does not display false success, the old password is rejected, the new password is accepted, the challenge is consumed after success, completion creates one audit event and notification, existing sessions follow the documented policy, MFA remains enabled, role and tenant data remain correct, SSO identities do not receive unintended local credentials, accessibility and mobile recovery remain usable, and production configuration has been tested safely.

Final acceptance criterion. The final acceptance criterion is not: "The password-reset page displayed a success message." It is: "The correct account received a new credential, the old credential was rejected, the recovery challenge became unusable, and subsequent access followed the intended session and authentication policy."

Automate the Repeatable Browser Layer

WrightTest lets teams record reusable password-reset request, recovery-form and login flows, replace fixed values with named test-case variables, and inspect separate screenshots, errors, step results and Playwright traces.

The browser checks can be exported to native Playwright .spec.ts files when they need to move into an existing repository or CI pipeline.

Use WrightTest for the repeatable browser journey, then combine it with mailbox, challenge-store, identity, session and security checks for the complete recovery loop.