Quand votre interface change, une partie des scénarios se répare seule. Le reste, vous le corrigez une fois et la correction se propage partout où le bloc est utilisé. C’est le point qui fait échouer la plupart des automatisations menées en interne.
Self-healing par IA Blocs réutilisables Hébergement dans l’UE
Personne ne regarde la maintenance au démarrage d’un projet d’automatisation. C’est pourtant là qu’il meurt. Un scénario qui casse à chaque évolution d’interface finit par être désactivé le temps de le reprendre, puis un deuxième, puis dix. La couverture s’effondre en silence, et le tableau de bord reste vert parce qu’il ne reste plus que les tests faciles.
Quand ça casse
Un scénario tombe un mardi matin. Voici les cinq écrans que vous traversez, dans l’ordre, jusqu’à ce qu’il repasse au vert.
1
Le scénario porte son étape en échec en clair, et le message exact renvoyé par le moteur. L’historique dit depuis quand ça dure, à quel rythme, et lesquelles de ces exécutions ont ouvert un incident. Personne n’a besoin de rejouer pour savoir de quoi on parle.
2
Un échec brut ne dit rien. L’incident, lui, porte sa cause et sa criticité, et il a été tranché : vrai positif ou faux positif. Il compte ses répétitions au lieu de les empiler, il sait quels scénarios il touche, et il ne se rouvre pas quatre fois pour la même raison.
3
C’est le self-healing. L’IA lit l’erreur, le bloc concerné, ses paramètres et le contexte de la page, puis propose des corrections classées par priorité et par effort. Chacune dit quel bloc insérer ou remplacer, et avec quel paramètre. Vous relisez, vous appliquez, ou vous écartez.
4
Suricapture rejoue le scénario sur votre machine, étape par étape, dans un vrai navigateur. Vous voyez l’échec se produire au lieu de le déduire d’un journal, et vous reprenez la main sur l’étape qui coince. En amont, la plateforme rejoue d’elle-même les échecs d’origine technique avant d’ouvrir le moindre incident.
5
La connexion, l’acceptation des cookies, la sélection d’un établissement : ces séquences reviennent dans presque tous vos parcours. Elles vivent dans un métabloc unique. Quand l’interface change, vous corrigez le métabloc, et tous les scénarios qui l’appellent repartent au vert ensemble.
Avant les outils de Mr Suricate, nous avions besoin d'une journée entière pour re-tester toutes les fonctionnalités du site après la livraison d'une nouvelle version. Aujourd'hui, cela ne prend que 10 minutes. En seulement 10 minutes, avec une quarantaine de scénarios critiques en pré-production, nous savons si tout est OK ou pas. Pour nous, c'est le meilleur argument : le gain de temps.
Michael AlimiDOSI, Intersport
ALLER PLUS LOIN
Chaque brique de la plateforme, de la création du scénario à la preuve de son exécution.
Un terme vous échappe ? Le glossaire du test automatisé le définit.
VOS QUESTIONS
Self-healing, blocs réutilisables, partage du travail : les réponses aux questions qui reviennent le plus souvent.
Quand un élément de votre interface change d'identifiant ou de position, la plateforme le retrouve à partir d'autres signaux et propose la correction, au lieu de sortir une erreur. Une partie des ruptures de sélecteur se répare donc sans intervention humaine.
Le scénario remonte en incident, avec l'étape en échec et la capture de ce que l'utilisateur aurait vu. Vous corrigez le bloc une fois, et la correction se propage partout où ce bloc est utilisé.
Vous arbitrez. La plateforme ne remplace pas votre équipe QA, elle la renforce. Nos équipes peuvent prendre tout ou partie du périmètre, et ce partage n'est pas figé dans le temps.
Une action répétée dans plusieurs scénarios, comme la connexion utilisateur ou la validation d'un panier, devient un bloc unique partagé. Modifié une fois, il met à jour tous les scénarios qui l'utilisent.
Le self-healing ne rattrape pas une refonte. C'est un cas de reprise de scénarios, et c'est l'un des motifs les plus fréquents de recours à nos équipes.
Une démo de 30 minutes sur votre propre application. Vous verrez un scénario se construire, casser, puis se réparer.