One successful test shows only one path. For a working process, what matters is how the system behaves when errors and repeated events occur.
Prepare technical scenarios
For an integration, test valid and incomplete data, the same event being repeated and the receiving system being unavailable. Find out separately what happens once the connection is restored. Use an agreed test environment: accidentally creating a real order or sending a message to a customer must not become part of the experiment.
Check recovery
Clarify who receives the notification, where the error is visible and how to repeat the action without creating a duplicate. Keep clear instructions for manual handling. A “completed” report must correspond to a verified result in the target system.
How to record the expected behaviour of a test
For each scenario, specify the input data, the action and the result. “It shouldn't break” does not allow two people to assess the test in the same way. For a repeated enquiry, decide in advance whether a new record is created, an existing one is updated or a person has to decide. For an incomplete set of information, specify who receives a message and what the sender sees. Use test data and an agreed environment. Accidentally sending something to a real customer does not become acceptable just because whoever did it called it an integration test.
How to sign off recovery after an error
Simulate a failure of an external service, then check that it is detected and can be safely repeated. It must be clear what has already been done and what remains; otherwise a restart may repeat a significant action. Check the log without unnecessarily exposing personal material. The recovery instructions must be available to the designated employee and include conditions for stopping and passing the issue to a specialist. Final sign-off applies to the scenarios and limitations that were tested, not to a promise that nothing will ever fail in future.
What to check
- Test the same enquiry being submitted twice.
- Simulate a missing required value.
- Clarify what happens if the integration fails.
- Check that a task can be completed manually.
A set of acceptance scenarios for automation
For each scenario, record the expected behaviour in advance, then compare it with the actual result. Use agreed test data and check the target system.
| Scenario | What to check | Sign of completion |
|---|---|---|
| Normal event | The full data path | The result reaches the person responsible |
| Repeated event | The rule for handling duplicates | No accidental second order |
| Incomplete data | Required fields and notification | The error is clear and not hidden |
| Service unavailable | Alert and next action | The team knows what needs to be restored |
| Retry after a failure | Safe restart order | No results lost or duplicated |
| Manual handling | Instructions and access | The designated person can complete the task |
Example situation
If a form is submitted twice, the system must follow a rule chosen in advance rather than randomly creating two independent orders.
Next step
Automation is ready when it behaves predictably with exceptions and recovery is clear.
Official information on this topic
Checklists and examples are organisational recommendations. Requirements depend on the procedure, the city and your situation; check them with the relevant office before you act. Please discuss legal and tax questions with an authorised professional.
This article was prepared with the help of AI. The example illustrates the approach and does not describe a client case.