QA interview guide

How would you test password reset?

Password reset is a security-sensitive recovery flow. A good interview answer shows that you can protect users while keeping the flow usable when emails, links, tokens, or sessions fail.

Practice this scenarioBrowse all questions

Write your own answer and compare it with senior QA coverage.

What interviewers expect

What interviewers expect

Interviewers expect token lifecycle coverage, generic responses for unknown emails, email delivery handling, password validation, session invalidation, rate limiting, and edge cases like repeated requests or old links.

Checklist

Checklist

Use these practical prompts to build a complete answer. Strong interview responses usually include functional behavior, negative cases, security, backend/data risks, UX, accessibility, and reliability.

Functional checks

  • Existing users can request a reset email and reach the reset form from the latest valid link.
  • Unknown emails get a generic success response without revealing account existence.
  • New password and confirm password are validated together.
  • After reset, the new password works and the old password no longer works.

Negative and recovery cases

  • Expired, reused, invalid, malformed, and old tokens are rejected.
  • Multiple reset requests invalidate older links if required.
  • Network failures during request or submit show recoverable messages.
  • Email provider delay, queue failure, and backend 500 states are handled.

Security and backend risks

  • Tokens are random, single-use, scoped to the correct user, and not logged or leaked.
  • Rate limiting protects per email and per IP without enabling enumeration.
  • Existing sessions, refresh tokens, and remember-me sessions are invalidated when required.
  • CSRF, XSS, open redirect, HTTPS, noindex, and cache safety are checked.

UX, accessibility, and reliability

  • Email instructions are clear without exposing whether the account exists.
  • Password rules, mismatch errors, labels, focus states, and screen reader errors work.
  • Double-click submit and concurrent token use do not create inconsistent state.

Complete interview coverage checklist

Aim to mention 20-40 concrete checks. This expanded list helps you turn a short answer into a structured senior-style response.

Existing users can request a reset email and reach the reset form from the latest valid link.
Unknown emails get a generic success response without revealing account existence.
New password and confirm password are validated together.
After reset, the new password works and the old password no longer works.
Expired, reused, invalid, malformed, and old tokens are rejected.
Multiple reset requests invalidate older links if required.
Network failures during request or submit show recoverable messages.
Email provider delay, queue failure, and backend 500 states are handled.
Tokens are random, single-use, scoped to the correct user, and not logged or leaked.
Rate limiting protects per email and per IP without enabling enumeration.
Existing sessions, refresh tokens, and remember-me sessions are invalidated when required.
CSRF, XSS, open redirect, HTTPS, noindex, and cache safety are checked.
Email instructions are clear without exposing whether the account exists.
Password rules, mismatch errors, labels, focus states, and screen reader errors work.
Double-click submit and concurrent token use do not create inconsistent state.
Structure your answer: Start with reset request, email delivery, reset link, password change, and login with the new password.
Structure your answer: Add token cases: expired, reused, invalid, old token after new request, and token for wrong user.
Structure your answer: Add security: generic response, rate limiting, token leakage, session invalidation, CSRF, XSS, and open redirects.
Structure your answer: Add reliability and UX: provider delay, backend errors, clear messages, accessibility, and mobile behavior.
Do not miss: Unknown email enumeration risk.
Do not miss: Old reset email after a newer reset request.
Do not miss: Session and refresh token invalidation.
Do not miss: Email scanner or link preview behavior.

Ready to practice?

Practice this scenario interactively

Write your own answer and compare it with senior QA coverage.

Practice this scenario

Answer structure

Strong answer structure

  1. Start with reset request, email delivery, reset link, password change, and login with the new password.
  2. Add token cases: expired, reused, invalid, old token after new request, and token for wrong user.
  3. Add security: generic response, rate limiting, token leakage, session invalidation, CSRF, XSS, and open redirects.
  4. Add reliability and UX: provider delay, backend errors, clear messages, accessibility, and mobile behavior.

Common missed areas

Common missed risks

Unknown email enumeration risk.
Old reset email after a newer reset request.
Session and refresh token invalidation.
Email scanner or link preview behavior.

Answer template

Use this interview answer template

I would start with the reset request and email delivery, then cover token expiry, one-time use, old links after a new request, password validation, session invalidation, rate limiting, user enumeration, email provider failures, UX, accessibility, and backend reliability.

Use it as a structure, then replace the examples with specific checks for the feature you are discussing.

Common weak answer

“I would test valid and invalid cases.”

This is too generic because it does not show risk thinking. A stronger answer names the happy path, negative cases, security risks, backend/data behavior, UX/accessibility, and reliability concerns that matter for this exact scenario.

Examples

Weak answer vs stronger answer

Weak answer
“I would test reset email and expired link.”

This mentions two important checks, but misses token lifecycle depth, unknown email behavior, session invalidation, abuse prevention, backend failures, and accessibility.

Stronger answer
“I would test reset request for existing and unknown emails, generic success messages, email delivery, latest reset link, expired, invalid, reused, and old tokens, token ownership, weak password rejection, password mismatch, old password no longer working, new password working, existing sessions invalidated, refresh tokens revoked, rate limiting per email and IP, mailbox flooding prevention, CSRF and XSS protection, open redirect blocking, backend errors, email provider delays, double-click submit, keyboard navigation, labels, focus states, and screen reader errors.”

FAQ

Frequently asked questions

What should I mention first when answering "How would you test password reset?"

Start with reset request, email delivery, reset link, password change, and login with the new password.

Should I include negative and edge cases?

Expired, reused, invalid, malformed, and old tokens are rejected. Multiple reset requests invalidate older links if required.

Should I include security, API, or backend risks?

Tokens are random, single-use, scoped to the correct user, and not logged or leaked. Rate limiting protects per email and per IP without enabling enumeration.

What are common missed risks?

Unknown email enumeration risk. Old reset email after a newer reset request. Session and refresh token invalidation. Email scanner or link preview behavior.

How can I practice this answer?

Use the interactive how would you test password reset? challenge to write your own answer, get checklist-based feedback, and compare your coverage with stronger QA thinking.

Practice

Practice this scenario interactively

Write your own answer and compare it with senior QA coverage.

Practice this scenario