Self-healing execution
Recover from a failed action by finding another route to the same expected outcome.
When an action fails, agent-qa re-observes the current screen and plans another way to complete the step. The expected outcome remains the same. A different route can recover the run; a different requirement cannot.
This illustrative demo shows both cases: the agent dismisses a late notice and runs the requested twelve tests, then refuses a partial run when only eight are available.
Run the 12 tests in the smoke suite.
suite Smoke
Timeline
A step, and the screen it runs on
A sample smoke suite with 12 tests, and a step that asks to run them. The Run suite control is where it should be.
Recover the path
The execution loop observes, plans, executes, and verifies. When a sub-action fails, the next attempt includes that failure context and the current application state. This lets the agent respond to a changed layout or an obstructing overlay instead of repeating the same click blindly.
A healed result retains the failed action and subsequent attempts in the run trace. Use the dashboard to inspect the reasoning, screenshots, and final outcome.
Preserve the expectation
A test asking for all twelve tests to run is not satisfied by running eight. If the requested behavior is unavailable, the run should report that failure. Healing does not rewrite a test or weaken its assertions.
Write explicit outcomes in your test steps, so recovery has a clear goal to preserve.
Set the attempt budget
Use use.healing.maxAttempts to override the self-healing retry budget for a test:
use:
healing:
maxAttempts: 1The value is inherited when you do not override it. See the test configuration reference for this setting and the separate step retry and timeout controls.
Healing and improvement
Self-healing happens during execution. Self-improvement reviews completed runs to propose useful knowledge for later ones. Both depend on evidence; inspect the original failure and the verified result when diagnosing a run.