Protocol
Build the smallest failure you can reproduce
A bug you can summon is easier to interrogate than a bug you can only describe.
When it fits
- A defect is real but every retest changes several conditions at once.
When to avoid it
- Do not strip away timing, authorization or state when those conditions may be part of the failure.
Why it matters
Reduce the failing case until it still breaks with as little unrelated setup as practical. Preserve the condition that triggers the problem, the exact input, the observed output and the smallest environment facts that matter. The goal is not an elegant demo; it is a repeatable question you can ask the system again after each hypothesis.
Steps
- Capture one failing input and its observable result.
- Remove unrelated steps or data one at a time while the failure still occurs.
- Freeze the reduced case so another person can run it without reconstructing your memory.
An example
Instead of rerunning an entire customer migration, keep one anonymized record that still produces the wrong partner role.
Check your result
A colleague can run the reduced case and observe the same relevant failure or explicitly record that it remains intermittent.
Keep this limit in mind
- Do not strip away timing, authorization or state when those conditions may be part of the failure.
Connected ideas
Useful withPrefer a test that kills hypotheses
Evidence and sources
Google SRE recommends a solid reproducible test case because it speeds debugging and can enable safer investigation outside production.
Some intermittent or environment-specific failures cannot be reproduced on demand; the card does not require manufacturing a false reproducer.
Effective Troubleshooting · Simplify and reduce