How to Write Test Cases for Forgot Password (With Examples)

How to Write Test Cases for Forgot Password (With Examples)

How to Write Test Cases for Forgot Password (With Examples)

Forgot‑password functionality is a critical gate‑keeper for account recovery, yet it is often under‑tested because the flow appears simple. In reality, a robust test suite must verify that legitimate users can reset their credentials quickly, that malicious actors cannot abuse the mechanism, and that edge‑case inputs do not cause crashes or leak information. This guide walks you through the complete process of designing, prioritizing, and executing test cases for a forgot‑password feature, providing a concrete matrix of 20+ examples, a short checklist, and practical tips for combining manual exploratory testing with automated regression scripts. By the end you will have a ready‑to‑use test‑case template that you can adapt to any web or mobile application.

1. Understanding the Forgot Password Flow

Before writing test cases you need a clear mental model of the typical reset‑password sequence. Most implementations follow these logical steps:

1. User entry – The user supplies an identifier (usually email or username) on a “Forgot password?” page.
2. Validation – The system checks that the identifier matches an existing account and that the account is in a recoverable state (not locked, not marked for deletion).
3. Token generation – A cryptographically‑random, single‑use token is created and stored (often hashed) together with an expiration timestamp.
4. Notification – The token (or a URL containing it) is sent to the user via email, SMS, or an in‑app message.
5. User interaction – The user clicks the link, arrives at a reset‑password page, and enters a new password that satisfies policy rules.
6. Verification – The system validates the token, ensures it has not been used or expired, updates the password hash, invalidates any existing sessions, and confirms success.
7. Post‑reset actions – The user is redirected to a login page or a “password changed” screen, and a security notification is sent.

Each step introduces distinct test concerns: input validation, business logic, cryptographic security, usability, and auditability. Keeping this flow in mind helps you avoid gaps when you enumerate test cases.

1.1 Typical Variations

• Identifier type – Some apps accept email only, others allow username or phone number.
• Delivery channel – Email is common, but SMS, push notifications, or even secure messaging apps may be used.
• Additional verification – Certain systems require answering a security question, entering a CAPTCHA, or confirming via a second factor before sending the token.
• Password reuse rules – The new password may be forbidden from matching the last N passwords or from containing the user’s name.

Understanding which variations apply to your product shapes the set of test cases you will need.

1.2 Security Goals

A forgot‑password flow must satisfy three core security properties:

• Confidentiality – Only the legitimate account holder can obtain the reset token.
• Integrity – An attacker cannot forge or reuse a token to change another user’s password.
• Availability – Legitimate users are not denied service by rate‑limiting or lock‑out mechanisms that are too aggressive.

Your test cases should explicitly target each property.

2. Anatomy of a Test Case

A well‑structured test case makes it easy to review, automate, and trace back to requirements. The following fields are essential:

When you write a test case, fill in every field before execution. Leaving a field blank invites ambiguity and makes later traceability harder.

2.1 Writing Clear Steps

Steps should be imperative, atomic, and free of assumptions. For example:

1. Navigate to https://app.example.com/forgot.
2. Enter alice@example.com into the Email field.
3. Click the Submit button.
4. Wait for the success toast message to appear.

Avoid bundling multiple actions into a single step; otherwise, debugging a failure becomes guesswork.

2.2 Choosing Expected Results

Expected results must be observable and measurable. Instead of “system behaves correctly,” specify:

• “An HTTP 200 response is returned with JSON {“status”:“sent”}.
• “The email inbox of alice@example.com contains a message with subject “Reset your password” and a link matching the pattern https://app.example.com/reset?token=.*.”
• “No error dialog is displayed.”

Concrete expectations enable both manual verification and automated assertions.

3. Positive Test Cases

Positive tests confirm that the happy path works for legitimate users. Below are categories of positive scenarios, each with representative test cases.

3.1 Valid Identifier Submission

3.2 Token Validity and Expiration

3.3 Password Policy Compliance

3.4 User Experience Feedback

These positive cases establish that the core flow works under normal conditions and that the system gives appropriate feedback.

4. Negative Test Cases

Negative tests verify that the system correctly handles invalid or malicious input. They are essential for preventing information leakage, abuse, and denial‑of‑service.

4.1 Invalid or Non‑existent Identifiers

4.2 Rate Limiting and Abuse Protection

4.3 Token Tampering and Replay

4.4 Information Leakage Checks

These negative cases ensure that the system does not aid attackers by revealing whether an address is registered, by allowing token reuse, or by failing to enforce rate limits.

5. Boundary and Edge‑Case Tests

Boundary conditions often expose bugs that slip through happy‑path testing. Test the limits of input length, character sets, and concurrency.

5.1 Input Length Limits

5.2 Character Set and Unicode

5.3 Concurrent Requests and Race Conditions

These boundary cases test validation logic, Unicode handling, and concurrency safeguards that are often missed in scripted tests.

6. Security‑Focused Test Cases

Beyond functional correctness, the forgot‑password flow must resist specific attack vectors. The following cases target common weaknesses.

6.1 Token Entropy and Predictability

6.2 Replay and Man‑in‑the‑Middle Mitigations

