Solution
AI test automation for engineering teams
Another red build. Nobody opens the log, someone clicks re-run, it goes green, and the team trusts the suite a little less than yesterday. Most engineering teams live with a test suite that is half trusted: failures nobody has time to read, a redesign that breaks thirty locators at once, and the test that would have caught the real bug never written. AI can fix some of that today and none of the rest. This page is about the useful part, what you can try before talking to us, and where a person still has to decide.
Red builds nobody has time to read, locators that break with every redesign, and a suite the team only half trusts.
AI failure triage on every pull request and logged self-healing locators, added to your Selenium or Playwright suite.
Failed builds that explain themselves, fewer broken locators, and open-source tools you can inspect first.
What AI is good at in testing, and what it is not
AI is good at reading. It can read a long failure log and say, in plain English, whether the failure looks like a product bug, a broken test, a missing service or a timing problem, and what to check first. It can read a page's HTML and propose a new locator when the old one stopped matching. It can read a user story and draft test cases for a person to review. Those are the jobs where it saves hours every week.
AI is not good at deciding what matters. Which flows must never break, which tests are worth keeping, what a correct result looks like for your product: those decisions stay with your team, and with us when we work alongside you. An AI layer on a weak suite gives you faster explanations of the same gaps, so the plan always starts with the suite itself.
Every red build explains itself
AI Test Triage is a free GitHub Action we built and published. Add one step after your tests and, when a build fails, it reads the JUnit XML report and posts a comment on the pull request: each failing test, one of four labels (product bug, test bug, environment or flaky, unclear), a short explanation and a first thing to check. It never changes the build result, and without an API key it still lists the failures.
On a hand-written set of forty labelled failures it classified thirty-nine correctly, the same in three runs, including all ten tricky cases where the exception name points the wrong way. The cases were written by us, so treat that as an early test, not proof. The one it got wrong in every run was a test that waited the full timeout behind a spinner, which it read as a page change.
When the button moves, the test does not have to break
When a page changes and a test cannot find its button, a self-healing step reads the current HTML and proposes a replacement locator with a confidence score and a backup. Our open-source Selenium and TestNG framework does this, and the demo on this site lets you try the AI step with your own broken locator. On ten hand-written cases it found the right element every time; again, an early test, not proof.
The risk with self-healing is obvious: a test that quietly heals itself can hide a real change a person should have noticed. So every heal is logged with the old locator, the new one and the confidence, low-confidence heals fail the test instead of passing it, and healed locators are reviewed before they are written back into the suite.
Selenium or Playwright, and where the AI layer sits
If you already have a Selenium suite, we extend it rather than rewrite it; Selenium has the larger ecosystem and more engineers who know it. For a new project we usually suggest Playwright, which is faster to set up and handles modern web apps with less flakiness. Cypress, TestNG and JUnit are fine too. API tests sit underneath the browser tests: faster, more stable checks of the endpoints the UI depends on.
The AI layer is the same in every case. Triage works with anything that writes JUnit XML. Healing works at the locator level. Neither needs you to change frameworks, and both can be switched off with one line.
Your first week with us
We start with read-only access to your repository and CI and a look at what fails most and why. You get a one-page plan that separates tests worth automating now, flaky tests to fix or delete, and areas that should stay manual for now. The first pull request, with the reasoning written in it, usually arrives within the first week, and you review it like any other.
Standard hours are IST, which overlap with US Eastern and Central mornings. We shift the schedule further for teams on the West Coast when a project needs it. If you want the whole engagement explained, the page on outsourced QA for US teams covers it step by step.
Check our work before you call
Everything on this page can be checked before a call. The AI Test Triage Action and its example repository (four tests that fail on purpose and an open pull request showing the comment) are public on GitHub, as is the AI-augmented Selenium framework with self-healing locators. Both demos on this site call a live model. The build log records what broke on our own site and how it was fixed, including the day we shipped a demo with a retired model ID.
There are no client logos or results on this page, because we only publish those with a client's permission. What is here is work you can read and run.
If you want to try the triage on your own pipeline before any conversation, the five lines and the steps are in our build-log post on using AI Test Triage on your own repo. It runs only when tests fail, uses a small amount of API usage on your own key, and can be removed by deleting the step.
How it works
- Step 1Read-only access to your repository and CI, and a look at what fails most
- Step 2A one-page plan: what to automate, what to fix or delete, what to leave manual
- Step 3AI triage added to your pipeline, so every failed build explains itself on the pull request
- Step 4Self-healing added where locators break most, with every heal logged and reviewed
- Step 5A weekly rhythm of pull requests and short written reports, in your morning hours
Works with Selenium, Playwright, Cypress, TestNG and JUnit. The AI layer sits on top of your suite; it does not replace it.
See it working
Paste a failing test's error or stack trace; a live model returns the likely cause, a confidence and a fix. Inputs are logged, so do not paste secrets.
Paste a broken locator and the page's HTML; a live model proposes a replacement with a confidence score and a backup.
All demos. Every demo uses sample data, and the browser demos never send anything to a real phone.
Questions
Will AI write all our tests?
No. It can draft test cases from user stories and propose locators, which saves time, but a person decides what to test and reviews every test before it goes into the suite. A suite written entirely by AI tends to test what is easy rather than what matters.
Does self-healing hide real bugs?
It can, if it heals silently. That is why every heal is logged with the old and new locator and a confidence score, low-confidence heals fail the test, and healed locators are reviewed before they are saved. A real UI change still reaches a person.
Which frameworks and CI systems does it work with?
Selenium, Playwright, Cypress, TestNG and JUnit, and any runner that writes JUnit XML, which covers most Java, Python and JavaScript setups. The triage Action runs on GitHub Actions; the same approach works in Jenkins, GitLab or CircleCI.
Is our code sent to an AI provider?
The triage step sends the failure text and stack traces from the test report to the model, not your repository. It runs with your own API key, under your account's terms. For the demo on this site, inputs are logged, so do not paste secrets or customer data there.
How accurate is it?
On our own hand-written set of forty failures, triage was right on thirty-nine across three runs, and healing found the right element in ten of ten cases. Those are early tests, not proof; the honest answer for your suite comes from running it on your real failures, which is what the first week is for.
Related
Related reading
Next step
Want AI on your test suite?
A 20-minute call in your morning is enough to know if we can help. No pitch deck, no pressure.