How to Write Test Cases for Two-Factor Authentication (With Examples)

How to Write Test Cases for Two-Factor Authentication (With Examples)

How to Write Test Cases for Two-Factor Authentication (With Examples)

Two‑factor authentication (2FA) adds a second verification step beyond a password, and testing it requires a disciplined approach that covers the happy path, error conditions, timing quirks, and integration points. This guide walks you through the anatomy of a useful test case, shows how to derive positive, negative, and edge‑case scenarios, provides a ready‑to‑use matrix of more than twenty concrete examples, explains how to prepare test data, prioritize effort, and trace each case back to requirements. It also illustrates how manual test design works together with autonomous exploration (e.g., SUSA) to achieve real‑world coverage without maintaining large script suites.

Understanding Two‑Factor Authentication – Core Concepts for Testers

Before writing test cases you need a clear mental model of how 2FA works in the target application. Most implementations follow the pattern: the user enters a primary credential (usually a password), the system validates it, then challenges the user for a second factor. The second factor can be something the user possesses (a phone, a hardware token), something the user is (biometrics), or something the user knows (a PIN). In the answer to a secret question). In practice the most common second factors are:

• SMS‑based one‑time passcode (OTP) – a numeric code sent via a telecom gateway.
• Time‑based One‑Time Password (TOTP) – a 6‑digit code derived from a shared secret and the current Unix time, typically shown in an authenticator app (Google Authenticator, Authy, etc.).
• Push notification – the server sends a push to a registered device; the user approves or denies.
• Email OTP – similar to SMS but delivered via SMTP.
• Hardware token – a USB or NFC device that performs a cryptographic challenge‑response (e.g., YubiKey).

Each factor introduces distinct failure modes: network latency for SMS, clock drift for TOTP, device‑token binding issues for push, spam‑filter delays for email, and physical tampering for hardware. Knowing these helps you anticipate where bugs hide and what data you need to simulate or mock.

Types of 2FA Factors – What to Test

Understanding these rows lets you map each test case to a specific factor and its associated risk.

Anatomy of a Test Case for 2FA

A well‑structured test case contains the following fields, each serving a clear purpose during execution, review, and automation:

• Test Case ID – a unique, immutable identifier (e.g., 2FA-001).
• Title – a short, readable summary (e.g., “Valid SMS OTP leads to successful login”).
• Preconditions – the state that must exist before the first step (e.g., “User is registered, phone number verified, SMS gateway mocked”).
• Test Data – any variables needed (phone number, secret key, OTP length).
• Steps – an ordered list of actions the tester or automation performs.
• Expected Result – the observable outcome after the last step (e.g., “User is redirected to dashboard, session cookie set”).
• Postconditions – state left after the test (e.g., “Session active, no error logs”).
• Priority – often mapped to a risk‑based scale (P1‑critical, P2‑high, P3‑medium).
• Requirement Trace – link to the user story or specification item (e.g., US-1234: Enable SMS 2FA).

When you write a test case, keep each field concise but complete enough that another engineer can execute it without guessing. Avoid vague phrasing like “check that the code works”; instead state the exact value or condition you verify.

Example Test Case (Manual)

This layout works equally well for automated scripts; the steps become function calls, and the expected result becomes an assertion.

Positive Test Cases – Happy Path Scenarios

Positive cases confirm that the system behaves correctly when everything is supplied as intended. Below is a table of eight representative happy‑path tests covering the five common factors. Feel free to copy‑paste into your test management tool and adjust IDs to match your numbering scheme.

These cases give you confidence that the nominal flow works for each factor and that auxiliary mechanisms (backup codes, resend, tolerance) are correctly implemented.

Negative Test Cases – Invalid Inputs and Failure Modes

Negative testing proves that the system correctly rejects malformed or missing data and that it gives useful feedback. The following table lists eight negative scenarios, again covering each factor.

These cases ensure that error handling is present, that users are guided toward recovery, and that security checks (e.g., replay prevention, rate limiting) are enforced.

Edge and Boundary Cases – Timing, Retry Limits, Clock Drift, etc.

Edge cases often slip through because they involve timing, concurrency, or unusual states that are rare in manual testing but common in production. The table below captures six such scenarios.

