When failures come from selectors, not from the product, people learn to re-run and ignore. Then a real regression looks the same as the noise.
For QA engineers and SDETs
The build is red again, and nothing is actually broken.
A front-end release renames a class or moves a container, and tests fail on selectors that no longer match. Someone spends the morning fixing locators, and the next red build gets less trust than the last. This is how CertiQA keeps those failures from burying the real ones.
| Step | From | To | Tier |
|---|---|---|---|
| Click "Place order" | #submit-order-btn | TESTID:checkout-submit | DATA_TESTID |
| Type into "Email" | div.form > div:nth-child(2) input | ROLE:role=textbox[name="Email"] | ARIA_ROLE |
Example data. Mirrors the Self-Heal Events table in a run report, without the Score and Time columns.
What this looks like day to day
Four things that wear down a UI test suite.
None of these are about the tests being badly written. They are what happens to any browser suite while the product keeps changing.
Tests were written against generated class names or deep paths. The page behaves the same for a user, but the locator no longer finds anything.
Describing a flow in code takes longer than clicking through it. Teams put it off, and coverage trails the product.
Tests locked in a vendor format are a risk. You want to know you can take them to your own repository and run them without us.
How CertiQA helps
Each problem has a specific answer.
Repair locator drift, and show every repair
Each step keeps a ranked list of ways to find its element. When the first no longer resolves, CertiHeal works down a fixed order: a test id, an ARIA role, visible text, then nearby stable elements. It stops at the first visible, relevant match that clears a minimum confidence score. An optional fifth tier asks a vision model, and only runs after the local four have missed and AI healing is enabled.
The run report lists each repair in a Self-Heal Events table, with the old locator, the new one, and the tier that found it. A repair from a test id tells you less than one from the vision model, and the table lets you tell them apart. Self-healing can be switched off in Settings.
A repair needs a visible, relevant element. If the element is genuinely gone or the page is wrong, the step still fails. CertiQA records the repair and does not rewrite your case, so a deliberate redesign is a decision for you.
In the product
- A candidates button on each step lists its fallback locators, and you can switch the active one.
- A heal count on the run, and the Self-Heal Events table.
- Frontend test ids and ARIA roles keep repairs in the cheap local tiers.
Record a flow instead of describing it
Install the Chrome or Edge extension, open your application and choose Record Steps on a case. Walk through the flow as a user would, inside your own signed-in browser session. Each click, entry and navigation is resolved against the live page and saved as a step with several locator candidates, so a recorded step is not a bare coordinate.
Stop recording and the steps arrive in your project as an editable case.
A recording is a first draft. It captures what you did, not what you meant to check, so add assertions where it only recorded a click. During early access the extension is provided on request.
You get
- Steps in the same editor as hand-built cases.
- Works behind a login, because it uses your own session.
- A separate Import Script option if you already have Playwright, Cypress, Selenium or Postman files.
Take your tests with you
Open a case's tools menu and choose Export Script. CertiQA generates an ordinary @playwright/test file you can download as .spec.ts or copy, with options for step comments, network mocks and environment variables. Run it with npx playwright test.
Vault secrets and API keys become process.env lookups, so they are not written into the file. Set those variables wherever the file runs.
The export is plain Playwright with each step's top-ranked locator. It does not heal, so a changed selector fails there the way it would in any Playwright project.
import { test, expect } from '@playwright/test';
test('Guest checkout', async ({ page }) => {
await page.goto('https://shop.acme.test/checkout');
await page.getByTestId('email-input')
.fill(process.env["CHECKOUT_EMAIL"] ?? '');
await page.getByRole('button', { name: 'Place order' })
.click();
await expect(page.getByText('Order Received'))
.toBeVisible();
});Run on the browsers your users have
Pick Chromium, Firefox or WebKit in the run panel. The same case runs on each, and the report keeps one run per browser, so a failure that only appears on WebKit is not hidden inside a green Chromium run. A project can also set a default device preset for phone and tablet viewports.
Running every suite on every browser adds time. Many teams keep per-commit runs to one browser and use the others nightly.
Related
Shared steps such as login live in one place: reusable test blocks. Mixed web, API and agent cases are covered under AI agent testing.
FAQ
Questions QA engineers ask about UI automation
How do I stop Playwright tests from breaking when the UI changes?
Give each step more than one way to find its element. CertiQA keeps ranked locator candidates per step. When the first one no longer resolves, CertiHeal tries a test id, then an ARIA role, then visible text, then nearby stable elements, and uses the first visible, relevant match. The run report lists every repair so you can see what moved.
Will self-healing hide real bugs?
It is meant for locator drift, such as a renamed class or a moved container. A repair needs a visible element that is relevant to the step and clears a minimum confidence score. If the button is gone or the page is wrong, the step still fails. A repair is still worth a look: a deliberate redesign that removed the element is something to fix in the test, not paper over.
How do I see what was healed in a run?
Open the run report. When a run healed anything, it shows a count of heals and a Self-Heal Events table with the step, the old locator, the new locator, the strategy, the tier that produced it and a score. CertiQA records the repair and does not rewrite your case on its own.
Can I export CertiQA tests to Playwright TypeScript?
Yes, one test case at a time. Open the case's tools menu, choose Export Script and download the .spec.ts file or copy the code. Run it with npx playwright test. Vault secrets and API keys are written as process.env lookups, so set those variables wherever you run the file. The export is plain Playwright using each step's top-ranked locator. It does not include CertiHeal.
Can I import my existing Playwright, Cypress or Selenium tests?
Yes. In Test Suites choose Import Script and upload the files. Playwright, Cypress and Postman collections go through a deterministic parser. Selenium (Java and Python) and Protractor scripts are translated by an LLM. Each import gets a fidelity grade and per-line warnings for anything it could not map, such as a custom command or a page-object helper. Imported selectors keep working but do not start with extra locator candidates, so repairs have less to choose from.
Which browsers can tests run on?
Chromium, Firefox and WebKit. Choose the browser in the run panel when you run a suite. To cover several, run the suite once per browser and the report keeps each run separate. A project can also set a default device preset to run on an emulated phone or tablet viewport.
Can I record a test instead of writing it?
Yes. With the Chrome or Edge extension installed, open your application, start recording from the case, and walk through the flow. Clicks, typing and navigation become steps in an editable case. Treat the result as a first draft and add assertions where the recording only captured a click. During early access the extension is provided on request.
Can one test case run against many rows of data?
Yes. Upload an Excel or CSV file as a dataset and run the case against its rows, instead of copying the case for each set of values.
Start with the suite that fails the most.
Import it or record the flow, run it, and read the Self-Heal Events table to see how much of the noise was locators.