Why your Selenium tests fail intermittently: 5 reasons for flaky tests
Flaky tests are the biggest source of distrust in automation. Per the Google Testing Blog, about 1.5% of all green CI runs in their pipelines contained at least one flaky failure. And most often, the problem isn’t in the product — it’s in the test itself.
⚠️ Implicit + explicit waits in the same project. Selenium docs warn explicitly: don’t mix them. Implicit wait blocks element lookup, explicit adds its own delay — the total timeout becomes unpredictable. Keep only WebDriverWait with an explicit condition.
⚠️ Tests with Thread.sleep(3000). It’s always either too short (under CI load) or too long (slows you down). Replace with waiting for a concrete DOM state: elementToBeClickable, presenceOfElementLocated, textToBe.
⚠️ Test order dependency. Test A creates a user, test B logs in with the same email. If B runs first — fail. Every test should be fully isolated: own fixture with a unique ID, or setUp/tearDown that cleans state.
⚠️ Animations and transitions. Test clicks a button, checks the result — but the button is still in its fade-in animation. Solution: either disable CSS animations in the test environment (* { animation: none !important; }), or wait for aria-busy="false".
⚠️ Shared environment. A parallel CI runner changed data mid-test. Use data isolation: namespacing by test id, transactional rollback in the DB, or mocking external APIs via WireMock/MSW.
What to do right now
✅ Run your most unstable test 50 times in a row — the failure pattern will reveal the cause class.
✅ Use runner-level retries ONLY as a temporary crutch, tagged and tracked in Jira — otherwise it’ll mask real bugs.
✅ Disable implicit wait globally and see which tests immediately fail — those are your growth areas.