Un bouton « Valider » qui envoie un formulaire vide, un panier e-commerce qui affiche un prix négatif, une page qui met dix secondes à charger sur mobile : chaque bug découvert en production coûte bien plus cher qu’un bug détecté pendant le développement. Les types de tests en informatique existent pour intercepter ces défauts le plus tôt possible, à différents niveaux du logiciel.
Pourquoi un seul type de test ne suffit pas
Imaginons une application de réservation de billets de train. Le code qui calcule le prix d’un trajet peut fonctionner parfaitement quand on le teste isolément. Connecté au module de paiement, il peut pourtant générer une erreur si les deux composants n’échangent pas le bon format de données.
Lire également : Comment avoir internet sans box gratuitement ?
Et même si le calcul et le paiement fonctionnent ensemble, l’utilisateur final peut se retrouver bloqué parce que le bouton « Payer » n’est pas visible sur un petit écran. Chaque type de test cible une couche différente du logiciel. Ignorer l’une de ces couches, c’est laisser une porte ouverte aux régressions.
Les équipes de développement organisent donc leurs tests en niveaux complémentaires, du plus petit morceau de code jusqu’au parcours complet de l’utilisateur.
A lire également : Quel est le principe du cloud ?
Tests unitaires : vérifier chaque brique de code isolément
Le test unitaire cible la plus petite unité logique du programme, souvent une fonction ou une méthode. On lui fournit des données d’entrée connues, puis on vérifie que la sortie correspond au résultat attendu.
Reprenons l’exemple du calcul de prix. Un test unitaire pourrait vérifier que la fonction calculerPrix(Paris, Lyon, 2eClasse) renvoie bien le montant prévu. Si quelqu’un modifie la formule de calcul par erreur, le test échoue immédiatement.
Les tests unitaires sont les plus rapides à exécuter, car ils n’ont pas besoin de base de données ni de serveur. Ils constituent la base de la pyramide de tests : nombreux, peu coûteux, très ciblés.
Tests d’intégration : vérifier que les modules communiquent correctement
Vous avez déjà branché deux appareils compatibles « en théorie » qui refusent de fonctionner ensemble ? C’est exactement le problème que les tests d’intégration détectent dans le logiciel.
À ce niveau, on ne teste plus une fonction isolée. On vérifie que deux composants ou plus échangent des données sans erreur. Par exemple, que le module de réservation envoie bien les bonnes informations au service de paiement, et que celui-ci renvoie une confirmation exploitable.
Les tests d’intégration révèlent les incompatibilités entre composants : mauvais format de date, champ manquant dans une réponse d’API, timeout mal configuré. Ce sont des bugs invisibles dans les tests unitaires.
Le piège des dépendances externes
Quand un test d’intégration fait appel à un service tiers (passerelle bancaire, API météo), il devient fragile. Une panne du service externe fait échouer le test sans que le code soit en cause. Les équipes utilisent alors des « mocks », des simulateurs qui imitent le comportement du service réel, pour stabiliser ces tests.
Tests fonctionnels et tests de bout en bout
Les tests fonctionnels vérifient que le logiciel répond aux exigences décrites dans le cahier des charges ou les user stories. On ne regarde plus le code : on teste un comportement attendu du point de vue de l’utilisateur.
Un test fonctionnel peut vérifier que « l’utilisateur connecté peut ajouter un article au panier et voir le total mis à jour ». Le test de bout en bout (end-to-end) va plus loin : il reproduit un parcours complet, de la connexion jusqu’à la confirmation de commande, en passant par le paiement.
- Test fonctionnel : valide une fonctionnalité précise, par exemple l’ajout au panier ou la recherche par mot-clé.
- Test de bout en bout : enchaîne plusieurs fonctionnalités dans un scénario réaliste, comme un achat complet sur un site e-commerce.
- Test d’acceptation : variante du test fonctionnel réalisée par le client ou le product owner pour valider que le livrable correspond au besoin métier.
Ces tests prennent plus de temps à écrire et à exécuter que les tests unitaires. Ils sont donc moins nombreux, mais couvrent les scénarios à fort impact.
Tests non fonctionnels : performance, sécurité et robustesse
Un logiciel peut répondre à toutes les exigences fonctionnelles et rester inutilisable. Pourquoi ? Parce qu’il rame sous la charge, plante quand mille utilisateurs se connectent en même temps, ou expose des données sensibles.
Tests de performance et de charge
Ces tests mesurent le temps de réponse de l’application et sa capacité à supporter un volume croissant de requêtes. On distingue le test de charge (comportement sous trafic normal), le test de stress (comportement au-delà des limites prévues) et le test d’endurance (stabilité sur une longue durée).
Tests de sécurité et chaîne d’approvisionnement logicielle
L’édition 2025 de l’OWASP Top 10 élargit les vérifications de sécurité aux défaillances de la chaîne d’approvisionnement logicielle. Les tests doivent couvrir non seulement le code applicatif, mais aussi les dépendances tierces, les composants open source et les scripts intégrés dans les pipelines CI/CD.
Un composant obsolète ou compromis dans la chaîne de dépendances peut introduire une vulnérabilité sans qu’aucune ligne de code de l’équipe ne soit en cause.
Tests manuels, tests automatisés et place de l’IA générative
Chaque type de test décrit plus haut peut être exécuté manuellement ou de manière automatisée. Les tests manuels restent pertinents pour les tests exploratoires, où le testeur navigue librement dans l’application pour découvrir des comportements imprévus. L’automatisation convient mieux aux tests répétitifs, comme les campagnes de régression lancées à chaque modification du code.
L’IA générative commence à intervenir dans certaines tâches : génération de cas de test, priorisation des régressions, maintenance des sélecteurs d’interface. L’ISTQB propose d’ailleurs une certification dédiée, la CT-GenAI, qui couvre ces usages tout en insistant sur la validation humaine des résultats.
- L’IA peut générer rapidement des jeux de données de test variés.
- Elle aide à trier les échecs de test pour identifier plus vite les vrais bugs.
- Le jugement du testeur reste nécessaire pour évaluer le contexte métier et décider d’une mise en production.
Les tests d’API méritent aussi un traitement séparé des tests d’interface web ou mobile. Tester l’API indépendamment permet de détecter des erreurs de contrat de données avant même que l’interface soit développée.
Choisir les bons types de tests en informatique dépend du projet, de ses contraintes techniques et de son niveau de risque. Un socle solide de tests unitaires, complété par des tests d’intégration ciblés et quelques scénarios de bout en bout, couvre la majorité des régressions courantes. Les tests non fonctionnels, eux, protègent contre les mauvaises surprises qui ne se révèlent qu’en conditions réelles.
