How to Write Test Cases for OTP Verification (With Examples)

How to Write Test Cases for Otp Verification (With Examples) begins with a clear grasp of the OTP flow and ends with a reusable test matrix.

How to Write Test Cases for Otp Verification (With Examples) begins with a clear grasp of the OTP flow and ends with a reusable test matrix.

This guide walks you through every step needed to design high‑signal test cases for one‑time password verification, from flow analysis to traceability, and shows how manual design pairs with autonomous exploration to achieve real coverage.

Understanding OTP Verification Flow

Before writing any test case, map the end‑to‑end process that the system follows when a user requests and validates an OTP. A typical flow includes:

1. Trigger – user clicks “Send OTP” or system initiates verification (e.g., login, password reset, payment).
2. Request Generation – backend creates a random numeric or alphanumeric code, stores it with expiry timestamp and usage limit, and dispatches it via SMS, email, push, or voice.
3. Delivery – the user receives the code through the chosen channel.
4. Input – user enters the code into the UI field.
5. Validation – backend checks code correctness, expiry, and reuse constraints; returns success or failure response.
6. Post‑validation Action – on success, the system proceeds to the protected operation (e.g., grants access, resets password); on failure, it shows an error and may allow retries.

Identify all touchpoints where variations can occur: channel latency, code format, resend limits, brute‑force protection, accessibility of the input field, and handling of expired or already‑used codes.

Why Flow Mapping Matters

A test case that only checks “correct code → success” misses failure modes that appear only when a preceding step behaves unexpectedly. By documenting each step, you can derive preconditions, inputs, and expected results that target specific risks.

Anatomy of a Robust Test Case

A well‑structured test case contains the following elements:

Each element forces you to think about what you are validating and makes the case reusable across manual and automated suites.

Writing Steps That Are Automation‑Friendly

Use imperative language that maps directly to UI actions or API calls. Avoid vague phrasing like “check that the OTP works”. Instead, write:

