Features

Maintain your tests without spending weeks on them

When your interface changes, some of the scenarios fix themselves. For the rest, you make a one-time correction, and that correction is applied everywhere the block is used. This is the reason why most in-house automation efforts fail.

AI-powered self-healing Reusable blocks Hosting in the EU

The maintenance assistant displays the detected error, the step and block involved, and suggests the appropriate corrective action

Maintenance—that's where automation projects come to a halt

No one pays attention to maintenance when an automation project gets underway. Yet that’s where it dies. A scenario that breaks with every interface update eventually gets disabled until it can be fixed—then a second one, then ten. Test coverage quietly collapses, and the dashboard stays green because only the easy tests remain.

When it breaks

What Happens Between Failure and Correction

A scenario pops up on a Tuesday morning. Here are the five screens you'll go through, in order, until it turns green again.

1

You can tell right away where it broke

The script clearly shows which step failed and the exact message returned by the engine. The log shows how long this has been going on, how often it occurs, and which of these runs triggered an incident. No one needs to replay the process to know what we’re talking about.

  • The incorrect step, numbered, at the top of the worksheet
  • The engine error message, as is
  • Each execution, along with its trigger—whether scheduled or automatic
  • The link to the incident, if there is one
  • Screenshot and video of the scene
The execution history of a failed scenario, showing the step that caused the error and the error message repeated
The execution history of a failed scenario

2

The incident is classified, not just reported

A raw failure tells us nothing. The incident, on the other hand, carries its own cause and severity level, and it has been classified as either a true positive or a false positive. It counts its occurrences rather than piling them up; it knows which scenarios it affects; and it does not reopen four times for the same reason.

  • Cause and Severity Specified
  • True positive or false positive, clearly defined
  • Reproductive stages, observed and expected behavior
  • Repetitions counted, not stacked
  • The relevant scenarios associated with this
An incident report, including its reproduction steps, status, origin, classification, and cause
An Incident and Its Classification

3

The assistant suggests a correction

That’s self-healing. The AI analyzes the error, the affected block, its parameters, and the page context, then suggests corrections ranked by priority and effort. Each suggestion specifies which block to insert or replace, and with which parameter. You review them, apply the changes, or discard them.

  • Corrections Sorted by Priority and Effort
  • The exact block to insert or replace
  • The parameter to use, ready to copy
  • The decision is still up to you
The maintenance wizard suggests five solutions, ranked by priority, along with the module and setting to use
Corrections suggested by the assistant

4

You can play again, on your computer and on your own terms

Suricapture replays the scenario on your machine, step by step, in a real browser. You see the failure happen instead of inferring it from a log, and you can take control of the step that’s causing the problem. Before opening any incidents, the platform automatically replays technical failures on its own.

  • Play it locally, right in your browser, right before your eyes
  • Pause at the step that’s causing trouble to correct it manually
  • Automatic replay in the event of a technical error, before any alert is triggered
  • Environment, dataset, and resolution of your choice
Suricapture replays a scenario step by step in a browser, using the "Test" button
Replaying a scenario from Suricapture

5

The metablock—corrected once, propagated everywhere

Logging in, accepting cookies, selecting a location: these steps recur in almost all of your user journeys. They’re contained within a single metablock. When the interface changes, you update the metablock, and all the scenarios that call it are automatically brought back up and running together.

  • A block written once, called from anywhere
  • One correction; all scenarios are up to date
  • Web, iOS, and Android in the same library
The library of reusable metablock, named in French
The Metablock Library

What Self-Healing Changes, Line by Line

Without self-healing
With Mr Suricate
A selector changes, and the script encounters an error.
Some breaks heal on their own.
Each error is analyzed manually, one by one.
Errors with the same cause are grouped together.
The user connection is rewritten in each scenario.
A modified block updates all scenarios.
Scenarios that are too costly to maintain are disabled.
Coverage remains stable over time.
The drop in coverage isn't visible anywhere.
The discrepancy is evident in the report.
Maintenance is entirely the responsibility of the QA team.
You choose what to delegate.
ResultAbout one hour of maintenance saved per scenario per month, and coverage that doesn't collapse at the first interface change.
Before we started using Mr Suricate tools, it took us an entire day to retest all the site’s features after a new version was released. Now, it only takes 10 minutes. In just 10 minutes, using about 40 critical test scenarios in pre-production, we know whether everything is OK or not. For us, that’s the best selling point: the time savings.

Michael AlimiDOSI, Intersport

YOUR QUESTIONS

Questions We Get Asked About Maintenance

Self-healing, reusable blocks, load balancing: answers to the most frequently asked questions.

What exactly is self-healing?

When an element in your interface changes its identifier or position, the platform identifies it based on other signals and suggests a correction, rather than displaying an error. As a result, some selector mismatches are resolved without human intervention.

What happens when the AI can't find the correct answer?

The scenario is logged as an incident, with the failed step and a screenshot of what the user would have seen. You fix the block once, and the fix is applied everywhere that block is used.

Who maintains the tests when the application changes?

You're in charge. The platform doesn't replace your QA team—it enhances it. Our teams can handle all or part of the scope, and this division of labor isn't set in stone.

Reusable blocks—what exactly are they used for?

An action that is repeated across multiple scenarios—such as user login or checkout—becomes a single shared block. When modified once, it updates all scenarios that use it.

How about a complete redesign of the interface?

Self-healing isn't a substitute for a redesign. It's a matter of recovering from scenarios, and it's one of the most common reasons people turn to our teams.

Do you only believe what you see?

A 30-minute demo of your own app. You'll see a scenario take shape, break down, and then be fixed.