Testing a QR scan end to end: a test plan from printing to display

End to end testing of a QR scan means testing every step from the printed symbol to the displayed view, as a reader would experience it, with a recorded pass or fail for each step. Testing only the symbol, or only the display, leaves the middle steps untested, and the middle steps are where most failures occur: payload errors, resolver errors, access errors and display inconsistencies. A test plan should therefore be written before testing begins, with the steps, the expected result for each step, the scanner types, the lighting conditions, and the record version to be tested.

Testing without a plan produces impressions. Testing with a plan produces evidence that can be repeated.

How is a test plan structured?

A test plan is structured in step order: print quality, payload, resolution, authentication, tier display, and consistency. Print quality covers module size, quiet zone, contrast, error correction level and durability. Payload covers the decoded address, the identifier, the domain and the absence of session or tracking parameters. Resolution covers the resolver reaching the correct record for the identifier, with no redirect to a different record. Authentication covers the correct prompt for each tier: none for public, authentication for authorised, authority authentication for point 3. Tier display covers the presence of point 1 fields in the public view, the extension in the authorised view, and the absence of leakage. Consistency covers shared fields being identical across views. Each step has a pass standard stated in advance, so that a tester does not adjust the standard to fit the result.

Which scanners and conditions are used?

Testing uses the scanner types that readers will use: at least two phone models with different camera systems and operating systems, and an industrial imager where workshop or recycling readers use one. Testing uses at least two lighting conditions: normal indoor light and low light, plus glare where the battery surface is reflective. Testing uses at least two distances: close reading and reading at arm’s length, where the installation allows it. Testing uses a production representative battery or label, not a paper proof, because substrate, curvature, adhesive and finish affect readability. A code that passes on paper and fails on the battery surface has not passed. The test record states the scanners, the conditions, the battery or label tested, and the date, so that a later failure can be compared with the original test.

What does the test record look like?

How are failures handled?

A failure at any step stops the test for that step and is recorded with the step, the expected result, the observed result, and the evidence. The failure is assigned to the owner of the step: printing, identifier system, resolver, access control, or display. The fix is retested from the failed step onward, not only at the failed step in isolation, because a fix to one step can affect later steps. A payload fix can change symbol density and affect print quality. A resolver fix can change the record reached and affect display consistency. Retesting from the failed step onward catches those knock on effects. A test that passes after a fix, without a record of the original failure and the fix, hides the history of the defect. The test record should retain the failure, the fix and the retest, in sequence.

How often is end to end testing repeated?

End to end testing is repeated on a change to any step: new artwork, new substrate, new printer, new resolver, new access rules, new display, or a new model version. Testing is also repeated at intervals set by the operator, because printing, resolver and display systems drift over time, and because scanner technology changes. A test performed once at launch and never repeated becomes stale evidence, and a stale test cannot support reliance on current codes. The test schedule should be stated in the register, with the date of the last test and the trigger for the next test. A code system without a test schedule is a code system without a control.

What limits apply to a test pass?

A test pass proves that a scan reached the correct view on the date tested, with the scanners and conditions used. It does not prove that the record is complete, current or accurate, and it does not prove that every code in production will read. Production sampling, durability testing and record checking are separate controls, and each must pass on its own terms. This guide gives general educational information only and does not give legal advice for a particular battery, code or system.