Types de tests

Tests de non-régression : livrez sans casser l'existant

À chaque livraison, la question est la même : est-ce que ce qui marchait hier marche encore ? La non-régression automatisée y répond en quelques minutes, sur l’ensemble de vos parcours, avant la mise en production.

15× moins de temps de TNRWeb, mobile et APISans écrire de code

Campagne de non-régression dans Mr Suricate, avec le taux de succès après rejeu de chaque lancement

Ils nous font confiance

3 M exécutions de scénarios par mois100+ clients15 types de tests couverts

Retail, banque, industrie, transport, services. Hébergement dans l’Union européenne, support francophone, accompagnement humain au démarrage.

En bref

Un test de non-régression rejoue les parcours qui marchaient déjà, pour vérifier qu'une nouvelle version ne les a pas cassés. On ne cherche pas la nouveauté, on protège l'existant. Automatisé, il transforme une campagne de plusieurs jours en une exécution de quelques minutes, avant chaque mise en production.

TNR, régression, campagne de test : les définitions sont dans le glossaire QA.

Ce n'est jamais la nouveauté qui casse, c'est ce qu'on n'a pas retesté

Une évolution du panier, et c’est le code promo qui ne s’applique plus. Le lien entre les deux n’était évident pour personne. La non-régression est la discipline la plus utile et la première qu’on abandonne, parce que rejouer cent parcours à la main avant chaque mise en ligne ne tient dans aucun planning. Automatisée, la campagne complète repasse à chaque release sans mobiliser l’équipe.

Toute la campagne, à chaque release

Pas une sélection faite dans l’urgence. L’ensemble des parcours déjà validés repasse avant chaque mise en production.

Un verdict avant la mise en ligne

Un scénario en échec peut bloquer votre déploiement. La décision se prend sur un résultat, pas sur une intuition.

L'écart, pas seulement l'erreur

Capture d’écran, étape exacte, données utilisées. Vous voyez ce qui a changé, pas seulement que quelque chose a changé.

Une maintenance qui ne vous mange pas

Le self-healing répare une partie des ruptures, et un bloc modifié met à jour tous les scénarios qui l’utilisent.

La campagne part de votre pipeline, pas d'un tableur

Votre campagne se déclenche à chaque merge, tourne sur vos environnements de recette et remonte les écarts dans les outils de vos équipes. Rien à réoutiller.

1 Déclenchement Vos outils gardent la main

GitLab
Jenkins
Microsoft Azure
Appel API
Planification

2 Exécution

vos scénarios tournent sur vos environnements réels

Parcours web
Applications natives iOS et Android
Fermes de mobiles réelles
API et flux internes

3 Restitution Le résultat arrive où vous travaillez

Jira
Slack
SMS
Webhook
API

Et une maintenance qui tient dans le temps

Blocs réutilisablesune modification met à jour tous les scénarios qui l'utilisent
Réparation assistée par IAdes correctifs proposés sur les scénarios en erreur
Regroupement des incidentsles anomalies similaires sont traitées une seule fois

Ce que change l'automatisation, ligne par ligne

Non-régression manuelleAvec Mr Suricate

Non-régression manuelle

Avec Mr Suricate

Une journée de tests avant chaque mise en production.

La même campagne tourne en une dizaine de minutes.

On réduit le périmètre quand la date approche.

Le périmètre ne bouge pas, quelle que soit la date.

Les régressions se découvrent après la mise en ligne.

Elles se découvrent avant, et peuvent bloquer le déploiement.

Personne ne veut reprendre la campagne du trimestre dernier.

Les blocs réutilisables se mettent à jour en une seule fois.

Le résultat tient dans un fichier partagé.

Chaque exécution est tracée, horodatée et comparable.

Le rythme de livraison est limité par la capacité de la QA.

Vous livrez plus souvent, avec la même équipe.

Résultat15× moins de temps passé en non-régression, et environ 50 % de bugs en moins en production.

Ce que la non-régression couvre

L’ensemble des parcours déjà validés, rejoués à chaque livraison

Un verdict avant la mise en ligne, qui peut bloquer le déploiement

Le taux après rejeu, qui mesure la stabilité release après release

L’écart montré, pas seulement l’erreur : capture, étape exacte, données utilisées

Le même cahier de tests que la recette, sans double entretien

Ce que ce n'est pas

Le test des nouveautés de la release, qui demande ses propres scénarios

Un test unitaire ou d’intégration, qui se joue côté code

Un audit de couverture de votre patrimoine de tests

Un tir de charge, qui mesure la tenue et non le comportement

Non-régression (TNR), régression, faux positif : les définitions sont dans le glossaire QA.

