PUBLIC LEARNING GUIDE
Find the first thing that goes wrong
A repeatable debugging routine using expected results, small test cases and evidence.
Describe the failure precisely
‘It is broken’ does not tell you what to inspect. ‘The run succeeds but routes a Support request to Sales’ gives you an input and a mismatch. Record the smallest input that reproduces it, the expected outcome and what actually happened.
Start with synthetic data. Logs and screenshots should not contain customer addresses, passwords, API keys or authentication links. You usually need the shape and category of the input rather than somebody’s real information.
Inspect the earliest mismatch
Walk forward from the trigger. Check the input to each condition and action. If category already equals Sales before the routing condition runs, inspect the mapping that produced it. Editing the final action may hide the symptom while leaving the mistake.
Change one thing at a time, rerun the failing case and inspect the same evidence. Keep the change small enough to explain why the result should differ.
Test more than the happy path
A useful small test set includes a normal input, a missing required field, a boundary value and a repeated event. For each one, state both what should happen and what must not happen. A missing recipient should not create a message.
Repeated events matter because a real service may retry delivery. An idempotent action handles the same event again without creating another unintended effect. Retrying every failure blindly can create duplicate messages or records.
Know what your test proves
A simulated run can check routing and the expected data shape. It cannot establish that a real provider accepts your credentials, delivers a message or handles your production traffic. Those need separate controlled integration checks.
Practice: make a three-row test table for a request router. Include a valid request, missing email and the same event twice. Write the expected record and message counts before building it.
Automation 101: quick reference
Case Expected result
Valid email One record; one message
Missing email Validation error; no message
Same event repeated No duplicate message- Reproduction
- The smallest repeatable input and steps that demonstrate a problem.
- Regression test
- A check that fails when a repaired bug returns.
- Boundary
- A value just at, below or above a rule’s threshold.
- Idempotency
- Repeating the same operation does not create an additional unintended effect.
- Evidence
- Observed input and output that support a conclusion, rather than a green status alone.