These edge cases test the limits of time windows, replay protection, concurrency handling, and environmental changes that can affect 2FA reliability.

Data Setup and Test Environment Preparation

Reliable 2FA testing hinges on controllable test data. You must be able to generate or mock OTPs, simulate SMS/email delivery, and control device states without relying on real carriers or third‑party services that introduce flakiness.

Generating TOTP Secrets and Codes

A common approach is to use the pyotp library (Python) or its equivalents in other languages. Below is a short script that creates a base32 secret, prints the provisioning URI for QR‑code scanning, and outputs the current and future TOTP values.

import pyotp
import time

# Generate a random secret (store this securely in your test vault)
secret = pyotp.random_base32()
print(f"Secret: {secret}")

# Provisioning URI for authenticator apps (replace with your app name)
uri = pyotp.totp.TOTP(secret).provisioning_uri(name="testuser@example.com",
                                                issuer_name="MyApp")
print(f"Provisioning URI: {uri}")

# Show current and next codes (useful for edge‑case timing)
totp = pyotp.totp.TOTP(secret)
print(f"Now: {totp.now()}")
print(f"In 10s: {totp.at(int(time.time()) + 10)}")

You can persist the secret in a test data file (JSON/YAML) and load it for each test run. For automated suites, wrap the above in a fixture that creates a fresh user account, stores the secret, and tears it down after the test.

Mocking SMS and Email Gateways

Instead of paying for real SMS, use a mock HTTP endpoint that returns a predetermined OTP. Many teams employ tools like MockServer, WireMock, or a simple Express server. Below is a Node.js/Express snippet that mimics an SMS provider:

const express = require('express');
const app = express();
const port = 3000;

// In‑memory store for the latest OTP per phone number
const otpStore = new Map();

app.post('/sms/send', express.json(), (req, res) => {
  const { to } = req.body; // expect E.164 format
  const code = Math.floor(100000 + Math.random() * 900000).toString();
  otpStore.set(to, code);
  // Simulate network delay
  setTimeout(() => res.json({ status: 'queued', messageId: 'mock-123' }), 200);
});

app.get('/sms/verify', (req, res) => {
  const { to, code } = req.query;
  const stored = otpStore.get(to);
  if (stored && stored === code) {
    otpStore.delete(to); // consume OTP
    return res.json({ status: 'verified' });
  }
  res.status(400).json({ status: 'failed', reason: 'invalid_code' });
});

app.listen(port, () => console.log(`Mock SMS listening on :${port}`));

Point your application’s SMS gateway configuration to http://localhost:3000/sms/send for sending and http://localhost:3000/sms/verify for verification. Adjust the logic to simulate latency, failure rates, or rate‑limit responses as needed.

Email mocks can be built similarly using a fake SMTP server (e.g., smtp4dev) or an HTTP endpoint that returns the OTP when queried.

Controlling Device Time for TOTP Drift Tests

When you need to simulate clock skew, you can adjust the system clock in a containerized test or use a library that allows you to inject a custom time source. In Java with JUnit 5, you can use @ExtendWith(MockitoExtension.class) and mock java.time.Clock:

@Test
void totpFailsWhenClockIsAhead() {
    Clock fixedClock = Clock.offset(Clock.systemUTC(), Duration.ofSeconds(45));
    TOTPGenerator generator = new TOTPGenerator(secret, fixedClock);
    String code = generator.generate();
    assertFalse(authService.validateCode(code), "Code should be rejected due to drift");
}

For mobile automation (Appium), you can set the device time via ADB:

adb shell date -s "2025-11-02 14:30:00"

Remember to revert the clock after the test to avoid affecting subsequent runs.

Hardware Token Simulation

YubiKey provides a YubiKey Neo with OTP** mode that can be emulated using the yubico-python library in a test harness. For most UI tests, it’s sufficient to mock the backend validation endpoint and simply send a predetermined cryptographic response. This removes the need for physical hardware while still exercising the server‑side logic.

Prioritization and Risk‑Based Ordering

