Understand what an integration test can and cannot prove

What this means for your practice

Ask the supplier what its test setup represents and which real situations it cannot reproduce. Record those limits in the agreed checks, rather than assuming a successful demonstration proves how the live service will behave.

Questions to take to your supplier

Submit an incomplete fictional record that the receiving rules should reject. How does the test environment respond, and what differs from live use? Agree authorised checks for important gaps. The supplier should explain the remaining uncertainty rather than treating a single successful sample as complete proof.

Agree the working process

Ask the supplier to explain which parts of the live service the test environment represents faithfully and which are simplified or unavailable. The business owner needs that limitation in plain language, especially where it affects permissions, validation or the receiving workflow. Choose examples that exercise actual requirements rather than only the vendor's easiest sample record. Include missing information, unsupported values and any relationship between records important to the task. Check the error or review route when the receiving system rejects an example.

Keep uncovered cases in the acceptance plan with a named owner and an authorised way to investigate them. A later live check should be planned proportionately, not improvised using real people or uncontrolled submissions. Record the differences that remain when deciding readiness. The useful question is what confidence the evidence provides for your specific journey. A successful demonstration can be valuable without being presented as proof of behaviours the available environment could not test.

How to check the result

Count acceptance assumptions not exercised by available testing.