Les types de test logiciel : la carte pour s’y retrouver

« Vous avez testé ? » Le développeur répond oui : ses tests unitaires passent. La cheffe de projet comprend que l’application est prête. Le client, lui, entend « il n’y a plus de bugs ». Trois personnes, trois sens du même mot, et une mise en ligne qui tourne mal.

Le test logiciel a un vocabulaire précis, mais il ressemble vite à une jungle : test unitaire, test système, recette, régression, boîte noire, performance… Ces mots ne sont pas interchangeables. Chacun répond à une question différente sur votre application.

Cet article est une carte. Il suit les repères du syllabus Fondation de l’ISTQB, l’organisme international qui certifie les testeurs, et les traduit en exemples concrets. À la fin, vous saurez nommer le bon test pour chaque question, et repérer celui qui manque à votre projet.

Pourquoi distinguer les niveaux et les types de test ?

Tout test se situe sur deux axes. Le premier dit à quelle échelle on teste : une fonction isolée, un assemblage de modules, l’application entière, ou son adoption par les vrais utilisateurs. C’est le niveau de test. Le second dit ce que l’on regarde : le résultat est-il juste ? Rapide ? Sûr ? Agréable ? C’est le type de test.

Pensez à une maison en construction. On contrôle les briques, puis les murs, puis la maison entière, et enfin la famille la visite avant de signer : ce sont les niveaux. L’électricité, la plomberie et l’isolation sont les types, et elles se vérifient à chaque étape, pas seulement à la fin.

Quels sont les cinq niveaux de test ?

Le syllabus Fondation de l’ISTQB (version 4.0) décrit cinq niveaux. Le tableau ci-dessous les illustre avec une application de mobile money.

Le test d’acceptation prend plusieurs formes : le test d’acceptation par les utilisateurs (UAT, pour User Acceptance Testing), le test d’acceptation opérationnelle (l’équipe qui exploitera le service sait-elle sauvegarder, surveiller, restaurer ?), le test d’acceptation contractuelle ou réglementaire, et les tests alpha et bêta. En français, on l’appelle souvent la recette.

Ces niveaux peuvent se chevaucher : en équipe agile, le développeur écrit ses tests unitaires pendant que la testeuse explore la version de la veille.

Quels sont les grands types de test ?

Le syllabus retient quatre types : le test fonctionnel, le test non fonctionnel, le test boîte noire et le test boîte blanche.

Le test fonctionnel : est-ce que ça fait ce qu’il faut ?

Il vérifie ce que l’application doit faire : ses fonctions sont-elles complètes, correctes et adaptées au besoin ? Une application de livraison calcule-t-elle les frais selon le quartier ? Le bouton « Annuler la commande » rembourse-t-il vraiment le client ?

Le test non fonctionnel : est-ce que ça le fait bien ?

Il évalue comment l’application se comporte. L’ISTQB s’appuie sur la norme ISO/IEC 25010, qui classe les caractéristiques de qualité. Le tableau suivant les traduit en questions concrètes.

Beaucoup de tests non fonctionnels ajoutent une contrainte à un test fonctionnel : « le paiement aboutit » devient « le paiement aboutit en moins de dix secondes sur un réseau lent ». Le syllabus prévient qu’un défaut non fonctionnel découvert tard peut menacer tout le projet : on ne rend pas une application rapide la veille de sa sortie.

Boîte noire et boîte blanche : deux façons d’inventer des tests

Le test boîte noire part de la spécification : ce que l’application est censée faire, sans regarder le code. Le test boîte blanche part de la structure interne : le code, l’architecture, les flux de travail et de données. Son but est de couvrir cette structure, par exemple en s’assurant que chaque branche d’un calcul a été exécutée au moins une fois.

Au restaurant, la boîte noire goûte le plat et le compare à la carte ; la boîte blanche entre en cuisine et vérifie chaque étape de la recette. Les deux se complètent : la boîte noire ne mesure pas quelle part du code a été exécutée, et la boîte blanche ne voit pas la fonction demandée que personne n’a codée.