Not all test cases carry equal weight. A practical way to order execution is to plot each case on a risk matrix (Impact vs. Likelihood). High‑impact, high‑likelihood items (e.g., valid SMS OTP leading to account takeover if broken) become P1. Low‑impact, low‑likelihood items (e.g., edge case where a user changes time zone while a push is pending) may be P3.

Below is an example of how you might assign priorities to the cases we listed earlier. Adjust the numbers to match your own risk assessment.

How to use the matrix

1. Identify regulatory or contractual obligations (e.g., PSD2 requires strong customer authentication; those map to highest impact).
2. Consult incident data – if past outages were caused by SMS gateway latency, give those cases higher likelihood.
3. Schedule test runs – run all P1 cases on every build, P2 on nightly, P3 weekly, and P4 before major releases.

This risk‑based approach ensures you spend effort where a defect would hurt users or the business most.

Traceability to Requirements and Test Management

Traceability links each test case to a source artifact (user story, specification, regulation). It enables impact analysis when a requirement changes and provides evidence for audits.

Creating a Traceability Matrix

A simple two‑column table works well: the left column lists the requirement ID, the right column lists the test case IDs that verify it. Below is an excerpt for a hypothetical feature set.

When you import this matrix into a test management tool (e.g., Zephyr, Xray, TestRail), you can generate reports showing requirement coverage percentage. If a requirement drops below a threshold (say 80 %), you know you need to author additional cases.

Automating Traceability Links

Many frameworks allow you to embed IDs directly in test annotations. In JUnit 5 you can use @Tag:

@Test
@Tag("US-1234")
@Tag("2FA-001")
void validSmsOtpLogsIn() {
    // test steps
}

In pytest you can use markers:

@pytest.mark.requirement("US-1234")
@pytest.mark.testcase("2FA-001")
def test_valid_sms_otp():
    ...

These tags flow into CI pipelines, enabling automatic generation of traceability reports.

Combining Manual Cases with Autonomous Exploration (SUSA)

Manual test cases give you intentional coverage of known scenarios. Autonomous exploration tools complement that by exercising the application in ways a tester might not anticipate—different user personas, random interaction sequences, and edge‑condition triggering.

SUSA (susatest.com) is an autonomous QA platform that, once pointed at an APK or a web URL, explores the app using a set of built‑in personas (curious, impatient, novice, adversarial, elderly, accessibility, power user, etc.). It performs real interactions—taps, scrolls, text entry, handling dialogs—and reports crashes, ANRs, accessibility violations, security issues, and UX friction. Crucially, it also auto‑generates regression scripts (Appium for Android, Playwright for Web) based on the flows it discovers.

How to Run SUSA for a 2FA Flow

1. Install the agent

   pip install susatest-agent

1. Point it at your build (example for an Android APK)

   susatest-agent run \
       --apk path/to/app-release.apk \
       --personas all \
       --output-dir ./susa-results \
       --timeout 300

The --personas all flag tells SUSA to cycle through its eight built‑in profiles, each with distinct timing, error‑tolerance, and interaction style.

1. Review the report

After the run, open ./susa-results/report.html. You will see sections like:

• Crashes – any unhandled exceptions during OTP entry screens.
• ANRs – long‑running UI thread while waiting for SMS gateway simulation.
• Accessibility – missing labels on OTP input fields, insufficient contrast on error messages.
• Security – exposed OTP in logs or network traces.
• UX friction – steps where the impatient persona repeatedly taps the resend button, revealing a missing debounce.

1. Leverage auto‑generated scripts

SUSA creates an Appium test suite under ./susa-results/appium/ that you can add to your CI. Because the scripts are derived from actual explorer behavior, they often cover paths you did not manually script, such as a power‑user who pastes a TOTP from the clipboard, or an elderly user who enables large‑font mode and then attempts 2FA.

Benefits of Combining Approaches

By using both, you achieve depth (manual cases verify the spec) and breadth (SUSA explores the state space). For 2FA specifically, SUSA often finds:

• Incorrect handling of whitespace when a curious user pastes a code with leading/trailing spaces.
• Missing error states when an impatient user repeatedly taps “Resend OTP” before the previous request finishes.
• Accessibility gaps when an elderly user