Les niveaux de test et la pyramide appliquée au mobile
Le gain du jour : situer les quatre niveaux de test classiques (unitaire, intégration, système, acceptation) sur une app mobile concrète, et comprendre pourquoi la pyramide des tests guide la répartition de l’effort.
Les quatre niveaux, du plus petit au plus large
Test unitaire — vérifie une fonction, une méthode, une classe isolée du reste. Sur mobile : une fonction qui calcule un prix avec remise, une classe qui valide un format d’email. Rapide à exécuter (millisecondes), écrit par les développeurs.
Test d’intégration — vérifie que plusieurs modules fonctionnent ensemble. Sur mobile : l’écran de connexion appelle-t-il correctement le module d’authentification et le stockage local du jeton de session ?
Test système (end-to-end) — vérifie l’app entière, dans des conditions proches du réel, du point de vue de l’utilisateur : installer l’app, créer un compte, ajouter un article au panier, payer. C’est le niveau où les outils comme Appium ou Espresso interviennent le plus (leçon 11).
Test d’acceptation — vérifie que l’app répond au besoin métier tel que défini par les parties prenantes (product owner, client). Souvent formalisé par des critères d’acceptation écrits avant le développement (lien avec la QA vue en leçon 1).
La pyramide des tests
Ces quatre niveaux ne demandent pas le même effort. La pyramide des tests représente la répartition recommandée :
/\
/ \ Tests système / E2E (peu nombreux, lents, fragiles)
/----\
/ \ Tests d'intégration (nombre modéré)
/--------\
/ \ Tests unitaires (nombreux, rapides, stables)
/------------\Beaucoup de tests unitaires (rapides, stables, faciles à maintenir), un peu moins de tests d’intégration, et peu de tests système end-to-end — parce qu’ils sont lents, coûteux à maintenir, et plus fragiles (un test E2E échoue parfois sans qu’il y ait de vrai bug, à cause d’un délai réseau ou d’une animation).
Beaucoup d’équipes mobiles débutantes construisent l’inverse — un « cône de glace » : peu de tests unitaires, énormément de tests E2E manuels ou automatisés. Résultat : une suite de tests lente (des heures), instable (des échecs aléatoires liés au réseau ou à l’animation), et coûteuse à maintenir à chaque changement d’interface. Un testeur QA qui comprend la pyramide pousse l’équipe à investir davantage dans les tests unitaires et d’intégration, et réserve l’E2E aux parcours critiques.
Où se situe le testeur QA sur ces quatre niveaux ?
Historiquement, le testeur QA intervenait surtout au niveau système et acceptation. Dans une équipe mobile moderne, son rôle s’étend : il participe à la définition des critères d’acceptation (en amont), challenge la couverture des tests d’intégration avec les développeurs, et conçoit les scénarios E2E prioritaires — sans forcément les coder lui-même, mais en sachant lesquels valent la peine d’être automatisés (voir leçon 11).
Vérifie ta compréhension
Une équipe mobile a 500 tests end-to-end automatisés et 20 tests unitaires. Que suggère la pyramide des tests ?
Un test vérifie qu'une fonction de calcul de remise renvoie le bon montant pour différentes valeurs d'entrée. À quel niveau appartient-il ?
🗂 Fiche de référence associée : Glossaire QA mobile — antisèche.