Va-t-il être rejoué ?
Un test joué deux fois par an ne rentabilisera jamais son écriture ni sa maintenance. Un test de non-régression joué à chaque livraison, oui.
Automatisation des tests
L’automatisation ne remplace pas la recette : elle libère du temps de cerveau en reprenant ce qui est répétitif, stable et vérifiable sans jugement. Le reste reste humain, et c’est une bonne nouvelle.
Prendre rendez-vousLe tri
Un test joué deux fois par an ne rentabilisera jamais son écriture ni sa maintenance. Un test de non-régression joué à chaque livraison, oui.
« Le montant affiché est-il 12,90 € ? » s'automatise. « L'écran est-il clair ? » ne s'automatise pas, et ne doit pas l'être.
Automatiser un écran qui change toutes les semaines, c'est financer une maintenance permanente. On attend qu'il se pose.
Ce tri fait, il reste en général 60 à 70 % des cas d’une campagne de non-régression — et c’est exactement la partie qui épuise les équipes et qu’on sacrifie en premier quand les délais se resserrent.
Ce qui tient dans le temps
La plupart des projets d’automatisation ne meurent pas d’un défaut technique, mais de leur coût de maintenance.
Trois choix décident de la durée de vie d’une base automatisée. L’ancrage des éléments : des identifiants stables posés dans l’application plutôt que des chemins fragiles qui cassent au premier changement de mise en page. La séparation entre le scénario et la technique — le modèle Page Object — pour qu’un changement d’écran se corrige à un seul endroit. La maîtrise des données : un jeu d’essai reconstruit à l’identique, sinon les échecs deviennent aléatoires et plus personne ne lit les rapports.
Le vrai indicateur de santé n’est pas le nombre de tests automatisés, c’est le temps passé chaque semaine à les réparer. Nous le mesurons dès le premier mois.
Les outils
Selenium, Cypress, Playwright — selon ce que vos équipes savent déjà maintenir, pas selon nos préférences.
Appium pour les applications, et la vérification par interface applicative quand elle est plus fiable que l'écran.
Client lourd, borne, écran industriel : quand aucun outil ne mord, nous écrivons l'automate qui manque.
Ce que ça change
Ce que ces chiffres permettent réellement : livrer plus souvent sans réduire la couverture, vérifier en totalité ce qu’on ne vérifiait que par échantillon, et rendre aux testeurs le temps d’aller chercher les défauts qu’aucun script ne trouvera jamais.
Questions franches
Par les parcours critiques joués à chaque version : connexion, commande, paiement. Une dizaine de cas bien choisis rendent déjà service et servent de socle. Commencer par vouloir tout couvrir est la façon la plus sûre de ne rien livrer.
Quelqu'un doit pouvoir corriger un test qui casse. Ce peut être un testeur formé, pas nécessairement un développeur. Nous formons vos équipes pendant le projet plutôt qu'après, et nous documentons en français.
Les premiers scénarios tournent en deux à trois semaines. Le retour se voit à la deuxième ou troisième campagne de non-régression : c'est là que le temps gagné dépasse le temps investi. Avant, c'est un investissement, et il faut le dire comme tel.
Elle écrit un premier jet de cas, maintient les sélecteurs, trie les échecs et compare en masse. Elle ne décide pas ce qui mérite d'être testé. Nous la faisons tourner en delivery depuis deux ans : ce qui a changé, c'est le volume qu'un consultant couvre en une journée, pas la nature du métier.
Un audit de votre démarche de test, sans engagement, pour savoir où vous en êtes vraiment.
Prendre rendez-vous
French 
English 
Hebrew