How to Write Test Cases for Biometric Login (With Examples)

How to Write Test Cases for Biometric Login (With Examples)

How to Write Test Cases for Biometric Login (With Examples)

Biometric login has become a default gatekeeper for mobile apps and web portals, yet many teams still treat it as a black‑box feature and write only a handful of superficial checks. This guide shows how to construct a high‑signal test suite that covers enrollment, authentication, error handling, spoof resistance, and fallback paths, while also linking each case to requirements and prioritizing effort. You will find a concrete test matrix with 20+ examples, a prioritization table, practical automation snippets, and a short checklist you can copy into your test plan. The approach works whether you write tests manually, with Appium/Playwright, or alongside an autonomous explorer such as SUSA.

How to Write Test Cases for Biometric Login (With Examples) – Test Case Anatomy

A test case is more than a list of steps; it is a contract between the specification and the implementation. Every case should contain the following fields:

When you fill out each field consistently, reviewers can quickly judge coverage, and automation engineers can translate the steps into code without ambiguity.

Writing Clear Preconditions

Preconditions often cause flaky tests when they are omitted or vague. For biometric login, enumerate:

• Device capabilities – fingerprint sensor present, face‑auth hardware available, or iris reader enabled.
• OS settings – biometric authentication enabled in system settings, lock screen configured (PIN/pattern/password).
• App state – user is logged out, no existing biometric credential stored for the app, or a specific enrollment flow has just completed.
• Test data – a known username/password pair for fallback, or a mock biometric token if you are stubbing the hardware layer.

Documenting these items prevents a test from passing on one device and failing on another simply because the sensor was disabled.

Structuring Steps for Automation

Each step should map to a single API call or UI interaction. For example:

1. Launch the app and navigate to the Settings → Security → Biometric Login screen.
2. Tap “Enroll Fingerprint”.
3. Place a registered finger on the sensor (simulated via adb emu finger touch ).
4. Wait for the enrollment success dialog.

If you are automating on the web with Playwright, the equivalent steps might involve calling page.evaluate(() => navigator.credentials.get({…})) and mocking the PublicKeyCredential response.

How to Write Test Cases for Biometric Login (With Examples) – Positive and Negative Cases

Positive tests verify that the happy path works under normal conditions. Negative tests confirm that the system correctly rejects invalid or malicious input. Edge cases sit between these categories, often revealing timing or resource‑exhaustion bugs.

Positive Test Matrix (20+ Examples)

Below is a comprehensive table you can adapt to your test management tool. Each row includes an ID, preconditions, steps, and expected result. Feel free to add columns for priority or requirement traceability.

Negative Test Matrix (Representative Samples)

These tables give you a starter set; you can expand them by combining modalities (e.g., face + fingerprint) or adding context‑specific steps such as “while device is in Do Not Disturb mode”.

Data Setup and Test Environment

Reliable biometric testing depends on a controllable environment. Emulators can simulate sensor input, but real hardware catches timing‑related bugs that emulators miss. Use a layered approach:

1. Device farm – provision a matrix of devices covering each biometric modality you support (fingerprint, face, iris). Include at least one device with known sensor quirks (e.g., older fingerprint scanner with higher false‑reject rate).
2. OS version baseline – test on the minimum supported Android/iOS version and the two most recent major releases.
3. Biometric HAL stubs – on Android, you can replace the BiometricManager implementation with a mock that returns predefined results (SUCCESS, FAILED_LOCKOUT, ERROR_HW_UNAVAILABLE). This lets you inject error conditions without physically damaging the sensor.
4. Server‑side mock – if your backend validates a biometric token, stub the endpoint to accept or reject tokens based on test case IDs.
5. Test data isolation – create a dedicated test user account that is cleared before each test run. Use a unique username or a UUID suffix to avoid collisions with other test suites.

Example: Simulating a Fingerprint on Android Emulator

# Enroll a fake fingerprint (id 1)
adb emu finger touch 1
# Simulate a failed scan
adb emu finger touch 2
# Check biometric state
adb shell cmd uimodule list

Example: Mocking WebAuthn in Playwright

const { test, expect } = require('@playwright/test');

test.describe('Biometric login via WebAuthn', () => {
  test.use({
    // Override the navigator.credentials.get implementation
    bypassCSP: true,
  });

  test('successful fingerprint authentication', async ({ page }) => {
    await page.goto('https://example.com/login');
    await page.click('#biometric-login');

    // Mock the credential response
    await page.addInitScript(() => {
      navigator.credentials.get = async () => ({
        id: 'fake-credential-id',
        rawId: base64url.encode(Uint8Array.from([1,2,3])),
        type: 'public-key',
        response: {
          authenticatorData: new ArrayBuffer(0),
          clientDataJSON: new TextEncoder().encode('{}'),
          signature: new ArrayBuffer(0),
        },
      });
    });

    await page.fill('#username', 'testuser');
    await page.click('#submit');
    await expect(page.locator('#welcome')).toHaveText(/Welcome, testuser/);
  });
});

