Password reset looks like a simple feature.
A user clicks Forgot Password, enters an email address, receives a recovery link, creates a new password, and logs in again.
But from a QA perspective, password recovery is much more than a form and an email.
The flow involves identity, authentication, tokens, expiration, sessions, redirects, email delivery, password policies, rate limiting, account privacy, and security.
A small mistake can create serious consequences.
A reset link that never expires can remain usable long after it should.
A token that can be reused may allow repeated password changes.
An application that responds differently for registered and unregistered email addresses can reveal which users have accounts.
A reset flow that does not invalidate existing sessions may leave compromised accounts exposed.
And a recovery link that works in one browser but fails after a redirect can turn a legitimate recovery request into a support ticket.
This makes password reset testing an important part of both functional QA and security-focused testing.
This guide explains how QA teams can systematically test password reset and account recovery flows, including positive scenarios, edge cases, token behavior, security boundaries, session handling, and automation.
---
What Is Password Reset Testing?
Password reset testing verifies that users can securely recover access to their accounts when they forget their passwords.
A typical password reset flow looks like:
Forgot Password → Enter Email → Receive Recovery Link → Open Link → Create New Password → Login
QA needs to verify every stage of this journey.
That includes:
- Forgot-password form
- Email validation
- Account lookup
- Reset token generation
- Email delivery
- Reset URL
- Token expiration
- Token validity
- Password validation
- Password update
- Session invalidation
- Login after reset
- Existing-session behavior
- Error handling
- Rate limiting
- Account privacy
- Browser behavior
- Mobile behavior
The important point is that password reset testing is not just UI testing.
It is testing the complete recovery mechanism.
---
Why Password Reset Testing Matters
Password recovery is often treated as a secondary feature because users normally interact with it only when something has gone wrong.
But that is exactly what makes it important.
When a user forgets their password, they are already blocked from the product.
The recovery process must therefore be:
- Reliable
- Understandable
- Secure
- Predictable
- Fast enough
- Resistant to abuse
A failure can create several types of problems.
Functional problem
The user never receives the reset email.
Usability problem
The user clicks the link but doesn't know what to do next.
Security problem
The reset token can be reused.
Privacy problem
The application reveals whether an email address belongs to an account.
Session problem
A password change does not invalidate sessions created before the reset.
Integration problem
The email contains a broken URL.
Password recovery therefore deserves dedicated test coverage rather than being treated as a small part of login testing.
---
Anatomy of a Password Reset Flow
A typical implementation can be represented as:
```text
User
↓
Forgot Password
↓
Enter Email
↓
Recovery Request
↓
Token Generated
↓
Reset Email Sent
↓
User Opens Link
↓
Token Validated
↓
New Password
↓
Password Updated
↓
Sessions Handled
↓
Login
Every transition is a potential test boundary.
For example:
What happens if the email does not exist?
What happens if the token expires?
What happens if the token is modified?
What happens if the token is used twice?
What happens if the user requests two reset links?
What happens if the password violates the policy?
What happens to existing sessions after the password changes?
A good test strategy follows the entire flow rather than testing the reset form in isolation.
Password Reset Testing Categories
A useful password-reset test strategy can be divided into:
Functional testing
Validation testing
Token testing
Expiration testing
Security testing
Session testing
Email testing
Browser testing
Abuse and rate-limit testing
Recovery-flow automation
Each category catches a different class of defect.
1. Test the Forgot Password Form
Start with the recovery request form.
Typical input:
Email address
Test the obvious cases first.
Valid email
Enter a valid account email.
Expected:
Request is accepted.
Appropriate confirmation is displayed.
Recovery process begins.
Invalid email
Examples:
abc
user@
@example.com
user.example.com
Verify that invalid input is handled correctly.
Empty email
Submit without entering anything.
Expected:
Validation message appears.
No unnecessary recovery request is created.
Leading and trailing spaces
Test:
user@example.com
The application should handle whitespace consistently.
Case variation
Test:
User@example.com
versus:
user@example.com
Email handling should follow the application's intended account rules.
2. Test Existing and Nonexistent Accounts
This scenario is important for both functionality and security.
Test with:
Existing account
Nonexistent account
Disabled account
Locked account
Unverified account
Deleted account where applicable
The application should follow a consistent privacy-preserving response where appropriate.
For example, instead of clearly stating:
No account exists for this email.
the product may use a generic message such as:
If an account exists for this email address, you will receive recovery instructions.
The exact product behavior may vary, but QA should deliberately test whether account existence is unintentionally revealed.
3. Test Account Enumeration
Account enumeration occurs when an attacker can determine whether a specific email address is registered.
For example:
Existing email
Response:
Reset email sent.
Nonexistent email
Response:
No account found.
That difference can reveal which users have accounts.
Test for differences in:
Message text
HTTP response
Response body
Status code
Timing
Redirect behavior
UI behavior
A secure implementation should avoid unnecessarily exposing account existence.
This is especially important for applications where user identities are sensitive.
4. Test Reset Email Generation
Once a valid recovery request is submitted, verify the email.
Check:
Email is generated.
Correct recipient receives it.
Subject is correct.
Branding is correct.
Reset URL exists.
URL points to the correct environment.
Link is not malformed.
Instructions are understandable.
Expiration information is accurate if displayed.
No sensitive information is unnecessarily included.
Also verify that links generated in test environments do not accidentally point to production.
5. Test the Reset URL
A reset URL often looks conceptually like:
https://example.com/reset-password?token=...
The token is a security-sensitive value.
Test:
Valid token
Invalid token
Modified token
Empty token
Missing token
Expired token
Previously used token
The application should not treat arbitrary values as valid recovery credentials.
6. Test Token Expiration
Reset tokens should have a defined lifetime according to the application's security requirements.
Test:
Request password reset.
Receive the token.
Wait until the token expires or simulate expiration.
Open the reset URL.
Attempt to set a new password.
Expected:
Token is rejected.
Password is not changed.
User receives a clear recovery message.
User can request a new reset link.
Expiration testing is particularly important because password reset links can be stored in email accounts, browser history, screenshots, logs, and other places.
7. Test Token Reuse
A critical scenario is using the same reset token more than once.
Example:
Request reset.
Open valid reset link.
Change password successfully.
Return to the same reset URL.
Try to change the password again.
The previously used token should normally no longer be accepted.
This helps prevent replay-style attacks against recovery credentials.
8. Test Multiple Reset Requests
What happens when the user requests multiple reset links?
For example:
Request reset.
Receive Token A.
Request reset again.
Receive Token B.
Test:
Token A
Token B
Token A after Token B is generated
Token B after Token A is generated
The application's intended policy should be explicit.
Some systems invalidate previous tokens when a new reset request is generated.
Others may allow multiple valid tokens within a controlled window.
QA should verify the actual intended behavior rather than assuming one implementation.
9. Test Token Modification
A reset token should not become valid simply because it looks structurally correct.
Test modifications such as:
Remove characters
Add characters
Change characters
Change encoding
Copy only part of the token
Replace the token entirely
Duplicate query parameters
Modify URL parameters
Expected:
The token should be rejected.
10. Test Missing and Malformed Tokens
Test URLs such as:
/reset-password
/reset-password?token=
/reset-password?token=invalid
/reset-password?token=123
The application should respond safely.
It should not:
Crash
Display internal errors
Load another user's reset form
Assume a default account
Reveal sensitive implementation details
11. Test Password Validation
Once the reset page loads, test the new-password rules.
Depending on the product, this might include:
Minimum length
Maximum length
Uppercase requirement
Lowercase requirement
Number requirement
Special character requirement
Previously used password restriction
Common-password restriction
Password confirmation
Test boundary values.
For example, if the minimum length is 12:
11 characters
12 characters
13 characters
Do not assume the UI validation is enough.
The backend should enforce password rules as well.
12. Test Password Confirmation
If the form contains:
New Password
and:
Confirm Password
test:
Matching values
Password:
ExamplePassword123!
Confirm:
ExamplePassword123!
Expected:
Password can be submitted.
Different values
Password:
ExamplePassword123!
Confirm:
ExamplePassword456!
Expected:
Submission is rejected.
Also test differences involving:
Case
Spaces
Special characters
Leading/trailing whitespace
13. Test Password Policy Enforcement on the Backend
A common mistake is validating password rules only in the frontend.
A user may bypass browser validation by sending a request directly.
Therefore, test the backend behavior as well.
For example, if the application requires:
Minimum 12 characters
One number
One special character
try submitting an invalid password through the underlying request.
The server should still reject it.
This is an important distinction between:
UI validation
and
security validation.
14. Test Password Reuse Rules
If the product prevents users from reusing recent passwords, test it.
Example:
Current password:
PasswordA
Attempt to reset to:
PasswordA
Expected:
The password should be rejected if password history rules prohibit reuse.
Also test:
Immediate previous password
Older password
Similar password
Case variation
Minor modification
The exact policy depends on the product.
15. Test Successful Password Reset
The primary happy path should verify the entire journey.
Example:
User requests password reset.
User receives email.
User opens the link.
User enters a valid new password.
Password is accepted.
User receives confirmation.
User logs in using the new password.
Then verify that the old password no longer works.
This is one of the most important end-to-end recovery scenarios.
16. Test the Old Password After Reset
After successfully resetting the password:
Try the old password.
Try the new password.
Expected:
Old password:
Rejected
New password:
Accepted
If the old password continues to work when the product expects it to be invalidated, investigate the authentication implementation.
17. Test Existing Sessions After Password Reset
This is a critical security scenario.
Imagine a user is logged in on:
Laptop
Phone
Tablet
The user then resets their password.
What happens to the existing sessions?
The intended behavior depends on the product's security model.
Some applications invalidate all existing sessions.
Others may keep trusted sessions active while requiring reauthentication in certain circumstances.
QA should verify the documented product behavior.
This is particularly important when password recovery is being used because the user may suspect their credentials were compromised.
18. Test Login After Password Reset
After the reset:
New password
Should authenticate successfully.
Old password
Should behave according to the product's password invalidation rules.
Also verify:
Remember-me behavior
MFA behavior
Device trust
Session creation
Login redirects
Password reset should integrate correctly with the rest of the authentication system.
19. Test Password Reset With MFA
If the application supports multi-factor authentication, test how recovery interacts with it.
Possible flows include:
Forgot Password → Reset Password → MFA → Login
or:
Forgot Password → Identity Verification → Reset Password
Test:
Valid MFA
Invalid MFA
Expired MFA challenge
Missing MFA
Recovery from a new device
Recovery when the MFA device is unavailable
The exact flow depends on the application's security model.
The important point is that password recovery should not accidentally bypass stronger authentication controls.
20. Test Disabled and Locked Accounts
Password recovery behavior may differ for:
Disabled users
Locked accounts
Suspended accounts
Deleted accounts
Unverified accounts
Test each relevant account state.
Verify that the application does not accidentally restore access to accounts that should remain disabled.
21. Test Rate Limiting
Password reset endpoints are attractive targets for abuse.
Test repeated requests from the same:
Account
IP
Device
Session
The application may use:
Rate limiting
Temporary delays
CAPTCHA
Account-level throttling
IP-level controls
The exact mechanism depends on the product.
QA should verify that repeated recovery requests do not create uncontrolled abuse opportunities.
22. Test Email Delivery Delays
Email is asynchronous.
The reset request may succeed while the email takes time to arrive.
Test scenarios such as:
Immediate delivery
Delayed delivery
Duplicate email
Email provider failure
Temporary delivery failure
The application should provide a sensible user experience.
For example, repeatedly clicking Send Again should not create uncontrolled reset requests.
23. Test Resend Behavior
If the product provides:
Resend Reset Email
test:
Single resend
Multiple resends
Rapid clicks
Resend after token expiration
Resend after successful reset
Also verify which token remains valid according to the application's design.
24. Test Reset Link in Different Browsers
Users may open recovery emails on one device and complete the process on another.
Test:
Chrome
Edge
Firefox
Safari where applicable
Mobile browsers
Also test scenarios such as:
Request reset on desktop.
Open email on phone.
Open link on phone.
Complete password reset.
This can reveal assumptions about browser state or device state.
25. Test Reset Links in Mobile Email Applications
Many password resets begin inside mobile email applications.
Test links opened from:
Gmail
Outlook
Mobile email clients
Messaging applications where links may be forwarded
Verify:
Link opens correctly.
Correct browser/app is launched.
Token is preserved.
Page renders correctly.
Password fields work correctly.
Reset succeeds.
26. Test Browser Back Button
Password reset pages often contain security-sensitive state.
Test:
Open reset link.
Enter a new password.
Complete reset.
Press Back.
Attempt to submit the form again.
The application should handle the old reset state safely.
This can help expose token reuse and stale-page issues.
27. Test Opening the Reset Link Multiple Times
Test:
Receive a valid reset link.
Open it in one browser tab.
Open it again in another tab.
Attempt to complete the reset in both.
This can expose concurrency problems.
For example:
Tab A:
Password A
Tab B:
Password B
The product should have a clearly defined outcome.
28. Test Concurrent Password Reset Requests
Use multiple reset requests at nearly the same time.
Check:
Token behavior
Email ordering
Token invalidation
Password state
Session behavior
Error handling
This is particularly useful for detecting race conditions.
29. Test Reset URL Leakage
Reset tokens are sensitive.
QA should consider where tokens might appear.
Potential locations include:
Browser history
Server logs
Analytics
Referrer data
Screenshots
Monitoring tools
Third-party scripts
The application should minimize unnecessary exposure of recovery credentials.
Where technically appropriate, teams may also use patterns that reduce the lifetime or exposure of sensitive tokens in URLs.
30. Test Error Handling
Password reset should fail gracefully.
Test scenarios such as:
Email service unavailable
Database failure
Token service failure
Expired token
Invalid token
Password update failure
Network interruption
Session expiration
The user should receive a useful message without seeing:
Stack traces
Internal database details
Secrets
Tokens
Debug information
Password Reset Test Case Matrix
A practical matrix might look like this:
Scenario Expected Result
Valid registered email Recovery process starts
Unknown email Privacy-preserving response
Invalid email Validation error
Empty email Validation error
Valid reset token Reset page opens
Expired token Token rejected
Modified token Token rejected
Used token Token rejected
Missing token Safe error
Valid new password Password updated
Weak password Rejected
Mismatched confirmation Rejected
Old password after reset Rejected according to policy
New password after reset Login succeeds
Unauthorized session Handled according to security policy
Multiple reset requests Defined token behavior
Excessive reset requests Rate limiting applied
Disabled account Correct account-state behavior
Password Reset Security Testing
Password recovery is a security-sensitive workflow, so QA should think beyond functional correctness.
Important security questions include:
Can an attacker determine whether an account exists?
Can a reset token be reused?
Can a token be modified?
Can an expired token still work?
Can one user's token reset another user's account?
Can password reset bypass MFA?
Can an unauthorized user change the password?
Are existing sessions handled correctly?
Are reset tokens exposed unnecessarily?
Can the endpoint be abused through unlimited requests?
These questions can reveal issues that ordinary functional testing misses.
Testing for Cross-Account Token Problems
A particularly important scenario is verifying that a token belongs to the correct account.
Suppose:
User A requests a reset.
User B should never be able to use User A's token to change User B's password.
Test that the token is cryptographically and logically bound to the correct recovery request.
Also verify that modifying account-related URL parameters does not change which account the token represents.
For example, if a reset URL contains both:
user=123
and:
token=ABC
changing the user identifier should not allow the token to operate on another account.
The server should derive identity from trusted recovery credentials rather than trusting user-controlled parameters.
Testing Reset Token Predictability
Reset tokens should not be predictable.
From a QA perspective, test that generated tokens do not follow obvious sequences such as:
12345
12346
12347
or other easily guessable patterns.
The actual security implementation should use appropriate cryptographic mechanisms.
QA should not attempt to break cryptographic systems through brute force, but predictable-token behavior should be treated as a serious security finding.
Password Reset Automation Strategy
A strong automated suite should cover the highest-risk scenarios.
A basic automated flow can be:
Create or identify a test account.
Request password reset.
Capture the test recovery email.
Extract the reset URL.
Open the URL in a browser.
Set a valid new password.
Verify successful completion.
Attempt login with the new password.
Attempt login with the old password.
Verify expected session behavior.
Then add negative tests:
Invalid token
Expired token
Used token
Invalid password
Mismatched confirmation
Unauthorized request
Multiple reset requests
Separating Functional and Security Test Suites
Not every password reset test needs to run on every commit.
A practical approach is to divide them.
Fast CI Tests
Run frequently:
Valid reset
Invalid email
Invalid password
Mismatched passwords
Valid login after reset
Old password behavior
Extended Tests
Run regularly:
Token expiration
Token reuse
Multiple reset requests
Role/account-state combinations
Browser variations
Security-Focused Tests
Run according to the team's security testing process:
Account enumeration
Token manipulation
Authorization boundaries
Session invalidation
Rate limiting
Token exposure
Cross-account scenarios
This keeps the main pipeline efficient while maintaining deeper coverage.
How AI Can Improve Password Reset Testing
Password recovery is a good candidate for AI-assisted test design because the workflow contains many combinations.
AI can analyze:
Authentication flows
User roles
Account states
Token states
Password policies
Existing tests
API contracts
Browser workflows
and identify scenarios that may be missing.
AI-Assisted Test Scenario Generation
Instead of asking:
Generate password reset tests.
A stronger instruction is:
Analyze the password recovery workflow and generate test scenarios covering authentication state, token lifecycle, expiration, reuse, multiple reset requests, account enumeration, password policy, session behavior, rate limiting, and error handling.
This produces a more structured test plan.
AI-Assisted Token Lifecycle Analysis
AI can model a token lifecycle:
Generated → Delivered → Opened → Validated → Used → Invalidated
It can then ask:
What happens before expiration?
What happens after expiration?
What happens after use?
What happens if another token is generated?
What happens if the token is modified?
What happens if the browser is refreshed?
This helps QA reason about state transitions rather than individual screens.
AI-Assisted Account-State Testing
AI can generate a matrix involving:
Active account
Unverified account
Locked account
Suspended account
Deleted account
Admin account
Regular account
Combined with:
Valid reset
Invalid reset
Expired token
Multiple reset requests
This can reveal gaps in test coverage.
AI-Assisted Security Scenario Discovery
AI can also review the recovery workflow for potential security boundaries.
For example:
Can a user determine whether an email exists?
Can a previously used token be replayed?
Does password recovery bypass another authentication factor?
Are existing sessions still active after a security-sensitive reset?
These questions can turn a basic functional test suite into a more security-aware QA strategy.
AI should assist with identifying and prioritizing scenarios, while security-sensitive conclusions should still be validated through deterministic tests and appropriate human review.
What QA Should Log During Password Reset Tests
Useful evidence can include:
Request
Timestamp
Account test identifier
Browser/device
Request result
Token
Token state
Expiration state
Whether it was previously used
Reset-request sequence
Do not log raw production recovery tokens.
Email
Delivery status
Link destination
Timestamp
Template version
Reset
Password policy result
Success/failure
Error category
Session
Login result
Existing session behavior
New session creation
This evidence makes failures much easier to diagnose.
Common Password Reset Testing Mistakes
Mistake 1: Testing Only the Happy Path
Many teams test:
Forgot Password → Email → New Password → Login
and stop there.
That misses the highest-risk cases.
Mistake 2: Checking Only the UI
A password rule displayed in the browser does not prove the backend enforces it.
Test the server-side behavior too.
Mistake 3: Ignoring Token Lifecycle
A reset token is effectively a temporary authentication credential.
Its lifecycle deserves dedicated testing.
Mistake 4: Ignoring Account Enumeration
Different responses for valid and invalid accounts can expose user information.
Test both response content and behavior.
Mistake 5: Ignoring Existing Sessions
Changing a password can have implications beyond the next login.
Test what happens to already-authenticated devices.
Mistake 6: Testing Only One Reset Request
Real users may request multiple emails.
Test multiple reset requests and define which tokens remain valid.
Mistake 7: Ignoring Expiration
A reset link that works immediately may still be broken if it continues working after its intended lifetime.
Expiration is a core security scenario.
A Practical Password Reset Testing Workflow
A mature QA team can structure the workflow like this:
Step 1: Map the Recovery Flow
Document:
Forgot Password → Request → Email → Token → Reset → Login
Step 2: Identify Security Boundaries
Define:
Token lifetime
Token reuse policy
Account enumeration behavior
Password policy
Session policy
Rate limiting
MFA behavior
Step 3: Build the Test Matrix
Combine:
Account state
Authentication state
Token state
Password state
Browser state
Step 4: Automate the Core Journey
Automate the happy path first.
Step 5: Add Token Tests
Add:
Expired
Invalid
Modified
Used
Multiple tokens
Step 6: Add Account-State Tests
Add:
Active
Locked
Disabled
Unverified
Deleted
Step 7: Add Security Tests
Cover:
Enumeration
Authorization
Session behavior
Rate limiting
Token exposure
Step 8: Add Browser Coverage
Test supported desktop and mobile browsers.
Step 9: Add Failure Injection
Test email failures, network problems, service failures, and interrupted flows.
Step 10: Review Coverage With Risk
Prioritize scenarios based on:
Account sensitivity
Business impact
User volume
Security risk
Authentication architecture
Password Reset Testing Checklist
Forgot Password
Valid email works.
Invalid email is rejected.
Empty email is handled.
Whitespace is handled correctly.
Email casing behaves as expected.
Existing account behavior is correct.
Unknown account behavior is privacy-preserving.
Email
Reset email is generated.
Correct recipient receives it.
Subject is correct.
Reset URL is correct.
URL points to the correct environment.
Email content is correct.
Expiration information is accurate.
Token
Valid token works.
Invalid token fails.
Modified token fails.
Missing token fails safely.
Expired token fails.
Used token cannot be reused.
Multiple-token behavior is defined.
Token is associated with the correct account.
Password
Valid password works.
Weak password is rejected.
Minimum length is enforced.
Maximum length is enforced.
Password confirmation is validated.
Password history rules are enforced where applicable.
Backend validation matches frontend validation.
Authentication
New password works for login.
Old password behaves correctly.
Existing sessions follow the expected security policy.
MFA behavior is correct.
Device trust behavior is correct.
Security
Account enumeration is controlled.
Reset requests are rate-limited where required.
Tokens cannot be reused.
Tokens cannot be modified successfully.
Unauthorized users cannot reset another account.
Reset does not unintentionally bypass MFA.
Sensitive recovery information is not unnecessarily exposed.
Browser and Device
Desktop browsers work.
Mobile browsers work.
Email-app links work.
Back button behavior is safe.
Multiple-tab behavior is defined.
Refresh behavior is safe.
Error Handling
Expired token has a useful message.
Invalid token has a useful message.
Email failure is handled.
Network failure is handled.
Password update failure is handled.
No sensitive internal information is exposed.
Frequently Asked Questions
What is password reset testing?
Password reset testing verifies that users can securely recover their accounts after forgetting a password. It covers the recovery request, email delivery, reset token, expiration, password validation, authentication, session handling, and security controls.
What are the most important password reset test cases?
Important scenarios include valid reset, invalid email, nonexistent account, expired token, invalid token, token reuse, multiple reset requests, password validation, old-password behavior, session invalidation, account enumeration, and rate limiting.
Why should password reset tokens be tested?
A reset token acts as a temporary recovery credential. QA should verify that it expires correctly, cannot be modified successfully, cannot be reused when the product requires single-use behavior, and cannot be transferred between accounts.
How do you test password reset expiration?
Generate a reset request, obtain the recovery link, wait for or simulate the defined expiration period, and then attempt to use the link. The application should reject the expired token and provide a path to request a new one.
What is account enumeration in password reset?
Account enumeration occurs when an application allows someone to determine whether an email address is registered by observing differences in responses, messages, status codes, or timing.
Should password reset invalidate existing sessions?
The correct behavior depends on the application's security design. QA should verify the documented session policy, especially because a password reset may occur when a user suspects their credentials have been compromised.
Can password reset testing be automated?
Yes. Browser automation can cover the full recovery flow, including requesting a reset, retrieving a test email, opening the reset link, setting a new password, and verifying authentication behavior.
How can AI help with password reset testing?
AI can help generate scenario matrices, identify missing token lifecycle tests, analyze account-state combinations, suggest security scenarios, and compare existing automated coverage with the expected recovery workflow.
Conclusion
Password reset is one of those features that looks small in a product roadmap but carries a surprisingly large testing surface.
The happy path is straightforward:
Forgot Password → Email → Reset → Login
The real QA challenge begins outside that path.
What happens when:
The token expires?
The token is used twice?
Two reset emails are requested?
The email doesn't exist?
The account is locked?
The password is too weak?
The old password is used?
Multiple devices are already logged in?
The reset link is opened in another browser?
The URL is modified?
The recovery service fails?
An attacker tries to discover registered accounts?
Those scenarios are where password recovery quality is actually tested.
A strong password reset strategy therefore treats the feature as an authentication system rather than simply another form.
Test the complete lifecycle:
request → token → delivery → validation → expiration → password change → session handling → login
Then add the security boundaries around it.
AI can help QA teams discover combinations and coverage gaps, but the most important principle remains the same:
Password recovery must be reliable for legitimate users and difficult to abuse for everyone else.
That is what makes password reset testing a core part of modern software quality.