• “Enter the exact six‑digit code received in the SMS into the OTP input field.”
• “Press the Verify button and observe the HTTP response status 200 with JSON { \"status\": \"success\" }.”

When steps are precise, test engineers can translate them into Appium, Playwright, or Selenium scripts with minimal interpretation.

Positive Test Cases for OTP Verification

Positive cases verify that the system behaves correctly when everything works as intended. Below is a representative set; you can expand based on channel specifics.

These cases cover happy‑path scenarios across channels, input methods, and environmental factors.

Negative Test Cases for OTP Verification

Negative cases ensure the system rejects invalid input and enforces security controls.

These cases test validation, expiry, replay protection, rate limiting, and integrity of the OTP binding to the user identifier.

Edge and Boundary Cases for OTP Verification

Edge cases live at the limits of specifications and often surface only under stress or unusual user behavior.

These cases probe configurability, input sanitization, fallback mechanisms, and race conditions.

Data Setup, Test Environment, and Prioritization

Test Data Management

• Phone numbers / emails: Use a pool of dedicated test numbers that can receive real SMS or use a mock SMS gateway (e.g., Twilio test credentials, MessageBird sandbox).
• Codes: Pre‑generate a set of known codes and store them in a test data repository; alternatively, hook into the OTP generation API to fetch the latest code for a given identifier.
• Timestamps: Control system clock or use a library like timewrap to shift expiry without waiting real time.
• Network conditions: Leverage tools such as tc (Linux traffic control), Network Link Conditioner (macOS), or Android’s adb shell netcfg to simulate latency, packet loss, or bandwidth limits.

Environment Checklist

Prioritization Framework

Apply a simple risk‑based matrix:

Assign each test case a priority based on where it falls. For example:

• OTP‑NEG‑06 (replay attack) → Impact Critical, Likelihood Medium → P1
• OTP‑POS‑07 (autocomplete) → Impact Minor, Likelihood High → P3
• OTP‑EDG‑09 (SMS gateway failure) → Impact Major, Likelihood Low → P3

Prioritization guides execution order in manual runs and helps decide which cases to automate first.

Manual Execution vs Automated Scripts

Manual Testing Strengths

• Exploratory intuition: testers can notice odd UI behavior, misaligned placeholders, or accessibility quirks that scripts miss.
• Ad‑hoc variations: quickly try unconventional input methods (voice, paste from unusual sources).
• Immediate feedback: tester can ask “does this feel right?” and note subjective UX friction.

Automation Strengths

• Repeatability: run the same steps hundreds of times per CI pipeline.
• Speed: a suite of 20 OTP cases executes in under two minutes on a device farm.
• Data‑driven: easily iterate over dozens of phone numbers, code values, and timing scenarios.

Sample Automation Snippets

#### Appium (Java) – Positive SMS OTP

@Test
public void testValidSmtpOtpLogin() {
    // 1. Trigger OTP send
    driver.findElement(By.id("btn_send_otp")).click();
    // 2. Retrieve OTP from mock SMS gateway (REST call)
    String otp = HttpHelper.getOtpFromMockGateway(testUser.getPhone());
    // 3. Enter OTP
    WebElement otpField = driver.findElement(By.id("otp_input"));
    otpField.sendKeys(otp);
    // 4. Verify
    driver.findElement(By.id("btn_verify")).click();
    // 5. Assert landing page
    Assert.assertTrue(driver.findElement(By.id("home_screen")).isDisplayed());
}

#### Playwright (TypeScript – Negative expiry

test('expired OTP is rejected', async ({ page }) => {
  await page.goto('/login');
  await page.click('text=Send OTP');
  // fast‑forward clock 150 s (assuming test helper)
  await page.evaluate(() => { /* mock OTP service to return expired timestamp */ });
  const otp = await getOtpFromMock(page);
  await page.fill('#otp_input', otp);
  await page.click('text=Verify');
  await expect(page.locator('.error')).toHaveText('OTP has expired');
});

#### Bash CLI – Trigger SUSATest Exploration

# Install the agent
pip install susatest-agent
# Run a 5‑minute exploratory session on an Android APK
susatest explore --app ./myapp.apk \
                 --personas curious impatient elderly \
                 --max-duration 5m \
                 --output ./susatest-report.json

The agent will automatically attempt OTP flows, vary input timing, and log any crashes, ANRs, or validation failures it discovers.

Leveraging Autonomous Exploration with SUSATest

While hand‑crafted test cases provide depth, autonomous exploration adds breadth by exercising the app in ways a tester may not anticipate.

How SUSATest Works

1. Ingestion – You supply an APK (Android) or a web URL.
2. Personas – The agent simulates distinct behavior profiles (e.g., impatient users tap rapidly, elderly users linger, adversarial users fuzz inputs).
3. Exploration – It navigates screens, fills fields, handles dialogs, and attempts real user flows such as login, signup, or checkout.
4. Observation – It logs crashes, ANRs, dead buttons, WCAG violations, security hints, and UX friction.
5. Script Generation – From successful paths it auto‑creates regression scripts in Appium (Android) and Playwright (Web).

Integrating SUSATest with OTP Verification

• Pre‑seed – Provide a test phone number that the agent can use; configure a mock OTP service that returns predictable codes.
• Persona‑Specific Variations – The curious persona may try to re‑send OTP many times; the impatient persona may spam the Verify button; the adversarial persona may inject SQL‑like strings into the OTP field.
• Outcome Correlation – After a run, compare the agent’s discovered paths against your manual test matrix. Any path not covered by your cases becomes a candidate for a new test case.

#### Example: Discovering a Race Condition

During an exploratory run, the adversarial persona triggered two OTP requests within 200 ms, received two distinct codes, and attempted to verify the first code in the second session. The agent logged a failure: “OTP verification succeeded despite session mismatch”. This insight led to adding a new test case (OTP‑EDG‑10) to the matrix.

Benefits

• Coverage boost – Autonomous runs often hit edge cases like rapid resend, out‑of‑order verification, or accessibility‑driven input methods that are easy to overlook.
• Regression safety – Auto‑generated scripts become part of your CI pipeline, guarding against future changes that break OTP flow are caught early.
• Learning loop – Each run refines the agent’s model of the app, making subsequent explorations smarter and reducing false positives.

Limitations

• The agent does not replace domain‑specific reasoning; it cannot infer business rules like “OTP must be bound to the exact phone number used for registration”.
• Flaky network simulations rely on the test environment’s ability to throttle traffic accurately.
• For highly regulated environments (e.g., banking), you may need to supplement autonomous data with certified test data sources.

Test Case Traceability and Requirements Mapping

Linking each test case to a requirement ensures that verification effort aligns with product specifications and supports audit trails.

Requirements Example

Traceability Table (excerpt)

Maintain this table in a version‑controlled spreadsheet or a test management tool (e.g., Zephyr, TestRail). When a requirement changes, you can instantly see which test cases need review.

Practical Checklist for OTP Verification Testing

Use this checklist before signing off a release:

• [ ] Flow diagram – OTP request → delivery → input → validation → post‑action is documented.
• [ ] Positive cases – At least one case per delivery channel (SMS, email, push, voice) with correct code, within expiry, single use.
• [ ] Negative cases – Cover invalid format, length, empty field, expired code, replay, rate‑limit, and channel‑specific failures.
• [ ] Edge/boundary cases – Test minimum/maximum OTP length, configurable expiry, resend limits, leading zeros, spaces, voice‑to‑text, and fallback mechanisms.
• [ ] Data setup – Test phone numbers/emails are isolated, mock OTP service is controllable, clock manipulation is available.
• [ ] Automation readiness – Each case has clear, imperative steps; locators are stable; test data is parameterized.
• [ ] Accessibility – Error messages are announced by screen readers; input fields have proper labels; contrast meets WCAG AA.
• [ ] Security – No OTP leakage in logs, URLs, or toast messages; rate limiting and replay protection are enforced.
• [ ] Logging & monitoring – All OTP events (request, success, failure) are written to audit logs with timestamps and user IDs.
• [ ] Regression scripts – Appium (Android) and Playwright (Web) scripts generated from manual cases are stored in version control and run on every CI build.
• [ ] Exploratory validation – Run a SUSATest session with all personas; verify that no new crash, ANR, or unhandled error appears.

If any item is unchecked, investigate and update the test suite before promoting the build.

Takeaways and Next Steps

Writing effective test cases for OTP verification is not merely about checking “correct code → success”. It requires a deep understanding of the entire verification lifecycle, disciplined case anatomy, and a blend of positive, negative, and edge scenarios that reflect real‑world usage and attack vectors.

• Start with a flow diagram – This anchors your test design and prevents gaps.
• Follow the ATDD‑style template (ID, title, preconditions, steps, data, expected result, postconditions, priority, traceability).
• Prioritize using impact/likelihood – Focus early automation on P0/P1 cases that guard core functionality and security.
• Leverage automation for repeatability – Use Appium or Playwright for the bulk of regression, but keep manual exploratory sessions for UX and accessibility validation.
• Integrate autonomous tools like SUSATest – They surface hidden race conditions, resend abuse, and accessibility friction that manual scripts may miss.
• Maintain traceability – Map each test to a requirement; update the matrix whenever the spec evolves.
• Apply the checklist – Treat it as a gate before each release candidate.

By combining carefully crafted test cases with smart, persona‑driven exploration, you achieve both depth and breadth in OTP verification coverage, reducing the risk of production‑facing failures and strengthening user trust in your authentication mechanisms.

---

*End of guide.*