Test automation without producing duplicates
Useful automation remains understandable when an event arrives twice or a step fails. Prepare these cases before connecting the workflow to real data and actions.
Define the event and boundary
Describe the trigger, authorised reads and allowed changes. Identify information that recognises the same request when repeated.
Fictional example: synchronisation may deliver a request twice. Decide whether repetition is ignored, updates a draft or triggers review; two orders are not an acceptable result.
Test the same event twice
In a setup with no external effects, submit a fictional case and replay it. Check produced object counts and retained outcomes. Also test two similar events that are genuinely different.
A name-only rule may block a legitimate request. Prefer a documented event definition with useful identifiers; preserve ambiguous cases for human review.
Simulate partial success
Fail one step after another succeeds. Define whether processing resumes, reverses or waits for a person. A lost response does not mean an action never occurred.
Retain execution evidence without unnecessary data. Before retrying a write, check whether the destination system has already performed it.
Prepare manual recovery
Write a procedure to identify the case, understand its state and resume without duplication. Prepare a stop action and owner for unexpected results.
A person must be able to explain why a case awaits review. A consistent state table is more useful than notifications that hide unfinished work.
Measure total work
Compare preparation, monitoring and correction effort with manual work. Record observed volumes and unhandled cases; one successful run does not establish sustained savings.
Retain duplicate and failure tests for rerunning after changes. Agree permitted automation scope with accountable people before real use.
A record to keep with the decision
| Item | Evidence |
|---|---|
| Event | Trigger, identifier and permissions. |
| Repetition | Replayed event and duplicate-free outcome. |
| Partial failure | Completed steps and expected recovery. |
| Review | Owner, shutdown and outcome check. |
Download the worksheet to fill in (CSV)
Frequently asked questions
Should duplicates be removed automatically?
Not without establishing that they represent the same event. Similar names are insufficient.
Does one successful test justify full automation?
It validates only that case. Check errors, repetition, permissions and recovery before expanding.
Reference material
The practical checklist is an editorial synthesis to adapt to your service. It does not constitute a certification or an audit result.