These snippets illustrate how you can drive both positive and negative scenarios without needing a physical biometric sensor for every test run.

Prioritization and Traceability

Not all test cases carry the same weight. Use a risk‑based matrix to decide what to automate first, what to keep manual, and what to deprioritize.

Prioritization Table

Map each test case ID to a requirement ID from your specification (e.g., REQ‑BL‑01: “User shall be able to log in using enrolled fingerprint”). Maintain a simple traceability matrix:

When a requirement changes, you can instantly see which tests need review.

Combining Manual Cases with Autonomous Exploration

Manual test cases give you deterministic coverage of known scenarios. Autonomous explorers, on the other hand, surface unexpected interactions by exercising the app with varied personas and random seeds. When you pair the two, you achieve both depth and breadth.

How an Autonomous Agent Works

An agent like SUSA uploads your APK (or points at a web URL), then:

1. Model building – it constructs a state graph of screens, inputs, and dialogs as it taps, scrolls, and types.
2. Persona injection – each run selects a persona (e.g., “impatient” taps quickly, “elderly” uses larger touch targets, “adversarial” tries malformed inputs).
3. Biometric handling – the agent can invoke the platform’s biometric prompt and respond with success, failure, or error based on configured probabilities.
4. Learning – visited screens and dead ends are stored; subsequent runs avoid re‑exploring known fruitless paths and focus on new edges.

Practical Integration

• Baseline run – execute your manual test suite on a device farm. Record pass/fail and any logs.
• Autonomous session – launch SUSA with a profile that emphasizes biometric interaction (--persona curious --biometric-mode mixed). Let it run for 30 minutes.
• Result comparison – export the agent’s discovered flows and compare against your test matrix. Any flow that reaches a biometric login screen but is not represented in your manual cases becomes a candidate for a new test ID.
• Feedback loop – add the new case to your test management tool, prioritize it, and automate it if feasible.

This approach catches production‑only issues such as:

• A race condition where the biometric prompt appears *after* the app has already navigated away due to a deep link.
• An accessibility service that interferes with the biometric dialog’s focus order, causing TalkBack to read the wrong label.
• A device‑specific OEM skin that replaces the standard biometric dialog with a custom full‑screen overlay, breaking your fallback logic.

By continuously feeding autonomous findings back into your test case repository, you keep the suite aligned with real‑world usage patterns.

Automation Strategies for Biometric Login

Automating biometric features requires stubbing or simulating the hardware layer because most CI environments lack genuine sensors. Below are patterns for Android (Appium/Espresso) and Web (Playwright) that you can adapt.

Android – Using Espresso with a Mock BiometricManager

1. Add a test-only dependency that provides a fake BiometricManager.
2. In your test Application subclass, replace the system service with the mock when Build.TYPE == "test".
3. In the test, program the mock to return specific results.

// FakeBiometricManager.kt
class FakeBiometricManager @Inject constructor(
    private var result: Int = BiometricManager.BIOMETRIC_SUCCESS
) : BiometricManager() {
    override fun canAuthenticate(): Int = result
    override fun authenticate(
        executor: Executor,
        callback: BiometricPrompt.AuthenticationCallback
    ) {
        // Simulate async callback
        executor.execute {
            if (result == BiometricManager.BIOMETRIC_SUCCESS) {
                callback.onAuthenticationSucceeded(
                    BiometricPrompt.AuthenticationResult(CryptoObject(null))
                )
            } else {
                callback.onAuthenticationError(
                    BiometricPrompt.ERROR_NEGATIVE_BUTTON,
                    "Biometric error"
                )
            }
        }
    }
    fun setResult(r: Int) { result = r }
}

In your test:

@Before
fun setup() {
    val fake = FakeBiometricManager()
    fake.setResult(BiometricManager.BIOMETRIC_SUCCESS)
    // Replace the system service (pseudo‑code, actual implementation depends on DI framework)
    ServiceLocator.setBiometricManager(fake)
}

@Test
fun `valid fingerprint logs in`() {
    onView(withId(R.id.btn_fingerprint)).perform(click())
    // Mock returns success, so the app proceeds
    onView(withText(R.string.welcome)).check(matches(isDisplayed()))
}

