01 — Les cinq niveaux
Que fait chaque niveau exactement ?
Tests de composants (tests unitaires)
Vérifient un composant isolé (fonction, classe, module), coupé de ses dépendances par des doublures.
- JUnit, NUnit, pytest, Jest : frameworks pour écrire et exécuter les tests de composants.
- Mocks, stubs : doublures qui remplacent les dépendances pour isoler le composant testé.
- TDDTest-Driven Development : écrire le test avant le code.
Couverture cible : 70-80 % des lignes critiques, à titre de repère (l'ISTQB n'impose aucun seuil précis)
Tests d'intégration de composants
Valide les interactions entre modules au sein d’une même application (classesStructures qui regroupent des données et des comportements, brique de base en programmation orientée objet., packagesRegroupements de classes ou de modules liés, organisés ensemble dans un même dossier ou une même bibliothèque., sous-systèmes internes).
- Spring Boot Test, Testcontainers : exécutent plusieurs classes ou modules ensemble pour vérifier leurs interactions.
- Pact : vérifie qu'un contrat d'interface est respecté entre deux composants (format d’échange convenu).
- Stratégies top-down, bottom-up, sandwich : assemblent les modules progressivement (voir plus bas).
Couverture cible : Chemins critiques entre modules internes
Tests système
Évaluent le système complet en boîte noire, sur un environnement représentatif de la production.
- Selenium, Cypress, Playwright : simulent un parcours utilisateur complet, du début à la fin.
- JMeter, Gatling, k6 : vérifient le comportement du système sous un volume de trafic donné.
- OWASP ZAP, Burp Suite : recherchent des vulnérabilités et des failles exploitables.
- BrowserStack, Sauce Labs : testent la compatibilité multi-navigateurs, multi-OS, multi-devices.
Couverture cible : Scénarios critiques de bout en bout
Tests d'intégration système
Valide les interactions entre applications ou systèmes distincts, notamment des systèmes externes : API externes, bases de données, files de messages, services tiers.
- Postman, REST Assured : vérifient les appels et réponses entre services (RESTRepresentational State Transfer : style d’architecture pour des API web utilisant les méthodes HTTP standards (GET, POST, PUT, DELETE...)., GraphQL, messages asynchrones).
- DBUnit, Testcontainers : vérifient la persistance et la cohérence des données échangées avec une base réelle ou simulée.
- WireMock, sandbox Stripe/PayPal : simulent des services tiers (paiement, authentification, envoi d'email...) via des doublures/bouchons de service.
Couverture cible : Chemins critiques inter-systèmes
Tests d'acceptation
Confirment que le système répond aux besoins métier et que les personnes utilisatrices peuvent l’accepter.
- UATUser Acceptance Testing (CucumberOutil qui exécute des scénarios de test écrits en langage naturel (Gherkin) et les relie au code de test., GherkinSyntaxe structurée (Étant donné / Quand / Alors) utilisée pour rédiger des scénarios de test lisibles par le métier.) : User Acceptance Testing : scénarios rédigés en langage métier, exécutés par les personnes utilisatrices finales ou la clientèle.
- OATOperational Acceptance Testing : Operational Acceptance Testing : sauvegarde, restauration, reprise sur sinistre, vérifiées par les équipes d’exploitation.
- Contractuels et réglementaires : vérifient la conformité à un contrat ou à une norme.
- Alpha / Bêta : tests réalisés respectivement chez l’éditeur puis auprès d'utilisateurs finaux réels.
Couverture cible : Cas réel d'usage et critères d'acceptation
02 — Stratégies d'intégration
Comment assembler et tester les composants ?
L'ISTQBInternational Software Testing Qualifications Board recense plusieurs approches, chacune avec ses compromis entre rapidité de mise en place et facilité de diagnostic.
Big bang
Tout est intégré d'un coup, puis testé. Simple, mais diagnostic difficile en cas d'échec.
Top-down
On part des modules de haut niveau et on descend, en utilisant des stubs pour les modules inférieurs.
Bottom-up
On commence par les modules bas niveau avec des drivers, puis on remonte vers les couches supérieures.
Sandwich
Combinaison top-down et bottom-up, on se rejoint au milieu. Bon compromis sur les gros systèmes.
Incrémental
On intègre les composants un par un, en validant à chaque étape. Diagnostic facile, mais plus long.
03 — Les schémas à éviter
Les différentes organisations de test à éviter
Hors syllabus FondationCône de glace
Beaucoup de bout en bout, peu de tests de composants. Suite lente, fragile et coûteuse à maintenir.
Sablier
Beaucoup de tests de composants et de bout en bout, très peu d'intégration. Les bugs d'interface passent entre les mailles.
Cupcake
Tout manuel sur le dessus, avec une base importante de tests de composants. Pas durable dès que le produit grossit.
04 — La pyramide idéale
La pyramide des tests
Théorisée par Mike Cohn, elle propose une répartition saine : beaucoup de tests de composants à la base, moins d'intégration au milieu, peu de bout en bout au sommet. L'objectif est l'équilibre entre vitesse, coût et confiance.
BeBBout en Bout / UIUser Interface
Peu nombreuxLents et coûteux = scénarios critiques.
Intégration / APIApplication Programming Interface
ModérésValident les contrats et interactions.
Composants (tests unitaires)
Très nombreuxRapides, nombreux = fondation de la confiance.
Légende & sigles de la pyramide
Repères rapides pour bien distinguer chaque niveau technique :
Valide des parcours utilisateurs complets à travers l'ensemble des couches logicielles (front-end, back-end, bases de données et services tiers). Très représentatif de l'usage réel, mais plus lent et coûteux.
Vérifie les interactions directes sur les écrans graphiques (clics de boutons, saisie de formulaires, affichage web ou mobile). Idéal pour l'expérience visuelle, mais plus fragile aux modifications d'interface.
Teste la logique métier et les échanges de données entre services (requêtes HTTP REST, GraphQL, messages) sans interface graphique. Beaucoup plus rapide, robuste et stable que les tests UI.
Vérifie chaque brique élémentaire de code (fonction, classe, module) de façon totalement isolée grâce à des doublures (mocks/stubs). Ultra-rapide, peu coûteux et socle de la pyramide.
À retenir
Ce qu'il faut retenir
Un objectif par niveau
Chaque niveau a un objectif et un responsable distincts : ne pas les confondre.
De l'unitaire à l'acceptation
Les tests de composants offrent des retours rapides, les tests d'intégration valident les échanges, les tests système couvrent les parcours complets, et les tests d'acceptation confirment la valeur métier.
La pyramide, un repère
La pyramide des tests est un repère utile, mais elle doit être adaptée au produit et à ses risques.
Le coût d'un mauvais placement
Un test mal placé (BeBBout en Bout pour ce qui pourrait être unitaire) coûte plus cher : cela revient à reporter la détection des bugs vers la fin du projet.
Mise en pratique
Testez votre compréhension
Une sélection de questions basées sur ce que vous venez de lire.
Un test s'appuie sur des mocks et des stubs pour isoler une fonction du reste du système. De quel niveau s'agit-il ?
Une équipe vérifie les appels API entre deux services distincts et l'accès à une base de données externe. Quel niveau de test couvre cela ?
On intègre les modules de haut niveau en premier, en s'appuyant sur des stubs pour simuler les modules inférieurs. Quelle stratégie d'intégration est-ce ?
Une suite de tests contient énormément de tests de bout en bout et très peu de tests de composants. Quel anti-pattern est-ce ?
La clientèle ou le métier valide le logiciel via l'UAT juste avant la mise en production. De quel niveau de test s'agit-il ?
Dans la pyramide des tests de Mike Cohn, quel niveau doit être le plus nombreux à la base ?
Rejoignez Le Labo QA gratuitement
Quiz d'entraînement, exercices pratiques et sauvegarde automatique de votre progression sur l'ensemble des parcours.
Bienvenue dans Le Labo QA
Votre session est active. Retrouvez l'ensemble de votre progression, reprenez vos quiz et consultez votre tableau de bord personnel.
À savoir
La Minute QA est une aide à la compréhension, pas une formation professionnelle : certains points ne peuvent pas être couverts ici. Pensez à suivre une formation certifiante et à consulter le syllabus officiel ISTQB pour une préparation complète.
Pour aller plus loin