QA interview guide

How would you test a password reset flow?

Password reset is an account recovery feature and a security boundary. A strong answer proves that legitimate users can recover access while attackers cannot abuse reset links, tokens, or account information.

What interviewers expect

Interviewers look for a complete recovery lifecycle: request reset, receive email, open tokenized link, set a new password, invalidate risky sessions, handle stale links, and keep responses safe from enumeration.

Checklist

What to include in your answer

Functional

  • Existing user can request a reset email.
  • Reset email reaches the correct mailbox and opens the reset page.
  • New valid password is accepted and old password no longer works.
  • Successful reset redirects or confirms according to requirements.

Token handling

  • Expired, reused, invalid, missing, and malformed tokens are rejected.
  • Tokens are single-use, time-limited, and bound to the correct account.
  • Old reset email after a newer request follows defined rules.

Security

  • Unknown email receives a generic response.
  • Reset requests are rate limited.
  • Reset tokens and new passwords are not leaked in logs, URLs, analytics, or referrers.

Edge cases and recovery

  • Multiple reset requests, cross-device links, changed email, deleted account, and locked account states are handled.
  • Network failure, backend 500, and email provider delay show recoverable states.
  • Existing sessions, refresh tokens, or remember-me sessions are invalidated when required.

UX and accessibility

  • Errors explain what to do next without exposing account existence.
  • Keyboard navigation, labels, focus states, and screen reader errors work.
  • Mobile email clients and mobile reset form remain usable.
Weak answer
existing email, expired token, weak password

What it misses

This mentions useful cases, but it misses generic responses, multiple reset requests, stale links, session invalidation, email delivery failures, backend errors, and accessibility.

Stronger senior-style answer
I would test known and unknown email requests with generic responses, reset email delivery, link expiry, single-use tokens, reused and invalid tokens, weak and mismatched passwords, old password rejection, session and refresh-token invalidation, rate limiting, token leakage, multiple reset requests, stale links, cross-device use, locked/deleted accounts, network and email-provider failures, audit events, clear recovery messages, keyboard navigation, labels, focus states, and screen reader error announcements.