6.3 Logging and Alerting

These security tests give you confidence that the mechanism does not become a weak point in your overall authentication strategy.

7. Prioritization and Traceability

A large test suite needs a rational ordering so that the most critical defects are found early, especially when time is limited.

7.1 Risk‑Based Scoring Model

Assign each test case a Risk Score = (Impact × Likelihood). Impact reflects the severity of a failure (e.g., account takeover = 5, UI glitch = 1). Likelihood estimates how often the condition occurs in production (e.g., malformed input = 3, token reuse = 2). Prioritize tests with the highest scores.

Apply this model to the matrix above; you will see that FP‑022, FP‑023, FP‑044, and FP‑047 typically fall into P0.

7.2 Requirements Traceability Matrix (RTM)

Link each test case to the requirement(s) it validates. Below is a simplified RTM showing a few requirements from a typical auth spec.

Maintaining this matrix in a spreadsheet or test‑management tool lets you quickly see which requirements lack coverage and guides test‑case creation when specs evolve.

8. Manual vs. Automated Execution

Both approaches have merit. Manual exploratory testing uncovers usability quirks and unexpected states, while automated regression guards against re‑introducing known defects.

8.1 Manual Exploratory Testing with SUSA

SUSA (the autonomous QA platform) can be pointed at your web or mobile app and will exercise the forgot‑password flow using a variety of user personas—curious, impatient, novice, adversarial, elderly, accessibility‑focused, power user, etc. Each persona follows its own behavior profile, which may reveal issues that scripted tests miss.

Typical workflow:

# Install the agent
pip install susatest-agent

# Point SUSA at a staging URL (web) or provide an APK (Android)
susatest run --url https://staging.example.com \
             --personas curious impatient adversarial \
             --timeout 15m \
             --output report.html

During a run, SUSA will:

1. Locate the “Forgot password?” link (often via text‑match or accessibility label).
2. Attempt to submit various identifiers (valid, invalid, long, special‑char).
3. Follow any email links it discovers (if a test mailbox is configured).
4. Try to reset passwords with weak, strong, and policy‑violating new passwords.
5. Observe UI messages, network responses, and any crashes or ANRs.

Because SUSA learns from each session, subsequent runs become smarter—avoiding previously dead ends and focusing on new avenues. Use its output as a starting point for manual investigation: flag any unexpected behavior, then write a focused test case (or automate it) to cover the gap.

8.2 Scripted Automation (Appium + Playwright)

After you have a solid set of test cases, encode the repetitive ones in code. Below are minimal examples for Android (Appium) and web (Playwright). Adjust selectors and data to match your application.

#### Appium (Java) – Valid Email Reset

@Test
public void testValidEmailTriggersReset() {
    driver.get("https://app.example.com/forgot");
    WebElement email = driver.findElement(By.id("forgotEmail"));
    email.sendKeys("alice@example.com");
    driver.findElement(By.id("submitBtn")).click();

    // Wait for toast
    WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
    WebElement toast = wait.until(ExpectedConditions.visibilityOfElementLocated(By.className("toast-success")));
    assertTrue(toast.getText().contains("Reset link sent"));

    // In a real test you would pull the link from a mailbox API here
}

#### Playwright (TypeScript) – Token Expiration

test('reset link expires after 24h', async ({ page }) => {
  await page.goto('https://app.example.com/forgot');
  await page.fill('#forgotEmail', 'bob@example.com');
  await page.click('#submitBtn');

  // Assume we have a test mailbox that returns the latest link
  const resetLink = await getLatestResetLink('bob@example.com');
  await page.goto(resetLink);

  // Simulate time travel: set system clock ahead via mock API (test‑only)
  await page.route('**/api/set-clock', route => route.fulfill({ json: { offsetHours: 25 } }));
  await page.waitForTimeout(500); // let mock apply

  await page.fill('#newPassword', 'NewPass!23');
  await page.click('#resetBtn');

  const error = await page.locator('.error-message').innerText();
  expect(error).toContain('Link has expired');
});

These snippets illustrate how to automate the most common positive and negative paths. Store test data (emails, passwords) in a secure vault or generate them on‑the‑fly to avoid hard‑coding secrets.

8.3 CI Integration

Add the automated tests to your pipeline so they run on every pull request. A typical GitHub Actions snippet:

name: Forgot Password Regression
on: [pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up Node
        uses: actions/setup-node@v3
        with:
          node-version: '20'
      - name: Install dependencies
        run: npm ci
      - name: Run Playwright tests
        run: npx playwright test --project=chromium
      - name: Upload report
        if: always()
        uses: actions/upload-artifact@v3
        with:
          name: playwright-report
          path: playwright-report/

For mobile, replace the Playwright step with an Appium execution using a Docker image that contains the Android emulator and the Appium server.

Combining SUSA’s exploratory runs (perhaps nightly) with the CI‑gated automated suite gives you both breadth and depth.

9. Worked Test Matrix (20+ Cases)

Below is a consolidated table that you can copy into your test‑management tool. It includes ID, short title, preconditions, steps, and expected result. Feel free to extend it with your own project‑specific variations.