Forgot Password Testing Checklist (2026)
Forgot Password Testing Checklist (2026)
Forgot Password Testing Checklist (2026)
A comprehensive, actionable matrix for validating the password‑reset flow in modern applications
---
Forgot Password Testing Checklist (2026) – Overview
The Forgot Password Testing Checklist (2026) gives you a single source of truth for exercising every observable behavior of a password‑reset feature, from the moment a user clicks “Forgot password?” to the point they successfully set a new credential. Treat this list as a living contract: each item maps to a pass/fail criterion, a concrete example, and guidance on how to automate it. By the end of this guide you will be able to copy the tables into your test‑management tool, extend them with product‑specific variations, and see how an autonomous explorer such as SUSA can hit the majority of these checks in one unattended run.
---
Happy Path Test Cases
| ID | Description | Preconditions | Steps | Expected Result | Pass/Fail Criteria |
|---|---|---|---|---|---|
| HP‑1 | User initiates reset via email link | Registered email address on file | 1. Navigate to login screen 2. Tap “Forgot password?” 3. Enter valid email 4. Submit 5. Open email inbox 6. Click reset link 7. Enter new password (meets policy) 8. Confirm password 9. Submit | System shows “Password updated successfully” and redirects to login page | ✅ If success message appears and user can log in with new password |
| HP‑2 | User initiates reset via SMS OTP | Verified phone number on account | Same as HP‑1 but choose “Send code via SMS”, enter OTP, then set new password | Same as HP‑1 | ✅ Same criteria |
| HP‑3 | Reset link expires after configured window | Email sent at T0 | Wait until link expiry (e.g., 24 h) then click link | System shows “Link expired or invalid” and offers to resend | ✅ Message appears, no password change allowed |
| HP‑4 | Resend functionality works | Email sent, user did not receive | Click “Resend link” on the reset page | New email arrives within expected SLA (≤ 30 s) | ✅ New email received, old link still valid until new one used |
| HP‑5 | Password policy enforcement during reset | Policy: min 12 chars, 1 upper, 1 lower, 1 digit, 1 symbol | Enter password that satisfies all rules | Acceptance | ✅ Password accepted |
| HP‑6 | Password policy rejection during reset | Same policy | Enter password missing a required class | Inline error indicating missing rule | ✅ Error shown, form not submitted |
Why happy‑path matters: It establishes the baseline that the core flow works for the majority of users. Any deviation here blocks downstream scenarios such as error handling or security checks.
---
Error Handling and Validation
| ID | Description | Trigger | Expected UI/UX | Pass/Fail |
|---|---|---|---|---|
| EH‑1 | Empty email field | Submit with blank email | Inline error: “Email address is required” | ✅ Error appears, form stays on page |
| EH‑2 | Malformed email | “user@” or “user@domain” | Inline error: “Please enter a valid email address” | ✅ Same |
| EH‑3 | Non‑registered email | “unknown@example.com” | General message: “If this email exists, we’ve sent a reset link” (no user enumeration) | ✅ Generic message, no indication of existence |
| EH‑4 | Rate‑limit on request submission | Submit > 5 times in 30 s | Toast: “Too many attempts, please wait 2 min” | ✅ Throttling enforced |
| EH‑5 | Invalid OTP length | Enter 3‑digit code when 6 expected | Inline error: “Code must be 6 digits” | ✅ Error shown |
| EH‑6 | OTP expired | Wait > 5 min after SMS sent, then submit | Message: “Code has expired, request a new one” | ✅ Correct messaging |
| EH‑7 | Token tampering | Modify reset link token (e.g., flip a bit) and submit | System rejects with “Invalid or expired token” | ✅ No password change |
| EH‑8 | Concurrent reset attempts | User A and B request reset for same account almost simultaneously | Only the latest token is valid; earlier token yields error | ✅ No race‑condition allowing both to succeed |
| EH‑9 | Password mismatch | New password and confirmation differ | Inline error: “Passwords do not match” | ✅ Form blocked |
| EH‑10 | Password too short/long | 5‑char password or 200‑char password | Policy violation message | ✅ Message reflects limits |
Implementation tip: Use a data‑driven test harness (e.g., TestNG + CSV) to iterate over the above triggers, asserting both UI text and HTTP response codes (where applicable).
---
Edge and Boundary Cases
| ID | Scenario | Boundary Value | Expected Outcome |
|---|---|---|---|
| EB‑1 | Email length limit | 254 chars (RFC 5321 max) | Accepted if system allows; otherwise error with clear limit |
| EB‑2 | Email length overflow | 255 chars | Rejected with “Email too long” |
| EB‑3 | Phone number international format | +1‑555‑123‑4567 (E.164) | Accepted if SMS gateway supports |
| EB‑4 | Phone number with leading zeros | 0015551234567 | Treated as invalid or normalized; check consistency |
| EB‑5 | Unicode in email (e.g., 用户@例子.中国) | UTF‑8 local part/domain | Accepted if IDN supported; otherwise punycode conversion visible |
| EB‑6 | Very long password (policy max) | 128 chars (if policy allows) | Accepted; verify hash storage length |
| EB‑7 | Password with only spaces | “ ” | Rejected as per policy (usually requires non‑space) |
| EB‑8 | Simultaneous email and SMS request | Choose both channels (if UI permits) | System sends both; each token works independently |
| EB‑9 | Reset after account lockout | Account locked due to failed logins | Reset still allowed (decoupled from auth) – verify |
| EB‑10 | Reset after password change within short window | Change password, then immediately request reset | New reset token invalidates previous session; old token fails |
| EB‑11 | Reset link clicked from insecure client (e.g., outdated browser) | TLS 1.0 only | Server should reject connection or force upgrade; client shows appropriate error |
| EB‑12 | Reset link clicked from email client that strips tracking parameters | Link missing utm_* | Core token still present; system works |
| EB‑13 | Reset request from VPN with IP‑geo mismatch | Login from US, reset from EU | No geo‑blocking on reset (unless policy says otherwise) |
| EB‑14 | Reset after account deletion request in progress | Account marked for deletion, not yet purged | System returns “Account not found” generic message (no leakage) |
| EB‑15 | Reset with disabled JavaScript | User has JS turned off | Fallback to server‑side form works (progressive enhancement) |
Testing approach: Combine manual exploratory steps with automated scripts that inject boundary values via API (if exposed) or via Selenium/Appium field manipulation.
---
Accessibility (WCAG) Considerations
| WCAG Guideline | Test Item | How to Verify | Pass Criteria |
|---|---|---|---|
| 1.1.1 Non‑text Content | All icons (e.g., eye‑toggle for password visibility) have accessible names | Inspect ARIA‑label or alt text | ✅ Each icon conveys purpose |
| 1.3.1 Info and Relationships | Form fields are correctly labelled (aria-labelledby) | Use axe or manual inspection | ✅ No orphaned inputs |
| 1.4.3 Contrast (Minimum) | Text vs. background contrast ≥ 4.5:1 | Run contrast analyzer | ✅ All foreground/background pairs pass |
| 1.4.4 Resize Text | UI scales to 200% without loss of content or functionality | Zoom browser 200% | ✅ No overlap, all controls reachable |
| 2.1.1 Keyboard | All interactive elements reachable via Tab; no keyboard traps | Navigate with Tab only | ✅ Logical order, escape closes dialogs |
| 2.4.7 Focus Visible | Visible focus outline on interactive elements | Tab through, observe outline | ✅ Outline present, ≥ 2 px solid |
| 2.5.1 Pointer Gestures | No reliance on complex gestures (e.g., multi‑touch swipe) for reset | Test with mouse and single tap | ✅ Simple click suffices |
| 2.5.3 Label in Name | VoiceOver/TalkBack reads the purpose of buttons (e.g., “Send reset link”) | Run screen‑reader, listen | ✅ Label matches visible text |
| 3.2.1 On Focus | Changing focus does not initiate unexpected context change (e.g., auto‑submit) | Focus each field, watch for auto‑submit | ✅ No auto‑submit on focus |
| 3.3.2 Labels or Instructions | Instructions for password policy are perceivable | Check for helper text or aria‑describedby | ✅ Policy visible or announced |
| 4.1.2 Name, Role, Value | Custom widgets (e.g., password strength meter) expose correct role/value | Inspect accessibility tree | ✅ Role = slider or progressbar, value announced |
Automated check: Run axe‑core or Google’s Accessibility Test Suite as part of CI; treat any violation as a blocker for the forgot‑password feature.
---
Security and Privacy Checks
| ID | Check | Method | Expected Result |
|---|---|---|---|
| SEC‑1 | Token entropy | Inspect reset link: should be ≥ 128‑bit random, base64url | ✅ High entropy, no predictable pattern |
| SEC‑2 | Token expiration | Request link, wait past TTL, attempt use | ✅ Link rejected |
| SEC‑3 | Token reuse | Use same token twice | ✅ Second use rejected |
| SEC‑4 | Rate limiting on token validation | Send 20 rapid validation requests with same token | ✅ After threshold, HTTP 429 or temporary lock |
| SEC‑5 | No password leakage in logs/APIs | Attempt to reset with a known password, capture network traffic, search logs | ✅ Password never appears in URL, headers, or response bodies |
| SEC‑6 | Secure transport | Verify all reset‑related endpoints enforce HTTPS (TLS 1.2+) | ✅ No HTTP fallback |
| SEC‑7 | Account enumeration resistance | Compare responses for existing vs. non‑existing email (timing, message) | ✅ Identical generic message, timing variance < 20 ms |
| SEC‑8 | Password policy enforced server‑side | Try to set password via API directly bypassing UI, violating policy | ✅ Server rejects with 400 and policy message |
| SEC‑9 | Salted hash storage | After reset, retrieve hash from DB (if accessible) and verify unique salt per user | ✅ Different salts for different users |
| SEC‑10 | Protection against brute‑force on OTP | Fail OTP 10 times, observe lockout or exponential back‑off | ✅ Account not locked, but OTP validation throttled |
| SEC‑11 | Privacy‑by‑design: minimal data in reset email | Email contains only link, no user‑ID or email in plain text | ✅ No PII beyond the address itself |
| SEC‑12 | CSP headers on reset page | Inspect response headers for Content‑Security‑Policy | ✅ Prevents inline script injection |
| SEC‑13 | SameSite cookie on reset session | Cookie set with SameSite=Strict or Lax | ✅ Mitigates CSRF |
| SEC‑14 | Logging of reset events for audit | Verify that each request logs timestamp, IP, user‑id (hashed) and outcome | ✅ Logs available for SIEM |
| SEC‑15 | Test for token leakage via Referer header | Click reset link from third‑party site, check if token appears in Referer | ✅ Token stripped or not sent due to referrerpolicy=no-referrer |
Tooling tip: Use OWASP ZAP or Burp Suite to automate SEC‑suite to scan for missing headers, token predictability, and information leakage.
---
Performance and Load Testing
| Scenario | Load Profile | Metrics to Capture | Acceptance Threshold | ||||
|---|---|---|---|---|---|---|---|
| PL‑1 | Single user reset (baseline) | End‑to‑end latency (request → password change confirmation) | ≤ 2 s on typical 3G/4G | ||||
| PL‑2 | Burst of 50 reset requests within 5 s | 95th‑percentile latency, error rate | ≤ 3 s latency increase >0 | --- | ---------- | -------------------- | ---------------------- |
| PL‑3 | Sustained 10 req/s for 5 min | Average latency, CPU/Memory on auth service | ≤ 2.5 s latency, < 70 % CPU, < 80 % RAM | ||||
| PL‑4 | Spike: 500 req/s for 30 s (simulating credential‑stuffing attack) | Rate‑limit triggers, HTTP 429 rate, system stability | ≥ 90 % of requests receive 429 after threshold, no crash | ||||
| PL‑5 | Reset via SMS gateway simulation (mock latency 800 ms) | End‑to‑end latency, queue depth | ≤ 4 s total, queue does not grow unbounded | ||||
| PL‑6 | Mobile client on low‑end device (CPU ≈ 500 MHz, RAM ≈ 512 MB) | UI render time, battery impact (via Android Profiler) | UI responsive (< 16 ms per frame), battery drain < 5 % per 10 resets |
Execution: Use k6 or Gatling for server‑side load, and Appium/Espresso for client‑side performance profiling. Include network throttling (e.g., Chrome DevTools → Network → Slow 3G) to emulate real‑world conditions.
---
Release Readiness and Regression
| Checklist Item | Description | Evidence Required |
|---|---|---|
| RR‑1 | Test coverage matrix updated | Link to test‑case repository showing all IDs from above mapped to automated scripts |
| RR‑2 | CI pipeline gate | Pipeline fails if any Forgot Password test returns FAIL |
| RR‑3 | Canary validation | Deploy to 5 % users, monitor reset success rate > 99.5 % and no increase in error logs |
| RR‑4 | Rollback plan documented | Run‑book with steps to revert auth service version and DB schema if needed |
| RR‑5 | Security sign‑off | Pen‑test report shows no critical findings in reset flow |
| RR‑6 | Performance baseline stored | Store latest k6 report as artifact; new build must not exceed baseline by > 10 % |
| RR‑7 | Accessibility audit passed | Axe report shows zero violations (WCAG 2.1 AA) |
| RR‑8 | Documentation updated | User‑help article and API spec reflect any changes to reset endpoint or token format |
| RR‑9 | Backward compatibility verified | Older client versions (n‑2) still able to consume reset links (no breaking changes) |
| RR‑10 | Feature flag toggle tested | Ability to disable reset flow via flag without breaking login or other flows |
Regression strategy: Keep a dedicated “forgot‑password” test suite that runs on every PR. Use contract testing (Pact) to ensure the API contract (request/response shape, status codes) stays stable.
---
How Autonomous Exploration (SUSA) Covers This Checklist
SUSA’s agent‑based testing model can exercise a large portion of the Forgot Password Testing Checklist (2026) without hand‑crafted scripts. When you point SUSA at your application (APK or web URL) and enable the “auth‑reset” persona set, the platform performs the following:
- Persona‑driven navigation – The curious and power‑user personas systematically explore every link and button labeled “Forgot password”, “Reset via email”, or “Send OTP”. This hits HP‑1, HP‑2, and the resend flow (HP‑4) automatically.
- Input fuzzing – For each discovered field, SUSA injects boundary values from its built‑in data‑set (empty strings, max‑length emails, Unicode, SQL‑style payloads). This covers EB‑1 through EB‑6, EH‑1 through EH‑10, and many SEC checks (token entropy, injection attempts).
- State‑machine tracking – The agent records the exact sequence of screens visited, tokens observed, and timestamps. When it encounters a reset link, it validates expiration, reuse, and rate‑limit behavior (SEC‑1, SEC‑2, SEC‑3, SEC‑4) by replaying the link with varied delays.
- Accessibility probing – Using integrated axe‑core, SUSA evaluates contrast, labels, and keyboard focus on every rendered reset page, satisfying WCAG items 1.1.1, 1.3.1, 1.4.3, 2.1.1, 2.4.7, and 3.3.2.
- Security header inspection – Each HTTP response is scanned for CSP, HSTS, SameSite, and Referrer‑Policy headers, fulfilling SEC‑12 through SEC‑15.
- Performance telemetry – SUSA measures time‑to‑interaction and time‑to‑completion for the reset flow under simulated 3G throttling, providing data comparable to PL‑1 and PL‑2.
- Logging and reporting – At the end of a run, SUSA emits a JSON report that maps each observed behavior to a checklist ID, marking PASS/FAIL based on heuristics (e.g., token entropy > 100 bits, error messages generic).
While SUSA excels at surface‑level validation, certain deep‑logic checks (e.g., server‑side password hash salting, back‑end rate‑limit algorithms, or specific cryptographic implementations) still require targeted unit or integration tests. Therefore, treat the autonomous run as a first‑line gate that catches the majority of regressions, freeing your team to focus manual effort on the higher‑risk items listed in the Security and Privacy and Release Readiness sections.
---
Quick Reference Checklist (Markdown Table)
You can copy this directly into your test‑management tool or a shared wiki.
| Area | ID | Title | Pass Criteria | Automation Hint | |
|---|---|---|---|---|---|
| Happy Path | HP‑1 | Email‑based reset success | Success message + new password login works | Playwright: fill email → click link → set password | |
| Happy Path | HP‑2 | SMS‑based reset success | Same as HP‑1 but via OTP | Appium: request OTP → fill code → set password | |
| Error Handling | EH‑1 | Empty email field | Inline “required” error | Selenium: assert visibility of error | |
| Error Handling | EH‑3 | Non‑registered email | Generic message, no enumeration | API: assert same response body for existent/non‑existent | |
| Edge Cases | EB‑1 | Max‑length email (254) | Accepted or clear limit error | Data‑driven test with 254‑char string | |
| Edge Cases | EB‑7 | Password only spaces | Rejected per policy | UI: attempt submit, assert error | |
| Accessibility | 1.1.1 | Icon has accessible name | ARIA‑label or alt present | Axe: run on reset page | |
| Accessibility | 2.1.1 | Tab order logical | No traps, all fields reachable | Keyboard navigation script | |
| Security | SEC‑1 | Token entropy ≥ 128‑bit | High randomness, base64url | Decode token, measure bits | |
| Security | SEC‑7 | No account enumeration | Identical messages/timing | Measure response time diff < 20 ms | |
| Security | SEC‑12 | CSP header present | Blocks inline script | curl -I response header check | |
| Performance | PL‑1 | Single‑user latency ≤ 2 s | End‑to‑end timer | k6 script with one VU | |
| Performance | PL‑4 | Spike → 429 after threshold | ≥ 90 % 429, no crash | k6 ramp‑up to 500 req/s | |
| Release | RR‑1 | Test coverage matrix updated | All IDs mapped | Link to test repo | CI badge |
| Release | RR‑6 | Performance baseline not degraded > 10 % | Compare latest k6 report to stored | Store as artifact, fail on regression |
---
Closing Takeaways
A solid forgot‑password flow is more than a “nice‑to‑have” convenience; it is a gatekeeper for account recovery, a potential vector for credential‑stuffing, and a frequent source of user frustration when poorly implemented. By treating the Forgot Password Testing Checklist (2026) as a contract—complete with pass criteria, realistic examples, and automation hints—you give your team a repeatable, verifiable way to guard against regressions, security slips, and accessibility gaps.
Leverage autonomous explorers like SUSA for broad coverage, but complement them with focused unit, integration, and performance tests that validate the cryptographic guarantees, rate‑limit logic, and server‑side side‑effects that lie beneath the UI. Keep the checklist alive: whenever you add a new reset channel (e.g., magic link via push notification) or adjust policy (e.g., increase minimum length), add the corresponding rows, update the automation, and let the CI gate enforce quality.
When the reset flow passes every item on this list, you can ship with confidence that users will regain access safely, quickly, and without barriers—exactly the experience a modern authentication system should deliver.
---
*End of article.*
Test Your App Autonomously
Upload your APK or URL. SUSA explores like 10 real users — finds bugs, accessibility violations, and security issues. No scripts.
Try SUSA Free