Manual testing guide
15 Password Reset Test Cases: OTP and Security
Password recovery must help legitimate users regain access without making account takeover easier. The examples below focus on token lifecycle, privacy-safe messaging and the state changes that follow a successful reset.
Example requirement
A registered customer can reset their password using a six-digit OTP. The OTP expires after five minutes, can be used only once and must not reveal whether an unregistered account exists.
Generate test cases for this example15
Test cases
5
Coverage types
10
High priority
CSV
Export format
15 example test cases
Filter the coverage, switch between card and table views, then copy or export the cases you need. Replace assumptions with the confirmed rules, environments and risks of your product.
Showing 15 of 15 cases
Reset the password using a valid OTP
Precondition
A registered account can receive the OTP.
Expected result
The password is changed and the user can authenticate with the new password.
Steps
- 1.Request a password reset
- 2.Enter the valid OTP within five minutes
- 3.Set a compliant new password
Reject an expired OTP
Precondition
A reset OTP was issued more than five minutes ago.
Expected result
Verification is rejected and no password change is allowed.
Steps
- 1.Enter the expired OTP
- 2.Submit verification
Prevent reuse of a consumed OTP
Precondition
An OTP was already used successfully.
Expected result
The consumed OTP is rejected and cannot authorise another password change.
Steps
- 1.Start another reset attempt
- 2.Enter the previously consumed OTP
Reject an incorrectly formatted OTP
Precondition
The OTP entry screen is available.
Expected result
Invalid formats are rejected with clear validation and no verification request is accepted.
Steps
- 1.Enter fewer than six digits, letters or special characters
- 2.Submit verification
Return a privacy-safe response for an unknown account
Precondition
The email address is not registered.
Expected result
The response does not confirm whether the account exists and does not send a usable reset credential.
Steps
- 1.Request a reset using the unknown email
- 2.Review the response
Apply the password policy to the new password
Precondition
OTP verification succeeded.
Expected result
The weak password is rejected with actionable guidance and the reset remains incomplete.
Steps
- 1.Enter a password that violates the documented policy
- 2.Attempt to confirm the reset
Handle existing sessions after a successful reset
Precondition
The account is signed in on another device.
Expected result
Existing sessions follow the documented security policy, such as revocation or an explicit reauthentication requirement.
Steps
- 1.Complete a password reset
- 2.Use the existing session on the other device
Resend an OTP after the allowed delay
Precondition
A reset OTP was issued and the resend delay is known.
Expected result
Early resend is controlled and a new credential is issued only when permitted.
Steps
- 1.Attempt resend before the delay
- 2.Wait until the delay ends
- 3.Request a new OTP
Apply the documented rule to an older OTP after resend
Precondition
Two reset OTPs were issued for one request flow.
Expected result
Validity follows the documented replacement rule and never permits multiple resets unexpectedly.
Steps
- 1.Request a replacement OTP
- 2.Try the older OTP
- 3.Try the latest OTP
Limit repeated incorrect OTP attempts
Precondition
The OTP attempt policy is configured.
Expected result
The configured delay or block is applied without revealing credential details.
Steps
- 1.Submit incorrect OTPs up to the threshold
- 2.Submit one additional attempt
Limit excessive reset requests
Precondition
The reset request policy is configured.
Expected result
Abuse controls activate consistently without exposing whether the account exists.
Steps
- 1.Request resets repeatedly from the same account and client
- 2.Review responses and delivery
Reject reuse of the current password
Precondition
The product prevents password reuse.
Expected result
Reuse is rejected according to policy without exposing stored password information.
Steps
- 1.Verify the reset credential
- 2.Enter the current password as the new password
- 3.Confirm the reset
Confirm both new-password fields must match
Precondition
Password confirmation is required.
Expected result
The reset is blocked and the mismatch receives clear guidance.
Steps
- 1.Enter different new and confirmation passwords
- 2.Submit the reset
Prevent a reset credential from authorising another account
Precondition
Two test accounts exist and a credential was issued for one.
Expected result
The credential is bound to the correct account and cannot reset another user.
Steps
- 1.Begin recovery for both accounts
- 2.Attempt to use the first account credential in the second flow
Complete password reset using keyboard navigation
Precondition
The complete reset flow is available.
Expected result
Focus remains visible and logical, errors are announced and all actions are operable.
Steps
- 1.Navigate the request, verification and password forms using only the keyboard
- 2.Complete the reset
Coverage checklist
- Test the OTP immediately before and after the five-minute boundary.
- Confirm resend behaviour invalidates or preserves earlier codes according to the specification.
- Use the same public message for registered and unregistered accounts where account discovery is a risk.
- Verify rate limits for reset requests and OTP attempts.
- Confirm the required behaviour for sessions active on other devices.
Common defects
- • The response reveals whether an account exists.
- • An OTP remains valid after it is used or replaced.
- • Rate limits apply only in the browser and can be bypassed through the API.
- • Existing sessions remain active contrary to the security policy.
- • Password-manager paste or autofill is unnecessarily blocked.
Suggested test data
- • Registered and unregistered account identifiers
- • Current, expired, consumed and replaced OTPs
- • Passwords at and around policy boundaries
- • Accounts with sessions on multiple devices
- • Attempt counts immediately below and above rate limits
Automation notes
- • Control the clock or token age in test environments instead of waiting for every expiry test.
- • Verify credential state and session state through approved APIs or fixtures.
- • Run rate-limit tests separately to avoid affecting normal recovery scenarios.
Frequently asked questions
What should password reset test cases cover?+
Cover account privacy, reset delivery, OTP or link expiry, one-time use, resend rules, attempt limits, password policy and existing sessions.
How do you test OTP expiry?+
Test immediately before, at and after the configured expiry boundary using a controlled clock or purpose-built test environment when possible.
Should existing sessions end after a password reset?+
That decision belongs to the product security policy. Testing must confirm the selected behaviour across every signed-in device.
Related test case examples
OTP test cases covering valid verification, expiry, one-time use, resend behaviour, attempt limits, privacy and input boundaries.
Login testingPractical login page test cases covering valid access, invalid credentials, validation, accessibility, session handling and security risks.
Registration testingExample registration test cases for required fields, duplicate accounts, password rules, verification, accessibility and input boundaries.
Mobile app testingMobile application test cases covering installation, permissions, connectivity, interruptions, orientation, accessibility and supported devices.
Generate cases for your own requirement
Paste your real user story, choose the coverage categories and receive structured manual test cases you can review and export.
Open the free generator