01 — Les cinq niveaux
Que fait chaque niveau exactement ?
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 unitaires.
- 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)
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
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 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'acceptation
Confirment que le système répond aux besoins métier et que l’utilisateur•rice peut 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 utilisateur•rices finaux ou le•la client•e.
- 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 chez de vrais·es utilisateur•rices.
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 d'unitaires. Suite lente, fragile et coûteuse à maintenir.
Sablier
Beaucoup d'unitaires 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 unitaires. 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 d'unitaires à 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.
Unitaires
Très nombreuxRapides, nombreux = fondation de la confiance.
A 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 unitaires 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 d'unitaires. Quel anti-pattern est-ce ?
Un•e client•e 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 ?
À 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