La plupart des testeurs d’applications, sur téléphone ou dans un navigateur, travaillent en boîte noire.

Que tester après un changement : confirmation ou régression ?

Le test de confirmation vérifie que le défaut corrigé a bien disparu : on rejoue le scénario qui échouait, et on ajoute au besoin des tests sur ce que la correction a modifié. Le test de régression vérifie que le changement n’a rien cassé ailleurs : dans le même module, dans d’autres modules, voire dans les systèmes connectés.

Le syllabus conseille de commencer par une analyse d’impact pour savoir jusqu’où tester. Et comme les suites de régression grossissent à chaque version, elles sont de bonnes candidates à l’automatisation : notre article test manuel ou automatisé vous aide à choisir. Le déroulé complet avant une sortie est détaillé dans smoke test, régression, recette.

Où ranger le test exploratoire, le smoke test ou le test utilisateur ?

Certains mots très courants ne sont ni des niveaux ni des types. Ils désignent une approche ou une technique, qui traverse toute la carte.

• Le test exploratoire est une technique fondée sur l’expérience : on conçoit, exécute et évalue les tests en même temps, en apprenant l’application. Voir le test exploratoire.
• Le smoke test (littéralement « test de fumée ») est une vérification rapide des fonctions vitales, pour décider si une nouvelle version mérite d’être testée plus à fond.
• Le test manuel et le test automatisé sont deux façons d’exécuter n’importe quel test.
• Le test utilisateur observe de vraies personnes en train d’accomplir des tâches, pour évaluer l’utilisabilité.
• Le test de maintenance accompagne les changements d’une application déjà en service, y compris les correctifs urgents (hotfix).

Quel test pour quelle question ? La table récapitulative

Voici la table à garder sous la main. Partez de votre question : la deuxième colonne donne le test qui y répond, la troisième l’article qui l’approfondit.

Comment choisir les tests de votre projet dès aujourd’hui ?

Personne ne fait tout. Voici une méthode en cinq étapes pour une petite équipe.

1. Listez vos trois plus grandes peurs. Un paiement débité mais non enregistré ? Des données perdues ? Une application trop lourde pour les téléphones de vos clients ?
2. Traduisez chaque peur en question, puis trouvez le test correspondant dans la table ci-dessus.
3. Regardez ce qui existe déjà. Des tests unitaires sur les calculs ? Une relecture des parcours clés avant chaque sortie ?
4. Repérez les trous. Les plus fréquents : aucune régression organisée, aucun essai sur un appareil modeste, aucun utilisateur réel avant la sortie.
5. Planifiez le minimum vital, puis enrichissez-le version après version.

Les derniers trous de la liste (appareils variés, regards neufs, vrais utilisateurs) sont ceux qu’une équipe comble mal seule. C’est le rôle de testeurs extérieurs comme ceux de GeekTest, sur leurs propres téléphones et leurs propres réseaux : vous pouvez faire tester votre application ou devenir testeur.

Pour aller plus loin

• Syllabus ISTQB Certified Tester Foundation Level v4.0.1 (nouvel onglet) : la référence de cet article. Section 2.2 pour les niveaux et les types, 2.2.3 pour la confirmation et la régression, 4.4 pour les techniques fondées sur l’expérience (en anglais).
• Page de la certification CTFL v4.0 sur le site de l’ISTQB (nouvel onglet) : présentation de la certification Fondation et téléchargement du syllabus.
• Glossaire ISTQB : regression testing (nouvel onglet) : la définition officielle du test de régression, et des centaines d’autres termes du métier.
• Glossaire ISTQB : smoke testing (nouvel onglet) : la définition officielle du smoke test.
• Glossaire ISTQB : portability (nouvel onglet) : la portabilité, à comparer avec la compatibilité pour bien saisir la nuance.