You already know how to fix a single flaky test. This lecture is about the situation you will inherit: a suite where forty tests fail at random and everyone has given up. Older Selenium suites are where this problem is most common, so you will probably meet it early.
You cannot debug forty tests one by one. You need a different approach.
Step 1: measure before you fix anything. Selenium gives you nothing here, so build it yourself. Save each run's results to a file and count failures per test over a week. A simple spreadsheet is enough to start.
Do not skip this. Without numbers, "the suite is flaky" is a feeling, and you cannot show progress to a manager who is asking why testing takes so long.
Step 2: rank by pain, not by ease. Sort tests by how often they fail. In almost every suite I have measured, a small number of tests cause most of the failures. Fixing the worst five usually removes half the problem.
Step 3: look for the shared cause. In Selenium suites the causes are usually the same four:
driver.sleepcalls, copied everywhere over the years.- An implicit wait set somewhere in a base class, quietly multiplying every explicit wait.
- Stale element errors from code that holds references across page changes.
- Tests sharing one browser, so a failure in test 3 breaks tests 4 to 10.
Each of these is one fix that repairs many tests. This is why measuring first pays off: you see the family, not the individual.
I joined a team whose suite took 40 minutes and failed constantly. One implicit wait, set three years earlier in a base class, was the cause of both. Removing that single line took the suite to 11 minutes and removed most of the flakiness. Nobody had looked, because everyone assumed the problem was the tests.
Step 4: agree a rule for new flakiness. A rule that works: a test that fails twice in a week without a real bug gets fixed or removed that week, by the person who owns that area.
About quarantine. Moving flaky tests to a suite that does not block builds is useful for a short time and dangerous as a habit. A quarantine with a deadline is a plan. A quarantine with thirty tests that have been there for a year is a graveyard.
The hardest part is not technical. You will need time from your manager, and "fixing flaky tests" sounds like tidying up. Frame it in their language: developer hours lost re-running builds, releases delayed, the cost of a missed bug.
Remember this: measure first, then look for the four usual causes. In Selenium they are nearly always the same ones.
Reference: Troubleshooting.