A suite's locator healing rate has risen from 2% to 30% of steps this quarter - what does that tell you?

The **healing rate** is the share of located steps in a run where the stored locator matched nothing and a substitute was accepted instead. Read on its own it is a curiosity. Read as a trend against what changed in the product, it is the most honest measure available of how far a suite has drifted from the application it drives. ## What a single repair record has to carry A rate is only as good as the records it aggregates. Every repair should write: 1. **Which case and which step** — the identity of the thing whose behaviour changed. 2. **The description it failed to match**, and the run on which that description was captured. 3. **The substitute chosen**, its score, and which features agreed and which did not. 4. **The runner-up's score**, so the margin is recoverable. Without it you cannot tell a confident identification from a coin flip that happened to clear the bar. 5. **The application version under test**, plus a captured image of the screen at the moment of repair. 6. **Whether the stored description was rewritten afterwards** — a `stored_description_rewritten` flag is the most consequential field in the record and the one most often missing. Records with the first three fields let you count repairs. Records with all six let you decide whether any of them were sound. ## Choosing a denominator Two rates are in common use and they answer different questions. | Rate | Denominator | What it is good for | |---|---|---| | Repairs per located step | Every element lookup the run performed | How much of the suite's contact with the application is now approximate | | Share of cases containing a repair | Cases in the run | How much of the reported result set is not a clean pass | A two-hundred-step journey that repairs one step and a two-step check that repairs one look identical by case and nothing alike by step. Publish both, or state which you mean, or every trend discussion decays into an argument about arithmetic. ## Reading the trend The shape of the curve, set beside the release history, usually names the cause. | Shape | Likeliest cause | Response | |---|---|---| | One-release step change that then holds | A single widely reused control changed structure; every step touching it now repairs | Fix that one control at source; the rate returns to its old level within a run | | Slow steady climb over months | Locators tied to something volatile, and nobody repairing them at source | Treat the most-repaired steps as a maintenance backlog with a budget | | Sawtooth: climbs, drops to zero, climbs again | Descriptions are rewritten on every repair, so the drop is the record being erased | Stop rewriting silently; require a human decision before a description is replaced | | Spike on one deployed target only | That target renders differently — different data, different feature toggles, a different locale | An environment difference, not a suite problem; find it before changing the suite | A move from 2% to 30% across a quarter is the second shape, and its message is organisational rather than technical: **healing has become the maintenance strategy**. The mechanism was adopted as a safety net for occasional drift and is now the thing keeping the suite running at all. At thirty percent, roughly one located step in three is operating an element that nobody chose. ## Why repairs compound The dangerous property of a high rate is not any individual repair; it is that repairs stack. If accepting a substitution rewrites the stored description, the next run scores candidates against the *substitute* rather than against the element the author originally picked. Each hop is defensible alone and the chain is not: over twenty releases a step can walk from a primary action to an adjacent one, one small accepted difference at a time, and no single record in the trail looks wrong. Keeping the original description immutable — repairing against it every time, and requiring a person to approve any replacement — costs a few more failures and buys back the ability to say what a step actually tests. ## Making the number act A metric nobody acts on is decoration. Three moves turn the rate into a control: - **Publish it per run**, beside the pass and fail counts, so a heavily repaired run never reads like a clean one. - **Rank the most-repaired steps** and fix those locators at source. The distribution is usually steep: a handful of steps produce most of the repairs, so a day of work often removes most of the rate. - **Give it a ceiling** — a rate above which the run fails regardless of individual case outcomes. The ceiling is what stops the slow climb, because it converts an invisible trend into a red build somebody has to answer for.