Lorsque je présente les niveaux de test ou les familles de test selon la norme ISO-25 010 on me pose souvent ces questions:
Mais quelle différence entre les types de test et les niveaux de test ? Pourquoi tant de terminologies ? Où se trouvent les tests de bout en bout / exploratoires / bêta tests … ?
Définitions
La première chose à faire lorsque l’on veut comparer des termes c’est de connaitre leur définitions.
Les niveaux de test ont une définition assez simple présentée dans cet article. Brièvement, ces tests ont pour but de décomposer un logiciel selon 4 niveaux: le niveau composant (la plus petite brique), le niveau intégration (la liaison entre ces briques: le ciment), le niveau système (le contenu de la construction) et le niveau acceptation (la correspondance au besoin utilisateur). Il est d’ailleurs possible de créer d’autres niveaux selon les projets comme décrit dans le syllabus avancé de l’ISTQB « Test manager »
Les types de test ont par contre un définition beaucoup plus floue. Pour être honnête je ne suis pas capable d’en donner une pertinente tellement cela regroupe des familles et branches diverses.
La définition ISTQB (disponible sur le glossaire en ligne) est celle-ci:
Groupe d’activités de test dont l’objectif est de tester un composant ou système sur un ou plusieurs attributs liés entre eux. Un type de test est focalisé sur un objectif de test spécifique (ex. : test de fiabilité, d’utilisabilité, de régression, etc) et peut couvrir un ou plusieurs niveaux de test et une ou plusieurs phases de test.
On retrouve donc, dans les « types de test » des tests comme:
- Les familles de test de l’ISO-25 010 comme les tests fonctionnels et de performances.
- Les tests de régression et vitaux
- Les tests boites noires/blanches
- Les tests de bout en bout
- Les tests exploratoires
- Les alpha et bêta test
- …
Analogie comparative
Au final, les niveaux de tests sont un moyens de structurer et d’organiser ses tests alors que les tests c’est tous les tests possible.
On peut dire que les niveaux de tests sont comme un trieur et que les types de tests sont les feuilles que l’on va ranger dedans.
Comme pour le trieur dans lequel on peut mettre n’importe quelle feuille, il est possible de ranger la plupart des types de test dans différents « niveaux de test »!
Au final
Au final, il n’est pas possible de donner une différence figée entre type et niveaux de test. Il est par contre possible de prendre les différents « types de test » et de définir à quels niveaux ils se peuvent généralement se situer.
Reprenons la liste précédente:
- Les familles de test de l’ISO-25 010 => l’ensemble de ces tests peut être effectué à tous les niveaux.
- .Les tests de régression => les tests de régression peuvent/doivent être effectués sur tous les niveaux.
- .Les tests vitaux => les tests de régression peuvent/doivent être effectués sur tous les niveaux.
- Les tests boites noires => les tests boites noires peuvent être effectués sur tous les niveaux même si en général on les voit moins au niveau des tests de composants lorsque ces derniers se confondent avec les tests unitaires.
- Les tests boites blanches => les tests boites blanches peuvent être effectués sur tous les niveaux même si en général on les voit moins au niveau des tests d’acceptation
- Les tests de bout en bout => ces tests ne peuvent pas être effectués sur le niveau composant et il est peu probable d’en voir au niveau intégration. Ils sont par contre bien présents dans les tests système et d’acceptation.
- Les tests exploratoires => les tests exploratoires peuvent/doivent être effectués sur tous les niveaux.
- Les alpha et bêta test => ces types de tests bien précis sont des tests d’acceptation.
- …
Cela donne cette figure qu’il est possible de compléter avec tout autre type de test:
Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
10 Responses
Bonjour Marc,
Fraîchement certifiée Istqb foundation, je suis débutante passionnée en test logiciel.
J’ai deux petites questions :
-c’est quoi les tests vitaux, c’est la première fois que j’entends ce terme?
-c’est quoi la différence entre un test système et un test de bout en bout, si c’est possible de me donner un exemple de ces deux tests dans une appli jee. Merci d’avance Hasnae
Bonjour,
Les tests vitaux sont en fait les tests fulmigatoires (voir glossaire istqb). N’aimant pas beaucoup ce nom peu compréhensible j’utilise le terme « vital ». Il y a des articles à ce sujet sur le site. Concrètement, le but de ces tests, très peu nombreux, est de déterrer très vite des anomalies critiques.
Les tests système c’est un niveau de test. Les tests de bout en bout c’est une notion parfaitement indépendante des niveaux de test (voir article sur les niveaux de test). Concrètement les tests de bout en bout ça veut dire sans simuler des composants internes voir externes. Les tests système ou même d’acceptation ne sont pas forcément de bout en bout, par contre des tests de bout en bout ont de très fortes chances d’être des tests système ou tests d’acceptation.
Bonjour Chahine,
Tout d’abord un grand merci pour ton blog très intéressant
ma question porte sur les tests d’intégration j’ai du mal à les différencier aux tests systèmes si vous avez des exemples concrets?
Pour moi ce que j’ai compris les tests d’intégration on teste le lien entre les composants, donc je suis testeur dans une équipe chaque développeur a développé un composant ou une US quand je fais le build de tous ces composants le tout doit bien s’intégrer et je n’ai pas des erreurs.
Est ce que les tests d’intégration s’arrêtent là ou ça comprend les tests fonctionnels si oui c’est quoi la différence avec les tests système?
Merci d’avance.
Youcef.
Bonjour,
le tests d’intégrations peuvent être fonctionnels ou non fonctionnels. Il représente en effet des tests sur les intéractions entre les composants. On peut par exemple penser à des tests d’API.
Le rôle des différents niveaux de test est bien imagé dans cet article: https://latavernedutesteur.fr/2019/04/04/le-role-des-tests-dacceptations-par-lexemple/
Bonjour Chahine,
Merci pour la réponse j’ai une autre question concernant celui qui doit faire les tests pour chaque niveau, car le testeur ne peut pas tout faire et parfois pour faire des tests de bas niveau d’une part il faut avoir des compétences en développement et d’autre part cela nécessite l’installation d’un environnement de dev pour le testeur (software plus hardware = coût pas négligeable)
Merci d’avance.
Youcef.
Bonjour Youcef,
Le testeur ne fait pas tous les tests!
C’est d’ailleurs un gros problème dans la dénomination du testeur. Si l’on devait cloisonner le travail d’un testeur sur un niveau de test, je dirais qu’il est en charge des tests « systèmes » uniquement (attention cela reste si l’on doit cloisonner, il arrive que des testeurs dans le cadre de leur rôle du testeur fasse de l’acceptation et de l’intégration… mais moins souvant du composant)
PS: Hage Chahine est mon nom, « Chahine » est seulement la seconde partie
Merci et désolé pour l’erreur sur le nom.
Youcef.
Bonjour Marc,
Est ce possible de faire le lien dans votre schéma entre chaque niveau de test et l’environnement dans lequel se déroule les tests concernés.
Pour ma part je les vois ainsi je peux me tromper:
Tests composant => Env de Dev
Tests d’intégration => Env d’intégration (éventuellement la dev aussi)
Tests système => env de test
Tests acceptations => Env de près-prod ( éventuellement la prod aussi )
Merci d’avance,
Youcef.
Bonjour,
en général c’est le cas mais pas tout le temps et ce pour plusieurs raisons:
1- il y a des fois plus ou moins d’environnements
2 – un même niveau de test peut être fait sur plusieurs environnements
3 – on peut être dans un cas comme pour ma présentation à la STLS sur la clé virtuelle où un composant se retrouve être un système dans son ensemble
J’aime vraiment bien l’image de couverture de cet article. Une efficace antisèche 🙂