Why a test pass and a risk assessment answer different questions

Testing and assessment are often confused because both produce documents that look authoritative. A test, however, asks a precise question: does this sample, under these conditions, meet this criterion. An assessment asks a broader question: how will this container be used, misused, washed, stacked, and stored, and what harm could follow at each stage.

For a plastic food container, a drop test might show that the container survives a fall onto a hard floor without cracking. That result says nothing about whether the lid seals after fifty dishwasher cycles, whether hot soup warps the base, or whether a child can open the lid and spill its contents. Those questions belong to the assessment, even if no test was commissioned for them.

A test result should always be read with its scope attached: which sample was tested, how many samples, under what temperature and load, and for how long. A result for a thick walled container does not transfer to a thin walled variant, and a result at room temperature does not transfer to a container filled with boiling soup.

The assessment, by contrast, should map the container's whole life. It should follow the container from a lunchbox to a microwave, to a dishwasher, to a freezer, and back to a child's hands, noting where each stage could create a new hazard that no single test was designed to catch.

Illustration: a seller tests 40 containers by dropping them and finds that 30 of them, in round illustration terms, survive without cracking. Those figures, as presented in Why a test pass and a risk assessment answer different questions, are invented, not measured. They show a pass, but they do not show whether the surviving containers still seal, still stack, or still close after the drop, because the drop check never asked those questions.

The seller who presents the drop pass as proof that the container is safe in every kitchen use is therefore overclaiming, even if the test itself was performed correctly. The assessment must fill the gap between what was tested and what buyers will actually do.

To use both kinds of evidence well, the seller should create a simple map: each assessment question on one side, and the evidence that answers it on the other. Questions with no evidence should stand out, marked as open, rather than being hidden behind a test result that answers a different question.

• Write the test question, sample, and conditions beside every test result.
• Map each assessment question to the evidence that actually answers it.
• Mark questions with no matching evidence as open, with a plan to close them.
• Check that the listing claims no more than the map supports.

A common failure is to commission a test and then stop thinking. The test becomes a shield: because a container passed, the seller feels no need to consider dishwasher warping, lid failure, or staining, even though customers later report exactly those problems. Testing should prompt assessment, not replace it.

The reverse failure is to assess without ever testing, relying on opinion where a simple check could settle a question. An assessment that claims a lid seals well, without any handling or test to support that claim, is as weak as a test result presented without an assessment.

Finish by writing a short evidence summary for the container: what was tested, what was assessed by handling and reasoning, and what remains unknown. That summary should be readable by the person who writes the listing, so the listing does not promise more than the evidence supports.

When a new test arrives or a new complaint appears, update the map rather than filing the new document separately. A map that stays current is the difference between a file that grows usefully and a folder that merely grows. The seller should also date every map update and keep the previous version, so the reasoning behind a claim can be traced back when a listing is questioned months later. A short note explaining why the map changed, and who approved the change, makes that history usable for a new team member who was not present when the update was made.