The Four Questions That Sort Any Failure
A red test is a claim, not a verdict. Four questions tell you which problem you actually have — before you touch any code.
Ask them in order
- Did it ever pass? Check
git logon the test file. A test that was never green is a new-test problem, not a regression. - Does it fail locally? CI-only failures are environment problems — lesson 5 covers those. Failing on your machine is good news: you can see it.
- Does it fail alone? Run just that one test. Passes alone but fails in the suite? Another test is leaking state into it.
- Does it fail every time? Run it ten times. 10/10 is a real bug — follow the trace. 3/10 is a race — timing is the suspect.
▸ The four questions as commands
# 1. did it ever pass?
git log --oneline -- tests/test_checkout.py
# 2 + 3. does it fail locally — alone, and in company?
pytest tests/test_checkout.py::test_guest_checkout
pytest tests/
# 4. does it fail every time?
for i in {1..10}; do pytest -q tests/test_checkout.py::test_guest_checkout; doneWhat the answers mean
- Never passed → fix the test's assumptions.
- Fails locally, alone, every time → an ordinary bug. Read the trace (next lesson).
- Fails only in the suite → state leak. Find the test that runs before it.
- Fails sometimes → a race. Measure it (lesson 4).
Grounded in the pytest docs on selecting and re-running tests
All lessons in The Failed Test: Debugging Automation Like a Senior
- The Four Questions That Sort Any Failure
- Reading the Traceback Like a Senior
- Shrinking the Search Space
- Flaky or Broken: Prove It With a Number
- It Only Fails in CI
- The Write-Up: Product Bug or Test Bug