> For the complete documentation index, see [llms.txt](https://learning.contextqa.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learning.contextqa.com/business-use-cases/document-mobile-and-ocr.md).

# Document, OCR, and KYC Validation

## Quick answer

Validate document extraction and identity-verification applications with web, mobile, API, and data-driven ContextQA tests. Use this page to connect the business problem to a supported ContextQA workflow, its expected value, and its operating considerations.

## What this page covers

{% hint style="warning" %}
ContextQA automates the system being tested. It does not perform OCR, identity verification, liveness detection, or regulatory approval itself. The available checks depend on the application, test environment, devices, and provider APIs you connect.
{% endhint %}

Document and identity workflows combine difficult inputs: camera capture, file upload, image quality, extraction, personal data, third-party decisions, and manual review. A complete test strategy validates both the accepted path and the reasoned rejection of unsafe or unusable inputs.

## Reference workflow

1. Start a web or mobile identity-verification session with synthetic test data.
2. Upload or capture the permitted document and, where required, a selfie.
3. Verify the user receives clear progress and consent information.
4. Wait for the application or connected service to finish processing.
5. Verify extracted fields, confidence or review state, and the final decision through the UI or an approved API.
6. Confirm downstream records contain the expected synthetic identifiers and status.
7. Retain only the evidence allowed by the data-handling policy, then clean up the test record.

## Positive coverage

Create representative synthetic samples for every supported document family, issuing region, language, layout, and capture channel. Verify:

* document type is recognized correctly;
* name, date, identifier, and address fields match expected synthetic values;
* normalization rules for dates, punctuation, case, and whitespace;
* front/back association where two images are required;
* successful selfie or liveness response when a test provider supports it;
* UI, API, and persisted status agree;
* the user sees the correct next step after approval or manual review.

## Negative and edge coverage

Use approved synthetic fixtures for:

* blurred, dark, overexposed, cropped, rotated, or low-resolution images;
* glare, occlusion, missing corners, or unreadable fields;
* unsupported type, file extension, file size, or page count;
* expired or incomplete documents;
* mismatched front and back, or mismatched document and selfie;
* duplicate submission and replay behavior;
* corrupted files, provider timeouts, and delayed callbacks;
* altered or suspicious samples supplied by the provider's test program.

The assertion should check more than “failed.” Verify the reason category, safe user message, retry path, manual-review behavior, and absence of sensitive technical details.

## Data-driven test design

Keep the workflow stable and move sample variation into a test data profile:

| Parameter                      | Example purpose                             |
| ------------------------------ | ------------------------------------------- |
| Fixture path or provider token | Select the synthetic document or image      |
| Document family and region     | Route the expected extraction rules         |
| Expected fields                | Compare normalized extracted values         |
| Expected decision              | Approved, rejected, retry, or manual review |
| Expected reason code           | Verify precise negative behavior            |
| Device, OS, and orientation    | Exercise supported capture combinations     |

Avoid real identity documents and biometrics in general-purpose test environments. Restrict access to fixtures, secrets, screenshots, downloads, and execution evidence according to the organization's privacy and retention requirements.

## Mobile-specific considerations

* Camera permission allowed, denied, and revoked
* Front/rear camera switching and orientation changes
* App backgrounding or network interruption during upload
* Device viewport, safe-area, and accessibility behavior
* Retry after an interrupted provider callback
* Consistent status when the user resumes on another channel

Use device coverage based on the product's supported-user population. A provider sandbox may not reproduce every production model or fraud signal, so document what is simulated and what still requires controlled manual validation.

## Business value and success measures

Automating these flows makes provider changes, mobile releases, and document-rule updates safer while reducing repetitive manual fixture checks. Measure:

* extraction accuracy by document class and field;
* false accept, false reject, retry, and manual-review outcomes in the approved test set;
* supported device and capture-mode coverage;
* failures with a specific, user-safe reason;
* time from provider or application change to regression feedback;
* privacy exceptions or unintended sensitive data in evidence (target: none).

## Related documentation

* [Mobile testing overview](/mobile-testing/mobile-testing.md)
* [Uploading mobile apps](/mobile-testing/uploading-apps.md)
* [Test data management](/web-testing/test-data-management.md)
* [Validating API responses](/api-testing/validating-responses.md)
* [Execution evidence](/execution/video-and-screenshots.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://learning.contextqa.com/business-use-cases/document-mobile-and-ocr.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.