To test failure, simply call fake.setResult(BiometricManager.BIOMETRIC_ERROR_HW_UNAVAILABLE) before the test.

Web – Playwright with WebAuthn Mock

The Web Authentication API (navigator.credentials.get) can be overridden as shown earlier. For more elaborate scenarios, you can simulate user presence, UV (user verification), and attestation statements using libraries like @github/webauthn-json.

const webauthn = require('@github/webauthn-json');

test('rejects missing user verification', async ({ page }) => {
  await page.goto('https://example.com/login');
  await page.click('#biometric-login');

  await page.addInitScript(() => {
    navigator.credentials.get = async () => {
      throw new Error('NotAllowedError'); // Simulates UV refusal
    };
  });

  await page.fill('#username', 'testuser');
  await page.click('#submit');
  await expect(page.locator('.error')).toHaveText(/Verification required/);
});

Cross‑Platform Tips

• Deterministic timing – inject a fake clock (e.g., androidx.test.core.app.ApplicationProvider.getApplicationContext().setWallpaperTimeout(0)) to eliminate flaky waits caused by sensor latency.
• Logging – enable verbose biometric logs (adb setprop log.tag.BiometricManager VERBOSE) and capture them in your test artifacts for post‑mortem analysis.
• Clean‑up – after each test, clear any enrolled biometric mock state to avoid cross‑test contamination.

These patterns let you run hundreds of biometric login tests per commit without needing a lab of physical devices.

Checklist for Biometric Login Test Suite

Before you sign off a release, run through this concise checklist. Each item maps directly to the test matrices above.

• [ ] Enrollment – at least one successful enrollment per supported modality (fingerprint, face, iris).
• [ ] Primary auth – valid biometric login succeeds without fallback.
• [ ] Fallback paths – PIN, password, and OTP work when biometric is unavailable or rejected.
• [ ] Error handling – sensor hardware errors, lockout timouts, and cancel actions produce appropriate UI and logs.
• [ ] Spoof resistance – liveness detection rejects static images, replay attacks, and known spoof materials.
• [ ] Accessibility – TalkBack/VoiceOver reads all biometric prompts correctly; interaction works with assistive touch.
• [ ] Multi‑device – test on minimum, median, and maximum OS versions; include at least one OEM‑specific skin.
• [ ] Concurrency – verify behavior when biometric auth is invoked during a call, background fetch, or while another auth dialog is visible.
• [ ] Rate limiting – after N failed attempts, the system enforces a delay or requires alternative credential.
• [ ] State persistence – biometric credential survives app updates, device reboots, and admin policy wipes as expected.
• [ ] Logging & metrics – success, failure, and error events are logged with sufficient detail for troubleshooting.
• [ ] CI integration – automated stub‑based tests run on every pull request; manual exploratory runs occur nightly on a device farm.

If any item is unchecked, open a ticket and assign a priority based on the risk matrix earlier.

Real‑World Production Gotchas

Even the most thorough lab suite can miss issues that only appear under unpredictable field conditions. Below are several patterns that have surfaced in production for biometric login, along with suggested mitigations.

Incorporate these observations into your exploratory testing charter. When you notice a pattern recurring in field logs, add a dedicated test case (e.g., “Biometric login succeeds after privacy screen removal”) and prioritize it based on observed impact.

Closing Takeaways

Writing effective test cases for biometric login is not a matter of checking a box that says “fingerprint works”. It requires a systematic approach that:

1. Decomposes the feature into enrollment, authentication, error handling, spoof resistance, fallback, and cross‑cutting concerns such as accessibility and device policy.
2. Captures each dimension in a structured test case with clear preconditions, atomic steps, and observable pass/fail criteria.
3. Prioritizes based on risk, linking every case to a requirement so that impact analysis is trivial when specs evolve.
4. Combines deterministic manual cases with stochastic autonomous exploration to achieve both depth (known paths) and breadth (surprising interactions).
5. Automates wisely by mocking the biometric hardware layer where possible, while still validating real‑device behavior on a representative hardware at least once per release cycle.
6. Learns from production by feeding field‑observed gotchas back into the test matrix, ensuring the suite evolves alongside the device ecosystem.

When you follow the process outlined here—starting with the exact phrase “How to Write Test Cases for Biometric Login (With Examples)” in your opening sentence, populating a rich test matrix, applying a risk‑based priority list, and augmenting manual effort with autonomous agents—you will deliver a biometric login feature that is not only functional but also resilient to the myriad ways users and attackers interact with modern authentication systems. Use the tables, snippets, and checklist as a living reference, and revisit them whenever you add a new modality, support a new OS version, or encounter a fresh failure mode in