← ClaudeAtlas

flake-triagelisted

Work out why a test is failing or flaky before changing anything. A decision tree over the five real causes, and the rerun protocol that tells a flake from a real defect. Use when a test fails, when a test passes locally and fails in CI, when a build is red intermittently, or when someone suggests adding a retry.
eduramos21/qa-automation-framework · ★ 0 · Testing & QA · score 66
Install: claude install-skill eduramos21/qa-automation-framework
# Why is this test red Five causes. Work through them in order, because the first is the most common and the one people skip. Nothing gets changed until you know which one it is. A fix applied to the wrong cause makes the test green and loses the information. ## 1. The app is broken The test is right. This is the good case, and it happens more often than the reflex "the test is flaky again" suggests. Check first: did the app change? Look at what shipped since the last green run. `git log` the files the test touches. If a developer changed that area yesterday and the test started failing yesterday, that is your answer. Then look at the failure itself. A wrong value, a missing element that should be there, a status that did not change. Those are defects until proven otherwise. If it is this: `bug-report`. Do not touch the test. ## 2. The app changed on purpose The behaviour is now different and intended. Renamed button, reworked flow, different copy. Check: is there a ticket or a commit that says so? If nobody can point at an intended change, go back to cause 1, because "it was intended" is also what an unintended change looks like from the outside. If it is this: update the test to the new intended behaviour. Update the requirement too if it still describes the old one. ## 3. The test waits badly The test looks for something before it is there, or after it is gone. Signs: - Fails on a slower machine, in CI, or under parallel load. - Passes when you run it alone,