[ISTQB] Les niveaux de test – 2023

Préambule

Cet article est une mise à jour de l’article le plus lus de la taverne depuis son ouverture sur les niveaux de test.

Avec son nouveau syllabus l’ISTQB a proposé un 5ème niveau de test. Pour rappel, ces niveaux sont des objectifs et il est toujours possible de les adapter à son contexte. Néanmoins, il est important de connaître ceux proposés de « base » car ils sont assez génériques pour s’adapter à un très grand nombre de contextes. L’ajout d’un 5ème niveau est d’ailleurs le fruit d’une évolution significative de ce contexte.

Introduction

L’ISTQB présente 5 niveaux de test dans son syllabus:

Ces niveaux sont un moyen de « découper » les tests en différents « types » définis en fonction de leurs objectifs.

Les tests de composants

Les tests de composants ont pour but de tester les différents composants du logiciel séparément afin de s’assurer que chaque élément fonctionne comme spécifié. Ces tests sont très souvent l’équivalent des tests unitaires. Dans ce cas ils sont généralement écrits et exécutés par le développeur qui a écrit le code du composant.

Lorsque ces tests sont bien les tests unitaires il est important de les automatiser lorsque c’est possible.

Pour une authentification, le bouton « se connecter » peut être vu comme un composant.

Il est possible de voir tout un système comme le composant d’un système plus complexe comme je l’ai fait avec un service de clé virtuelle pour les voitures. Dans ce cas, le téléphone était un composant du système plus grand.

Les tests d’intégration

Les tests d’intégrations sont des tests effectués entre les composants afin de s’assurer du fonctionnement des interactions et de l’interface entre les différents composants. Ces tests sont également gérés, en général, par des développeurs.

Toujours depuis l’authentification ici on vérifie que le message envoyé après l’appui sur le bouton « se connecter » est bien reçu par le serveur d’authentification.

Les tests d’APIs peuvent souvent faire office de tests d’intégration. Dans ce cas il est souvent intéressant de les automatiser car il y a un retour sur investissement rapide.

Les tests système

C’est les tests au sens le plus instinctif et généralement les plus effectués par les ingénieurs de tests. Leurs but est de vérifier que le système (le logiciel ou l’application dans son ensemble) répond aux exigences définies dans les spécifications. On les appelle souvent tests fonctionnels même si c’est un abus de langage car il existe des tests « non fonctionnels» qui peuvent être spécifiés (exemple de tests non fonctionnels : temps d’affichage d’une page). Pour en savoir plus je vous invite à lire les articles sur la norme ISO 25010.

Ici on vérifie que l’authentification fonctionne bien, que les bonnes erreurs sont remontées…

Ces tests peuvent être manuels ou automatisés, en général un mixte de tests automatisés et de tests manuels est ce qui a le meilleur retour sur investissement.

Les tests d’intégration système

Ce niveau de test est celui qui a été ajouté!

Dans le contexte actuel il est très rare de travailler sur un service numérique totalement isolé. Un service numérique interagit avec d’autres services et il ne peut fonctionner qu’avec ces autres systèmes. L’objectif de ces tests est de vérifier que notre système est capable de fonctionner dans cet environnement non cloisonné.

Dans l’exemple de l’authentification on peut imaginer des tests vérifiant le lien entre la demande d’authentification et la validation par la réception d’un code SMS.

Les tests d’acceptation

Les tests « finaux » effectués par le métier, les utilisateurs finaux ou leurs représentants (par exemple avec une bêta test). Leurs but est de confirmer que le produit final correspond bien aux besoins des utilisateurs finaux.

Attention : ce n’est pas parce qu’une application répond aux spécifications qu’elle répond aux besoins des utilisateurs.

Avec ces tests on vérifie qu’en plus de répondre aux exigences l’authentification correspond bien à ce à quoi le métier ou les clients finaux s’attendent (un champ authentification trop petit peut être problématique par exemple).

Les tests d’acceptation sont des tests manuels.

Conclusion

ISTQB définit bien les différents niveaux de tests et permet d’avoir une vision plus claire du test dans son ensemble.

Chaque niveau de test a sa place et doit être effectué avec rigueur.

Ces niveaux de tests sont généralement représentés par une pyramide car plus on est bas dans la pyramide plus le nombre de cas de tests est censé être important.

Si l’on devait comparer ces niveaux de tests à la construction d’une maison voici à quoi correspondrait chaque niveau de test :

• Les tests de composants aux vérifications matériaux de la maison (briques, tuiles, isolant…).
• Les tests d’intégration à tout ce qui lie ces matériaux (le ciment pour les briques)
• Les tests systèmes à l’ensemble de la construction (la maison a-t-elle le bon nombre de pièces, la bonne surface…)
• Les tests d’intégration système à ce que la maison soit bien raccordée à l’électricité, internet, l’eau courante…
• Les test d’acceptation à vérifier que la maison est bien vivable au jour le jour.

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.