Test extraction failure behavior with unreadable input

A negative test needs an expected failure

Include it in the trial so you can see whether failure is visible and recoverable before the process depends on a result that never arrived.

In ParseMill, select an extracted invoice field to inspect its source, correct the value and export the reviewed workbook. Try your own invoices as well as the interactive sample. Compare upload, checking and correction time with your current way of building the same spreadsheet.

Distinguish an unreadable field from an unsupported file and from a document with no relevant table. These cases should remain visible in results rather than being discarded from the evaluation denominator.

Create a synthetic negative-case set

The fixture describes test cases to create and run locally. It does not claim that a particular product has passed them. Preserve the exact test inputs so repeated runs examine the same degradation rather than different versions of a blurred image.

UK Government: Data Quality Framework connects quality assessment to intended use. Honest handling of unavailable information is part of a useful outcome when a fabricated value would mislead the recipient.

Run and score the negative cases

1. Build the cases from synthetic or authorized documents. Record which information was deliberately removed or made unreadable and retain the original for test design only.
2. Define expected statuses before running the extraction. Keep the unreadable test source separate from the clear reference used to design it.
3. Inspect every returned value for source support. Count unsupported guesses separately from correct abstentions and technical failures.
4. Verify that exported files preserve the unresolved status and do not convert missing results to zeros or blank successful records.

Google: Dividing datasets explains why evaluation examples should be separated from development. Keep some negative cases unseen while tuning exception handling so the final check is informative.

Avoid unfair or uninformative tests

Do not demand that a system recover information absent from the input. The relevant question is whether it handles that absence appropriately. Conversely, do not label a merely difficult but readable field unreadable without independent review; that would make an omission look acceptable.

Check source availability in the user workflow. If a clearer document can be requested, the output should support that next action with an identifiable field and location rather than an unexplained failure message.

Record the actual behavior

For each fixture, report whether the system returned a supported value, an unresolved state, an unsupported guess or a technical error. Keep all attempted cases in the summary and explain the intended behavior for each. A high success rate that excludes failures is incomplete evidence.

Use negative cases when evaluating ParseMill on your document collection. Assess whether the review process exposes unreadable material clearly enough for your team to request better evidence before using the register.