Rescue

What a suite looks like when it has stopped working

It is green, and the bugs still reach production. Or it is red, and the team has learned that red means nothing.

Both come from the same two places: assertions that cannot tell a working system from a broken one, and red runs whose cause is the environment rather than the code.

What gets built

The same system, built against what you already have. It learns your application first — what each element is, where the screens disagree — and that is what separates a test that broke from a test that was never checking anything.

It stays after I leave, and so does what it knows. Deciding which is which stays with me.

What I read in the history

Not just the tests as they stand — the commits that got them there. A suite does not start out this way. It drifts: a timeout raised, an expectation edited to match the output, a test skipped during a release week and never put back.

That drift leaves a trail, and reading it tells you more than reading the final state does. You get the trail, named, with the commits. Not to assign blame — every suite that has run long enough has some of this in it — but because you cannot install a gate against a failure mode nobody has named.

What happens to each test

Every test is read for one question: does this assertion distinguish a working system from a broken one? The check is state mutation, not opinion: an assertion that still passes against a deliberately broken system has not been tested, only run.

That puts every test in one of three places.

It works and it proves something

It stays. If it fails intermittently because of the environment rather than the code, it gets stabilised.

It is broken but repairable

A locator that moved, a dependency on data somebody else edits, a race that was papered over with a wait. I repair it. The coverage already exists; it just stopped functioning.

It proves nothing

It is deleted, and it appears in a list you get, with the reason. There is nothing in it to repair.

The coverage you lose with that third group is real. Writing it back is separate work with its own scope, and I will give you its size as a number once I have finished reading.

What gets fixed underneath

Flaky tests are quarantined under a written policy rather than silently retried or skipped. A retry hides the instability; a skip removes the coverage without telling anyone. The policy states what happens instead, and who has to look at it.

The environment stops being a variable: isolation on every run, and test data the suite creates and cleans up itself instead of a shared account somebody edits on a Tuesday. After that, a red run means a defect again.

What remains is restructured so that a mid-level engineer can work in it without guessing, and it is documented to the point where they add a flow themselves at handover while I am still there and not helping.

The trap catalogue and the tool selection come out of the rescue too. Reading a suite that has drifted is how you find what has been fighting it — each trap named, and priced in hours where it is confirmed — and the tools that stay are chosen the same way, with the ones I would replace named and the reason for each.

What stops it happening again

Cleaning a suite without installing gates puts you back where you started, on the same timescale it took to get here. The pressure that produced the drift has not gone anywhere.

So the last part is the gates: a merge gate that stops a test proving nothing, a written quarantine policy instead of a silent retry, and a rule about what a person has to look at before a skip is allowed. Agreed with the team, not filed in the repository.

What you get

1. Two numbers. How many tests existed and how many of them could actually detect a failure. Then the same count after.
2. The list of what was deleted, with a reason against each line.
3. The size of the gap that deleting left, so you can decide what to do about it.

I will tell you if the honest answer is to delete the suite and start over. That answer costs you a reading rather than a rebuild, and it is the one a vendor with a rebuild to sell has no reason to give you.

What you provide

What can be added

Team training

One day on the suite and how to extend it, priced separately. Worth it when the people who wrote the original suite have left, which is often how it got into this state.

Support after handover

Optional, priced with the project. A named owner for the suite while your team learns it: a few hours a month, two working days to respond. Covers breakage and questions; new flows are quoted separately. A fixed three-month term from handover, ending on a date agreed at the start. It does not renew unless you ask for it.

Separate from this: anything that was broken when I handed it over, I fix for thirty days at no charge, as part of the handover rather than a billed add-on.