Flaky tests pass and fail non-deterministically, eroding trust. A framework reduces flakiness by design — robust waits, stable locators, isolated data, controlled network — and tracks/quarantines remaining flakes rather than masking them with blanket retries.
Root causes of flakiness: fixed sleeps/timing races (fix with explicit waits), brittle locators (use stable data-* attributes), shared/dirty test data (isolate + seed + clean), external dependencies (stub/mock or use API setup), animation/async races, and parallel collisions (thread-local drivers, unique data). The framework should provide the tools (wait helpers, data factories, stable-locator conventions) that make reliable tests the default. Retries can absorb rare irreducible noise but must not hide reproducible bugs; track flaky tests (report analytics), quarantine and fix the worst offenders. Flakiness management is a defining senior-level topic.
The framework enforces explicit-wait helpers, data-testid locators, per-test unique data, and API-stubbed externals; a flaky-test dashboard surfaces the worst offenders, which the team fixes at the root instead of cranking up retries.
Your suite is 'green only with 3 retries'. Walk through how you'd address flakiness properly.