Demo

AI test triage and self-healing tests

A login test breaks after a routine UI change. Watch it get triaged in plain English and healed automatically, step by step. This one runs on a real open-source project, not staged data.

Demo - real open-source project

Sample CI run

A routine UI update quietly breaks a login button locator. The test suite catches it on the next run.

$ mvn test -Dtest=LoginTestRunning: LoginTest.testValidLogin()FAILED: NoSuchElementException Unable to locate element: #login-btn-v2 at LoginPage.clickLogin(LoginPage.java:42)1 test failed, 0 passed
Try it with your own error

Paste a real failing test error, stack trace or broken locator from your own suite, or pick a sample below. This calls the same AI, live, not a script.

No failing test handy? Try a sample:

Inputs are logged to improve this demo. Do not paste secrets, customer data or confidential code.

5 of 5 free tries left today

This is a real project, not a mockup: the self-healing framework and the AI Test Triage Action are both open source and running in CI. View the framework or the Triage Action on GitHub.

How accurate is it?

We tested it on 40 labelled test failures

We wrote 40 failing-test errors, labelled the real cause of each, and ran them through this same AI three times. Ten are tricky on purpose: the error name points one way, but the real clue is elsewhere in the log.

39 / 40failures classified correctly, the same in all three runs
10 / 10tricky cases where the AI found the real cause
0 / 10the same tricky cases for a simple keyword rule, for comparison

The one miss: a loading spinner blocked a click for 30 seconds. We called it timing, the AI called it a UI change. The cases are hand-written, so this is an early test, not proof. Real CI logs are messier. To see where it agreed with us and where it didn't on a real pipeline, open the example repo.

About this demo

What this demo shows

This demo has two parts. First, paste a real failing test error or stack trace, or pick a sample, and the same AI we use in our open-source GitHub Action explains it in plain English: the likely cause, a label such as product bug or test bug, and a first thing to check. Second, a step-by-step run shows a login test breaking after a routine UI change, then being triaged and healed by our open-source test framework.

How it works

  1. Step 1Paste your error or choose a sample failure.
  2. Step 2The AI reads it live and returns a label, a short explanation and a suggested next step.
  3. Step 3Watch the recorded run: the test fails, the failure is triaged, and the broken locator is healed.
  4. Step 4The healed run passes, and the change is shown so a person can review it.
  5. Step 5Use the same Action on your own repo by adding one step to your GitHub Actions workflow.

Who it is for

It is for QA engineers and engineering teams who lose time reading long CI logs to work out why a build went red, and for teams whose UI tests break every time a button moves.

About the data

The triage box calls a live AI. The step-by-step run uses a real open-source project, so the failures and the fix are real, not staged. On a set of 40 labelled failures written by us, it classified 39 correctly; treat that as an early test, not proof.

Questions

Does AI triage ever change my build result?

No. A red build stays red. The triage comment is extra information to help you start in the right place.

Which test tools does it work with?

Any test runner that writes JUnit XML, which covers most Java, Python and JavaScript setups.

Is my pasted error stored?

Yes. Demo inputs and answers are kept in a private sheet so we can improve the demo, and deleted when you ask. Do not paste secrets, keys or customer data.

Next step

Want this running on your test suite?

A 20-minute call is enough to know if we can help. No pitch deck, no pressure.