Liveness detection testing should prove two things at once: that a face verification API can resist presentation attacks and that legitimate users can complete the flow across realistic conditions. This reusable QA checklist covers test design, attack scenarios, device and lighting variation, accessibility, fallback handling, API assertions, and release review.
Overview
Liveness detection is a control within a biometric authentication or identity verification flow. It helps assess whether the camera is observing a live person rather than a presentation of a face, such as an image, replayed video, mask, or display. It is not the same as face matching: face matching compares facial features with a reference, while liveness detection evaluates whether the interaction appears live.
A useful test plan separates three outcomes:
- Attack resistance: known presentation attempts should be rejected or escalated according to the intended risk policy.
- Legitimate completion: real users should be able to pass without unreasonable friction on supported devices and networks.
- Operational correctness: the API, SDK, logging, retries, review queue, and fallback path should behave consistently when a check succeeds, fails, times out, or is abandoned.
Test in a controlled environment and use authorized test subjects and materials. Do not treat a single pass rate as proof of security. Results should be segmented by device, operating system, camera, lighting, user interaction, and failure reason so that regressions are visible.
Checklist by scenario
1. Baseline genuine-user tests
Begin with ordinary sessions before introducing attack scenarios. Use several testers with different facial characteristics, glasses or other common accessories, and levels of familiarity with mobile verification. For each session, record:
- device model, operating system, browser or app version, and front-facing camera;
- network type and whether the session moved between networks;
- time to start, complete, and receive a result;
- number of prompts, retries, and user corrections;
- final result and reason code returned by the API;
- whether the user understood what to do without staff assistance.
Repeat baseline tests after changing SDK versions, camera permissions, capture instructions, image compression, or session timeouts. These changes can affect usability even when the underlying biometric model is unchanged.
2. Presentation attack scenarios
Create a test matrix that distinguishes the attack medium from the user action. Test only materials that your organization is authorized to use, and document the exact setup so another tester can reproduce it.
| Scenario | What to test | Expected handling |
|---|---|---|
| Printed image | Different print quality, size, distance, and paper reflectivity | Reject, challenge, or route to review according to policy |
| Screen replay | Image or video shown on phones, tablets, and monitors with varied brightness | Do not grant a successful verification solely because a face is detected |
| Pre-recorded video | Replay with changes in angle, motion, and display refresh behavior | Return a consistent decision or a controlled retry |
| Face covering or mask | Partial coverage and accessories permitted or restricted by the product flow | Apply documented policy and provide a usable next step |
| Camera substitution | Unexpected camera source, virtual camera, or altered capture path where relevant | Block, flag, or require an approved capture route |
Do not rely on one attack sample. Vary distance, orientation, brightness, motion, and timing. The purpose is to test whether the control remains dependable when presentation conditions change, not merely whether it detects a familiar sample.
3. Device and lighting coverage
Build a representative device set from your actual customer or employee population. Include supported operating systems, older supported devices, different camera capabilities, and both native-app and browser journeys if both are offered.
| Condition | Test variations | Observe |
|---|---|---|
| Lighting | Even indoor light, backlighting, low light, bright overhead light, and changing light | Face visibility, prompts, retries, and false declines |
| Framing | Close, far, off-center, tilted, and moving camera | Guidance quality and time to correct position |
| Camera quality | High-resolution and lower-resolution front cameras | Capture stability and result consistency |
| Network | Fast, slow, intermittent, and interrupted connections | Timeouts, duplicate submissions, and recoverability |
| Permissions | Denied, delayed, revoked, and restored camera permission | Clear error handling without a dead end |
4. Accessibility and legitimate-user friction
Confirm that instructions are readable, concise, and available in the supported languages. Test screen magnification, large text settings, reduced motion preferences, voice guidance where supported, and users who cannot perform a required movement easily. A liveness flow should not assume that every user can turn their head, hold a device steadily, or interact with a small visual target.
Define an alternate path before testing begins. Depending on risk and policy, that path might be assisted review, document verification, a different authentication factor, or a scheduled verification. It should not silently weaken the assurance level.
5. API and workflow tests
Test the face verification API independently from the user interface, then test the complete journey. A practical test-case template includes:
Test ID: LIVE-###
Scenario: [genuine user / presentation attempt / technical failure]
Setup: [device, OS, camera, lighting, network, SDK version]
Input: [capture or session conditions]
Expected HTTP result: [documented success or error class]
Expected decision: [pass, fail, retry, review, or unavailable]
Security checks: [session binding, replay handling, rate limit, idempotency]
Audit checks: [event recorded, no unnecessary biometric payload retained]
Observed result: [actual response and user experience]
Evidence: [redacted logs, screen recording, test reference]Assert that sessions are bound to the correct user and transaction, expired sessions cannot be reused, retries do not create conflicting records, and client-visible errors do not expose sensitive implementation details. Verify that logs contain enough context for investigation without unnecessarily copying biometric data.
What to double-check
- Decision semantics: Confirm what pass, fail, retry, review, timeout, and unavailable mean. Do not map every non-pass response to a permanent rejection.
- Threshold configuration: Record the configured thresholds and who can change them. Test boundary cases rather than only obvious passes and fails.
- Model and SDK version: Capture the biometric model, SDK, API version, and configuration in every test report. A version change can alter both attack outcomes and user friction.
- Retry policy: Check maximum attempts, cooldowns, session expiry, and whether repeated attempts create a fraud signal or merely frustrate a legitimate user.
- Data handling: Verify encryption in transit and at rest according to your architecture, retention limits, deletion behavior, access controls, and redaction in logs. Align the workflow with your privacy and compliance review.
- Human review: Confirm what evidence reviewers receive, how decisions are recorded, and how an appeal or correction is handled.
- Monitoring: Segment outcomes by device, geography where appropriate, language, lighting, and failure code. Aggregate results can conceal a problem affecting one group or device family.
For broader implementation context, pair this QA process with the Biometric Authentication Implementation Guide and the Digital Identity Verification Compliance Checklist.
Common mistakes
- Testing only the happy path. A passing genuine-user demo says little about resilience, recovery, or API behavior during failure.
- Using one device and one lighting setup. This produces a narrow result that may not represent real customer conditions.
- Confusing face matching with liveness. A strong match does not by itself establish that the face came from a live person.
- Optimizing only for rejection. Excessive friction can shift users to unsafe workarounds or overload manual review. Security and completion quality must be assessed together.
- Ignoring technical failures. Timeouts, duplicate callbacks, revoked permissions, and interrupted uploads are part of the security boundary, not merely frontend defects.
- Keeping sensitive evidence indefinitely. Store only what is needed for testing, investigation, and documented obligations, with restricted access and a deletion process.
- Failing to preserve reproducibility. Without version, device, configuration, and environmental details, a regression cannot be reliably confirmed.
When to revisit
Run the full regression set before a production release, a major seasonal onboarding cycle, a vendor or model change, an SDK or operating-system update, or a material change to thresholds and retry rules. Run focused tests after smaller changes to camera permissions, capture instructions, API error mapping, network handling, or fallback routing.
Also revisit the checklist after a fraud incident, a spike in failed verifications, a rise in manual reviews, or reports that a particular device or user group cannot complete the flow. Compare results with the previous version and document whether the change affected attack resistance, legitimate completion, latency, privacy controls, or support volume.
Practical next step: create a versioned test matrix, select representative devices, define pass criteria for each scenario, and run a baseline before changing the integration. Keep redacted evidence with the API version, SDK version, environment, and decision codes. This turns liveness detection testing from a one-time demonstration into a repeatable part of biometric authentication QA.
