The fix lands mid-run. Unless it would hide a bug.
Every tool in this category sells self-healing. The question none of them answer is the one every QA lead asks first: does it just turn my tests green and bury real failures?
It is a fair question, because a healer that will rewrite anything to get a pass is worse than no healer at all. So the interesting part of ours is not what it repairs. It is what it will not.
The rule, in one line
A heal may change how a test finds something. Never what it expects to see.
It may
- Change how a test finds something on the page
- Wait longer for something that is slow to appear
- Recover from a control that moved, was renamed, or was re-wrapped
It may not
- Change what a test expects to see
- Rewrite an assertion so a wrong value passes
- Auto-apply anything without proof it resolves to one visible element
- Touch a failure that looks like a product defect
What happens when a test fails
Three exits, and one of them is a refusal.
A failure is classified before anything is touched. Most healers have one exit, which is why the objection exists.
Repaired, mid-run
The interface moved and the test was looking in the old place. Axon finds the control from the live page, swaps the locator, and the suite carries on. The fix is re-run before it is kept, so it is not a change that merely looked right.
Left failing, on purpose
The page is fine and the expectation is not being met. That is what a bug looks like, so nothing is rewritten. The test stays red, and you are told why it was not healed rather than finding a green suite and no explanation.
Escalated, and it counts
A test that keeps failing without a valid repair stops being retried and is quarantined. That is not a quiet shelving: a quarantined test is one of the conditions your release is judged against, so it has to be dealt with before you can call a release clean.
The refusal
The cheapest way to pass a test is to change what it was checking.
A test checks the order total says fifty pounds. A change ships, the total is now forty, and the test goes red. There are two ways to make it green: find out why the total changed, or edit the test to expect forty.
The second one takes a second and produces a clean suite. It also throws away the only warning you were going to get. AxonQA cannot do it: a repair is permitted to change the way a test locates something, and is blocked from altering the value it asserts. That is not a setting or a default, it is a guard on every proposed change, and there are regression tests whose job is to keep it that way.
When the evidence says the page is fine and the expectation is not, nothing is repaired at all. That failure is treated as a probable defect and left alone.
Proposed change, rejected
Was checking
Total: £50.00
Would have become
Total: £40.00
Blocked.
Changing the expected value would mask a potential bug. The test stays red and the failure is reported as a probable defect.
Illustrative figures. The guard itself is real, applied to every proposed change, and covered by regression tests.
How it behaves
Repaired during the run, not queued up for you afterwards.
A suite that stops at the first moved button has already cost you the night.
Verified by re-running it
A candidate fix is not trusted because it looks plausible. It is re-run, and it is only kept if the test actually passes. Anything that does not is discarded.
Most repairs never reach a model
The common breakages are handled deterministically, without an AI call. A model is the last resort rather than the first move, which is why healing does not scale its cost with your suite.
Every heal is on the record
A fix that landed mid-run is not a fix that happened quietly. Each one is recorded with the evidence behind it, so you can review afterwards what changed and why.
Where it ends up
A test it refused to heal becomes a condition on your release.
This is the part that only works because both ends live in the same system. A failure that cannot be validly repaired escalates, and a quarantined test is one of the conditions a release is judged against. So a healer that quietly gave up would not just leave a red test behind, it would leave a release looking cleaner than it is.
An automation tool can repair a locator. It cannot make that repair, or its refusal, show up in the decision about whether you ship.
What it will not do
Healing is not a suite that maintains itself.
Some failures are not repairable and are not pretended to be. An infrastructure timeout with nothing to go on, or a step that no longer exists in the flow, is reported rather than retried into the ground.
A test that keeps failing without a valid fix is taken out of the run rather than left flapping, and it stays on the release record until somebody deals with it. Healing buys you the maintenance nobody wants to do. It does not buy you a suite that never needs a person.
See it repair something, and refuse something.
Choose a plan and run the sample project. It ships with a history of runs that includes passes, failures and heals.