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.
You cannot debug forty tests one by one. You need a different approach.
Step 1: measure before you fix anything. You need to know which tests fail, how often, and whether it is getting better. Cypress Cloud does this for you, or you can save your test results to a file and count failures per test over a week.
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. That is your first week, and it gives you a number to show.
Step 3: look for the shared cause. Flaky tests usually come in families. When you fix five, you will notice the same three causes underneath:
- Fixed
cy.waitcalls copied from an old test into fifty new ones. - A shared login or shared data that tests fight over.
- One very slow screen that everything has to pass through.
Fixing the cause once fixes many tests at the same time. This is why measuring first pays off: you see the pattern instead of fixing symptoms.
Step 4: agree a rule for new flakiness. Otherwise you will clean the suite and it will slowly refill. A rule that works well: a test that flakes twice in a week gets fixed or removed that week, by the person who owns that area. Write it down and get the team to agree.
About quarantine. Some teams move flaky tests to a "quarantine" suite that does not block builds. This 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 that gives people the feeling of coverage without the coverage.
Here is the hardest part, and it is not technical. You will need time from your manager to do this work, and "fixing flaky tests" sounds like tidying up. Frame it in their language instead: how many developer hours per week are lost re-running builds, how long a release is delayed, what a missed bug costs.
Remember this: measure first, fix the shared causes, and agree a rule so the suite does not refill.
Reference: Flaky test management.