Most suites rot on schedule
The first year of a test automation programme looks like a success. Coverage climbs, the demo goes well, the team is proud of the number. The second year is where the bill arrives: tests that fail for reasons unrelated to the code, a suite too slow to run on every commit, and an engineer whose full-time job is now maintaining it.
Three decisions that decide the outcome
First, what you assert on. Tests coupled to markup break every time a designer moves a button. Tests coupled to behaviour and stable identifiers survive redesigns.
Second, where the suite runs. A suite that is not in the pipeline is documentation. If it does not block a merge, it will be ignored within a quarter.
Third, how failure is triaged. A suite with a known flaky set is a suite nobody trusts, and an untrusted suite gets skipped under deadline — which is exactly when you needed it.
The number that matters
Not coverage. Defect escape rate — the share of bugs that reach production despite the suite. It is harder to game and it is the only figure that tells you whether the investment changed anything.