Self-Healing

QualityMax self-healing helps you investigate a failed automated test and prepare a repair without hiding the failure. It uses the failure details and available execution evidence to identify likely causes, such as a changed selector, a timing problem, or an assertion that no longer matches the application.

How the workflow works

1. Run the test and retain its failure output and artifacts.
2. Open the failed execution and request a healing analysis.
3. Review the proposed selector or test-code change and its explanation.
4. Validate the proposal by running the repaired test against the intended environment.
5. Apply the change through your normal review workflow only after the validation result is acceptable.

A suggestion is not proof that the underlying product behavior is correct. A locator can be technically valid while pointing at the wrong element, and a changed assertion can conceal a real regression. Review the application state, the original test intent, and the resulting diff before accepting any repair.

Common failure types

• Selector changes: an element was renamed, moved, or rendered differently.
• Timing failures: the page or dependency did not reach the expected state before a timeout.
• Assertion failures: the observed value differs from the expected value.

When a proposed repair cannot be validated, keep the original failure visible and investigate it as a product, test, or environment issue. QualityMax records execution and healing context so teams can compare the failure evidence with the resulting change instead of treating healing as an invisible retry.

Jev decision activity for web projects

Project settings let a web project set Jev framework selection, discovery grounding, failure classification, and healing candidate selection to Off, Shadow, or Enabled. Off keeps the existing decision path. Shadow records Jev’s opinion without applying it. Enabled permits a Jev choice only where the independent policy and verification checks allow it. Discovery grounding blocks outreach, purchases, and deletes; a project-wide setting cannot establish that an individual action uses a safe test fixture.

The project’s Jev Live panel shows recent stored framework and healing decision receipts. It distinguishes the framework used from a Jev proposal, labels shadow decisions, and shows the healing check at the time of the proposal. A generation receipt is not proof that the script ran successfully. While the panel is open, the selected script’s verification is checked against its current code; an edit can make a stored verification stale. Older verification records without a script digest are shown as unknown rather than current. A healing receipt is not proof that an applied patch still matches the current script. Open the linked script or execution to review current evidence before acting.

The panel’s latency and spend summary covers only its visible receipts. Recorded Jev cost excludes retries and other work without cost receipts, so it is not a full project bill.

Slack incident healing

When Slack notifications are enabled, a failed managed run can open or update an incident thread in the approved project channel. Ask heal this script there. QualityMax presents the current patch for review, or an approval to request healing for that incident.

A general Slack project chat cannot select which failed run to heal. Enabling Auto-heal in Action access does not apply a patch. Review the diff and validation evidence before accepting the change. See the Slack guide.

For a new test, start with the web app quickstart or use the coding-agent workflow to create and review tests in a repository.