LIVRE BLANC · AUTOMATISATION DES TESTSEt si vos bugs ne coûtaient plus rien à votre business ?Pourquoi les campagnes de non-régression manuelles finissent par céder, et comment bâtir une automatisation qui tient dans la durée.

Télécharger le livre blanc

“ 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

Qui écrit la campagne, qui la maintient : vous décidez

Avec Mr Suricate, votre équipe QA n’est pas remplacée, elle est renforcée. Vous choisissez ce que vous internalisez et ce que vous déléguez : la constitution de la campagne, son exécution à chaque release, ou sa maintenance quand l’application évolue.

1Identification des parcours critiques, front et back
2Écriture des tests, sans code
3Supervision continue et alertes
4Maintenance et évolution des scénarios

Résultatvous gagnez en couverture sans alourdir la charge de vos équipes. Et si vous préférez tout déléguer, l'externalisation QA prend le relais.

ALLER PLUS LOIN

Les autres types de tests

Quinze types de tests, quatre familles. Chacun répond à une question différente sur votre application.

Tests fonctionnelsVérifier qu'une fonctionnalité produit bien le résultat attendu, du point de vue de l'utilisateur.En savoir plus Tests end-to-endLe parcours complet, d'un bout à l'autre de la chaîne, y compris les systèmes tiers et les back-offices.En savoir plus Tests d'APILes échanges entre vos services, testés directement, sans passer par l'interface.En savoir plus Tests de performanceLe temps de réponse réel de vos parcours, mesuré en continu et comparé à vos seuils.En savoir plus Tests graphiquesLa comparaison visuelle pixel par pixel, pour les changements qu'aucune assertion ne détecte.En savoir plus Tests de data layerLes événements envoyés à votre plan de taggage, vérifiés à chaque étape du parcours.En savoir plus Tests de sécuritéVérifier ce qu’un utilisateur peut réellement atteindre : droits par profil, sessions, authentification, HTTPS.En savoir plus Les 15 types de testsLa vue d'ensemble : quatre familles, quinze types, et par quoi commencer selon votre situation.En savoir plus

Un terme vous échappe ? Le glossaire du test automatisé le définit.

VOS QUESTIONS

Questions fréquentes

Ce que les équipes QA nous demandent le plus souvent sur la non-régression.

Qu'est-ce qu'un test de non-régression ?

C'est le fait de rejouer des scénarios déjà validés pour vérifier qu'une évolution du produit n'a rien cassé ailleurs. On ne teste pas la nouveauté, on teste tout ce qui existait avant et qui doit continuer de fonctionner.

À quelle fréquence faut-il lancer une campagne ?

Avant chaque mise en production au minimum. Beaucoup d'équipes vont plus loin et déclenchent la campagne à chaque intégration, ou la planifient chaque nuit, pour que l'écart se voie le jour même plutôt qu'à la release suivante.

Combien de temps prend une campagne automatisée ?

Une campagne d'une centaine de scénarios se joue en une dizaine de minutes, les exécutions étant menées en parallèle. Là où une campagne manuelle mobilisait une journée d'équipe, la contrainte de planning disparaît.

Qui maintient les scénarios quand l'application évolue ?

Vous choisissez. Le self-healing répare automatiquement une partie des ruptures, un bloc réutilisable modifié une fois se propage à tous les scénarios, et ce qui reste peut être traité par vos équipes ou délégué aux nôtres.

Un test en échec peut-il bloquer une mise en production ?

Oui. Le résultat de la campagne peut être remonté à votre chaîne d'intégration par API, et un échec sur un scénario critique peut interrompre le déploiement avant qu'il n'atteigne vos utilisateurs.

Comment choisir les scénarios à mettre dans la campagne ?

On part des parcours critiques, front et back, et on priorise par impact : ce qui touche au chiffre d’affaires, ce qui est réglementaire, ce qui a déjà cassé. Une campagne utile est une campagne courte que l’on fait tourner souvent.

Que faire des tests instables, les fameux flaky ?

On cherche la cause avant de relancer. Un test instable vient le plus souvent d’une attente mal posée ou d’un sélecteur fragile, pas du hasard. La réparation assistée par IA propose un correctif, et un test qu’on relance à l’aveugle finit par ne plus rien prouver.

Faut-il un environnement dédié ?

Non. La campagne tourne sur vos environnements existants, recette, pré-production ou production selon le scénario. Les variables et les jeux de données se déclarent par environnement, sans dupliquer le scénario.

Combien de temps pour automatiser une campagne existante ?

Cela dépend du nombre de scénarios et de leur complexité, mais l’absence de code change l’échelle : on parle de semaines de construction, pas d’un projet de développement à part entière.

Vous ne croyez que ce que vous voyez ?

Une démo de 30 minutes sur votre propre application. Vous verrez un de vos parcours automatisé en direct, sans écrire de code.