Tests automatisés : ce qu'ils apportent vraiment et leurs limites

Un test automatisé transforme un comportement attendu du système en vérification exécutable à volonté. Il transforme une attente en contrat. Quand ce contrat casse, l’équipe le voit vite. Cette promesse est souvent mal comprise et peut nourrir des attentes exagérées.

Sur un produit récent, construit avec un front riche et un backend exposé en API. La stratégie de test avait été posée dès le début du projet : tests unitaires, tests d’intégration, end-to-end, régression visuelle, tests de charge. Au bout de six mois, la base était très solide: plus de 1500 tests au total, dont environ 700 tests unitaires, 700 tests d’intégration et plus d’une centaine de tests end-to-end sur les parcours critiques.

Et pourtant, certains sprints se sont terminés avec de nombreux tickets rejetés. Comment est-ce possible avec un tel niveau d’automatisation ? Si les tests ne garantissent pas la qualité en fin de sprint, pourquoi y consacrer autant de temps ? Ces questions sont celles qu’ont posées les parties prenantes du projet à l’équipe technique.

La réponse tient dans le sens qu’on donne au mot qualité. Un produit de qualité n’est pas seulement un produit qui ne régresse pas. C’est aussi un produit conforme à l’intention, fluide, cohérent avec les règles métier et réellement utilisable. Les tests automatisés préservent ce qui fonctionne déjà, mais ils ne savent pas décider seuls si ce qui vient d’être livré est bon. Ils ne fabriquent pas la qualité produit, ils évitent qu’une qualité déjà validée se dégrade.

Les tests automatisés verrouillent l’état actuel du produit

Chaque test automatisé participe au verrouillage de l’état du produit :

• un test unitaire vérifie une règle métier ;
• un test d’intégration vérifie un contrat d’API ;
• un test end-to-end vérifie un parcours critique ;
• un test de régression visuelle vérifie un état attendu de l’interface ;
• un test de charge vérifie la performance du produit.

Les tests automatisés permettent la non-régression. C’est cette propriété intrinsèque qui les rend si utiles lorsqu’un produit évolue. Un produit vivant accumule des règles, des exceptions, des cas limites… Au bout d’un moment, la difficulté n’est plus seulement d’ajouter une fonctionnalité. C’est de l’ajouter sans casser une règle existante que l’on avait oubliée.

Sur le projet évoqué, les tests ont par exemple permis de faire remonter des oublis de règles métier ou de critères d’acceptation avant d’être livrés. C’est là que l’automatisation devient intéressante : elle ne remplace pas la réflexion, mais elle remet systématiquement certaines questions sur la table. À chaque livraison, la machine redemande : est-ce que ce parcours fonctionne encore ? est-ce que cette règle est toujours vraie ? est-ce que ce contrat d’API a changé ? est-ce que cette correction de bug tient toujours ? Un humain pourrait se poser ces questions, mais pas toujours avec la même régularité, surtout lorsque l’équipe est sous pression.

Ils sont donc aussi une forme de mémoire. C’est particulièrement vrai pour les corrections de bugs. Un bug corrigé sans test peut revenir. Un bug corrigé avec un test de non-régression a au moins laissé une trace exécutable de ce que l’équipe a appris. Ainsi l’automatisation ne sert pas seulement à vérifier du code : elle sert à capitaliser sur l’expérience du projet. Chaque bug important, chaque règle subtile, chaque parcours critique peut devenir un garde-fou pour la suite. C’est d’ailleurs pourquoi les tests les plus utiles ne sont pas toujours ceux qui augmentent le plus la couverture, ni forcément ceux auxquels on pense en premier quand on se demande quand automatiser est rentable.

Les tests automatisés ne garantissent pas la qualité livrée à eux seuls

La non-régression n’est qu’une condition de la qualité. Avoir l’ensemble des tests automatisés au vert ne suffit pas à dire que le produit est agréable à utiliser. Cela ne dit pas non plus que le produit est conforme à la spécification. Cela signifie simplement que ce que l’on a demandé à la machine de vérifier fonctionne encore.

La QA manuelle reste essentielle — c’est le coeur de notre approche QA, peu importe qui la réalise : est-ce que ce qui a été développé est conforme à la spécification ? est-ce que cela fonctionne pour un utilisateur réel ? Le contrôle manuel permet de détecter les ambiguïtés, les lenteurs, les incohérences, les frictions, les choses qui “fonctionnent” techniquement mais qui restent mauvaises à l’usage. Ainsi, l’automatisation et la QA manuelle sont complémentaires et ne peuvent se substituer l’une à l’autre.

La QA manuelle valide l’expérience et l’intention. Les tests automatisés gardent ensuite cette validation contre les régressions. Si l’on inverse l’ordre, on risque d’automatiser du provisoire. Si l’on supprime la première étape, on peut obtenir un produit très testé, mais médiocre.

Tests automatisés vs QA manuelle : que vérifie chaque approche ?

La frontière n’est donc pas entre “qualité automatisée” et “qualité manuelle”, mais entre ce qui peut être formulé comme une vérification explicite et ce qui demande encore une appréciation produit, métier ou design.

Tests automatisés et QA manuelle à l’heure de l’IA

Une suite de tests, même massive, ne permet pas de dire que le produit livré est bon. Elle dit seulement que les comportements qu’on a pris le temps de décrire restent vrais. L’automatisation prend le relais après la QA manuelle : une fois qu’un comportement a été validé, elle empêche qu’il se dégrade silencieusement.

La validation humaine doit précéder l’automatisation : automatiser toute la QA est illusoire. Une machine ne peut protéger que ce que l’équipe a d’abord jugé bon.

A l’heure de l’intelligence artificielle, la question du goût est prépondérante. L’IA permet des gains certains sur le volet de l’automatisation, donc de la non-régression, car elle accélère à un niveau inégalé la production des tests. C’est un très bon investissement car constitue des fondations à haute valeur ajoutée pour tout produit. Mais l’automatisation ne remplacera en rien la revue humaine, subjectivité nécessaire pour déterminer si un produit est bon ou non.