Guide
Document Extraction QA Sample Plan
A sample-based QA plan for checking PDF, DOCX, RTF, EPUB, EML, XPS, and winmail.dat extraction behavior.
Last updated: 2026-07-27
Create one sample per format
A useful QA set includes small, non-private samples for each supported format. The goal is not to cover every possible file; it is to confirm that common files produce clear output, clear limitations, and helpful errors.
Include expected output notes
For each sample, write what should appear: title, body text, attachment names, metadata, or chapter headings. Expected notes make it easier to notice when a parser silently drops important content.
Test edge cases separately
Tables, columns, scanned pages, special symbols, non-English text, HTML email, and Outlook TNEF attributes should be tested as edge cases. Keeping edge cases separate makes failures easier to explain to users.
Review privacy behavior
Browser-local tools should not upload the test file. Server-processed tools should explain retention and deletion rules. QA should include both function and data-handling behavior.
Check the empty and unsupported states
A good tool page explains what happened when a file has no extractable text, uses an unsupported format, or needs OCR. Empty output should not feel like a broken site.
Update documentation with findings
If a sample reveals a limitation, document it on the tool page. Honest limits can improve user trust and reduce policy risk because the site does not overpromise.