Les tests automatisés sont de petits programmes qui vérifient, à chaque modification du code, que l’application continue de produire les résultats attendus : un calcul de remise, un contrôle de droits, l’envoi d’une commande à l’ERP. Ils s’exécutent en quelques minutes, sans intervention humaine, et bloquent la mise en production si quelque chose a cassé. Pour une entreprise, ils protègent l’investissement : sans eux, chaque évolution devient plus risquée et plus lente que la précédente ; avec eux, l’application peut évoluer pendant des années à un rythme soutenu.
Ce guide explique ce que sont les tests automatisés, comment les répartir selon la pyramide des tests, et quelles questions poser à votre prestataire.
Que se passe-t-il dans une application sans tests automatisés ?
Prenons une entreprise de négoce qui fait développer un outil de devis. La première version fonctionne, les commerciaux l’adoptent. Six mois plus tard, on ajoute une remise par volume. Le développeur modifie le module de calcul, vérifie que la nouvelle remise fonctionne, et livre. Ce qu’il n’a pas vérifié : les devis en devise étrangère, qui utilisent le même module, affichent désormais un mauvais total. Personne ne s’en aperçoit pendant deux semaines.
Ce scénario porte un nom : une régression, c’est-à-dire un dysfonctionnement introduit dans une fonctionnalité qui marchait. Sans tests automatisés, la seule protection est de tout revérifier à la main à chaque version. C’est rapidement impossible : une application métier compte des centaines de règles et de cas particuliers.
L’équipe a alors deux options, toutes deux coûteuses :
- ralentir : espacer les versions, multiplier les vérifications manuelles, hésiter à toucher au code ;
- prendre le risque : livrer vite, et découvrir les régressions en production, chez les utilisateurs.
C’est l’un des mécanismes principaux de la dette technique : le code devient fragile, chaque modification coûte plus cher, et l’application finit par être perçue comme impossible à faire évoluer.
Qu’est-ce qu’un test automatisé, concrètement ?
Un test automatisé décrit une situation, déclenche une action et vérifie le résultat. Par exemple : « Étant donné un client avec une remise contractuelle de 10 % et une commande de 120 unités, quand on calcule le devis, alors la remise par volume s’applique en plus et le total est celui attendu. » Ce test s’exécute en une fraction de seconde, des milliers de fois dans la vie du projet.
Les tests sont lancés automatiquement par une chaîne d’intégration continue : chaque modification proposée par un développeur déclenche l’exécution de toute la suite de tests. Si un test échoue, la modification ne peut pas être intégrée tant que le problème n’est pas corrigé. La régression de l’exemple précédent aurait été détectée en quelques minutes, avant d’atteindre un seul utilisateur.
Ham Vocke le résume dans un article de référence sur la pyramide des tests, publié sur le site de Martin Fowler : une bonne stratégie de tests permet aux équipes d’aller vite et en confiance. Une fois les tests automatisés, on peut modifier le code sans crainte.
La pyramide des tests : quels tests, en quelle proportion ?
Tous les tests ne se valent pas. Certains sont rapides et précis, d’autres lents mais proches de l’usage réel. La pyramide des tests, popularisée par Mike Cohn dans son livre Succeeding with Agile (2009) et reprise par Martin Fowler, décrit l’équilibre à viser.
| Niveau | Ce qu’il vérifie | Vitesse | Proportion |
|---|---|---|---|
| Tests unitaires (base) | Une règle ou une fonction isolée : un calcul, une validation, un contrôle de droits | Millisecondes | La grande majorité |
| Tests d’intégration (milieu) | Le dialogue avec la base de données, une API, un outil externe | Secondes | Une part intermédiaire |
| Tests de bout en bout (sommet) | Un parcours complet dans l’interface, comme le ferait un utilisateur | Secondes à minutes | Un petit nombre, sur les parcours critiques |
Pourquoi cette forme ? Les tests de bout en bout sont rassurants, car ils reproduisent l’usage réel. Mais ils sont lents, coûteux à maintenir et sujets à des échecs aléatoires. Quand ils échouent, ils indiquent qu’il y a un problème, sans dire où. Les tests unitaires, eux, désignent précisément la règle en défaut.
Sur le blog de test de Google, Mike Wacker propose comme première approximation une répartition de 70 % de tests unitaires, 20 % de tests d’intégration et 10 % de tests de bout en bout, en précisant que le bon dosage varie selon les équipes mais que la forme pyramidale doit être conservée.
Le contre-modèle s’appelle le cornet de glace : une suite composée surtout de tests manuels ou de tests de bout en bout, avec très peu de tests unitaires. Il donne une impression de sécurité, mais chaque exécution prend des heures et les échecs sont difficiles à interpréter.
Que faut-il tester en priorité dans une application métier ?
Toutes les lignes de code n’ont pas la même importance. Dans une application métier, les tests doivent couvrir en priorité ce qui coûte cher quand c’est faux.
- Les règles de calcul : prix, remises, taxes, délais, stocks, primes. Une erreur y a un impact financier direct.
- Les droits d’accès : qui peut voir, modifier, valider. Une erreur y est une faille de sécurité, sujet que nous détaillons dans notre article sur la sécurité des applications web.
- Les transitions d’état : une commande ne peut pas passer de « brouillon » à « facturée » sans être validée.
- Les échanges avec les autres outils : format des données envoyées à l’ERP, traitement des réponses d’erreur, reprise après coupure.
- Les parcours critiques de bout en bout : créer une commande, clôturer une intervention, émettre une facture.
- Chaque anomalie corrigée : on écrit d’abord un test qui reproduit l’anomalie, puis on la corrige. Elle ne reviendra plus.
Ce dernier réflexe correspond à l’une des règles proposées par Ham Vocke : si un test de haut niveau détecte une erreur qu’aucun test de plus bas niveau n’a repérée, il faut écrire ce test de plus bas niveau.
Tests automatisés et recette : quelle différence ?
Les deux sont complémentaires et ne répondent pas à la même question.
| Tests automatisés | Recette | |
|---|---|---|
| Qui | L’équipe de développement | Les utilisateurs et le référent métier |
| Question | Le code fait-il ce qu’on lui a demandé, et le fait-il toujours ? | L’outil répond-il au besoin réel ? |
| Fréquence | À chaque modification, plusieurs fois par jour | À chaque livraison ou avant la mise en production |
| Ce qu’elle détecte le mieux | Régressions, erreurs de calcul, cas limites | Malentendus sur le besoin, problèmes d’ergonomie |
La recette est le dernier contrôle, pas le premier. Une équipe qui livre en recette du code non testé transforme les utilisateurs en testeurs, avec une perte de temps et de confiance des deux côtés. À l’inverse, une recette qui valide un comportement crée l’occasion d’écrire un test qui le protégera durablement.
Les signes d’une stratégie de tests saine
Le programme de recherche DORA, qui étudie la performance des équipes de livraison, associe l’automatisation des tests à des livraisons plus stables et moins pénibles. Il donne plusieurs repères concrets :
- un retour rapide : les développeurs doivent obtenir le résultat des tests automatisés en moins de dix minutes ;
- des tests fiables : un test instable, qui échoue parfois sans raison, ne doit pas être toléré ;
- la qualité plutôt que la quantité : une suite de dix tests fiables, rapides et dignes de confiance vaut mieux qu’une grande suite à laquelle personne ne croit ;
- des développeurs impliqués : ce sont eux qui écrivent et maintiennent les tests, pas une équipe séparée ;
- des échecs significatifs : quand un test échoue, c’est qu’il y a un vrai défaut.
Les questions à poser à votre prestataire
Les tests sont invisibles pour l’utilisateur, ce qui les rend faciles à sacrifier quand le planning se tend. Voici comment vérifier qu’ils font bien partie du projet :
- Quelle part de l’effort de développement est consacrée aux tests automatisés ?
- Quelles règles de gestion sont couvertes par des tests explicites ?
- La chaîne d’intégration continue bloque-t-elle une livraison quand un test échoue ?
- Combien de temps dure l’exécution complète des tests ?
- Les tests sont-ils livrés avec le code source, dans le dépôt qui nous appartient ?
- Que se passe-t-il quand une anomalie est corrigée : un test est-il ajouté ?
Cette question figure aussi dans notre liste pour choisir une agence de développement. Les réponses comptent d’autant plus que les tests conditionnent le coût de la maintenance et de la TMA pendant toute la vie de l’application, et qu’ils facilitent la reprise du code par une autre équipe si vous changez de prestataire.
Chez Hexora, les tests automatisés font partie de la définition de « terminé » de chaque fonctionnalité, comme le décrit notre méthode. Vous voulez faire le point sur la robustesse d’une application existante, ou cadrer un nouveau projet sur de bonnes bases ? Décrivez votre situation dans notre diagnostic de projet : il prend deux minutes.
