QA Automation Teams Actually Maintain

The failure mode

A team writes four hundred end-to-end tests in a quarter. By the next quarter the suite takes forty minutes, fails twice a week for reasons unrelated to the change, and somebody adds the magic words "just re-run it" to the deploy checklist.

At that point the suite has stopped being a signal. It is a tax.

What we do instead

• Cover the money paths end to end. Sign-up, checkout, and whatever the product's core action is. Nothing else earns a browser test.
• Push everything else down. Business rules belong in unit tests, where they run in milliseconds and fail for exactly one reason.
• Fix or delete. A test that has been flaky for two weeks gets repaired that sprint or removed. Nothing in between.
• Keep the suite under ten minutes. A check that does not fit the budget runs nightly, not on every push.

Make failures readable

A failing test should name what broke, not where it noticed. checkout fails when the promo code has expired tells a developer where to look. test_17 timed out waiting for selector sends them on an expedition.

The number that matters

Not coverage percentage. The one worth tracking is how often a red build corresponds to a real defect. When that ratio is high, people stop merging past it — and that, not the test count, is what a suite is for.