I have seen Flaky Tests treated like a formality and like a real craft. One produces green statuses, the other produces confidence people can explain.
My checklist for Flaky Tests is not meant to turn testing into box-ticking. It exists so pressure does not erase the few important questions that protect trust in automated checks, repeatability, and diagnosing unstable failures. It gets expensive when a real defect is ignored because the suite has trained everyone not to trust red builds.
A good checklist keeps important risk visible when the room gets busy.
Before I Start
- Make the change area explicit
- Write down the most expensive failure in one sentence
- Confirm which automation owners and the whole delivery team should review open risk
- Choose the environment that will tell the truth fastest
During the Check
- Exercise the normal path that should protect trust in automated checks, repeatability, and diagnosing unstable failures
- Run an awkward-path example based on the same test fails in CI, passes on rerun, and leaves the team guessing which result to believe
- Watch for mismatches between visible success and hidden state
- Capture the one detail that will matter during sign-off later
Before I Close the Work
I finish by asking whether the evidence would still make sense to someone who was not present during testing. For this topic, the evidence I want usually looks like failure patterns, environment notes, and a record of which instability causes are already known.
If the answer is yes, the checklist did its job. If the answer is no, I am not done yet. That is usually when confidence becomes visible enough to share, not just feel.