01 — Les grandes familles
Quelles familles de test existent ?
Six familles à connaître. Cliquez sur une carte pour voir ce qu'elle inclut et les techniques associées.
Tests fonctionnels
Vérifient ce que le système fait : règles métier, scénarios utilisateurs, conformité aux exigences. Réalisés en boîte noire.
Exemple : Vérifier qu'un formulaire de connexion accepte un email valide et refuse un mot de passe de moins de 8 caractères.
Tests non-fonctionnels
Vérifient comment le système se comporte : performance, sécurité, accessibilité, utilisabilité, fiabilité, compatibilité, portabilité.
Exemple : Mesurer le temps de réponse de la page d'accueil quand 500 utilisateur•rices la consultent en même temps (test de charge).
Tests structurels
Boîte blanche : exploitent la connaissance du code pour couvrir branches, conditions, chemins et instructions.
Exemple : Écrire un test qui déclenche la branche « sinon » d'une fonction de calcul de remise, jamais exécutée jusqu'ici.
Tests de régression
Assurent qu'une modification (correction, évolution, refactor) n'a pas cassé ce qui fonctionnait déjà.
Exemple : Après l'ajout d'un nouveau moyen de paiement, rejouer toute la suite de tests du panier pour vérifier que rien n'est cassé.
Tests de confirmation
Retestent après correction d'une anomalie pour confirmer qu'elle est bien résolue dans tous les environnements ciblés.
Exemple : Un bug empêchait de supprimer un article du panier ; une fois corrigé, on rejoue précisément ce scénario pour confirmer la résolution.
Tests de maintenance
Couvrent les évolutions, migrations de données, mises à jour techniques et retraits de fonctionnalités.
Exemple : Après une migration vers une nouvelle version de la base de données, vérifier que les commandes existantes restent accessibles.
02 — Non-fonctionnel
Les tests non-fonctionnels
Souvent négligés, les attributs qualité non-fonctionnels (ISOInternational Organization for Standardization 25010) définissent la frontière entre un logiciel qui fonctionne et un logiciel qui satisfait.
Performance
Temps de réponse, débit, consommation de ressources. Sous-types : charge (nominal), stress (au-delà), endurance (dans la durée), pic (spike).
Exemple : Charger la page produit avec 1000 utilisateur•rices simultané•es et mesurer le temps de réponse moyen (test de charge).
Sécurité
Vulnérabilités, injectionInsérer des données malveillantes dans un champ pour détourner son traitement (ex. injection SQL), authentification, gestion des sessions, exposition de données. Cadre : OWASPOpen Web Application Security Project, ASVSApplication Security Verification Standard, tests d'intrusion.
Exemple : Tenter une injection SQL dans un champ de recherche pour vérifier qu'il est correctement filtré.
Accessibilité
Conformité WCAGWeb Content Accessibility Guidelines 2.2 (A/AA/AAA), navigation clavier, lecteurs d'écran, contrastes, alternatives textuelles.
Exemple : Naviguer sur tout le site au clavier, sans souris, pour vérifier que chaque action reste possible.
Compatibilité
Navigateurs, OSOperating System, devices, résolutions, versions. Indispensable pour le web et le mobile multi-plateformes.
Exemple : Vérifier que le site s'affiche correctement sur Chrome, Firefox, Safari, ainsi que sur un iPhone.
Utilisabilité
Tests utilisateurs, parcours guidés, mesure de satisfaction (SUSSystem Usability Scale : questionnaire standardisé de 10 questions, noté sur 100, qui mesure la perception de l'utilisabilité d'un produit après son utilisation., NPSNet Promoter Score : mesure la probabilité qu'un utilisateur recommande le produit (note de 0 à 10), ici appliqué à une tâche précise plutôt qu'au produit entier. task-based).
Exemple : Observer un•e nouvel•le utilisateur•rice réaliser un achat sans aide, pour repérer les points de friction du parcours.
03 — Les différentes "boîtes"
Boîte noire, blanche, grise
Cet axe décrit le niveau de connaissance interne dont dispose le•la testeur•se.
Boîte noire
Sans connaissance interne. Basé sur les spécifications et le comportement observable. Tester comme un•e utilisateur•rice final•e, sans connaître le code ni la structure interne.
Exemple : Saisir un email sans arobase dans un formulaire d'inscription et vérifier que le message d'erreur attendu s'affiche.
Boîte blanche
Avec accès au code. Couvre branches, conditions, chemins. Typiquement piloté par les développeur•ses, conception des tests en fonction de la vision interne.
Exemple : Lire le code d'une fonction de calcul de remise pour écrire un test qui déclenche sa condition « sinon », jamais exécutée.
Boîte grise
Hybride. Connaissance partielle des structures internes pour guider des tests boîte noire plus ciblés.
Exemple : Savoir qu'une APIApplication Programming Interface interroge un cache avant la base de données, et tester spécifiquement le comportement quand ce cache est vide.
04 — Statique vs dynamique
Tester ne veut pas toujours dire exécuter
L'ISTQBInternational Software Testing Qualifications Board distingue deux grandes catégories complémentaires.
Statique
Le code ou les artefacts ne sont pas exécutés. S'appuie notamment sur des revues (relecture collective) ou des analyses statiques outillées (SonarQube, ESLint, SASTStatic Application Security Testing).
Dynamique
Le logiciel est exécuté avec des données d'entrée. On fait tourner le programme et on vérifie les sorties, les interactions, les performances, les erreurs. Sert à valider ce que le logiciel fait quand il tourne.
05 — Les tests statiques en détail
Les types de revue
L'ISTQBInternational Software Testing Qualifications Board distingue quatre niveaux de revue, du plus informel au plus rigoureux, selon le degré de formalisation du processus.
Revue informelle
Pas de processus formalisé. Un•e collègue relit le document ou le code et partage ses retours, souvent à l'oral ou via commentaires. Peu coûteuse, utile pour un premier avis rapide.
Exemple : Un•e développeur•se demande à un•e collègue de jeter un œil rapide à sa pull request avant de la merger.
Walkthrough (revue technique guidée)
L'auteur•rice présente et guide les participant•es à travers le document ou le code, scénario par scénario, pour recueillir des retours et partager la connaissance. Animée par l'auteur•rice lui-même·elle-même.
Exemple : Un•e product owner présente ses user stories et critères d'acceptation à l'équipe lors d'un atelier de refinement.
Revue technique
Revue structurée, menée par des pairs techniques (souvent sans l'auteur•rice en position de modérateur•rice), pour évaluer la qualité d'une solution et détecter des défauts. Documentée mais moins formelle que l'inspection.
Exemple : Deux développeur•ses senior analysent ensemble la conception d'une nouvelle architecture avant son implémentation, sans que l'auteur•rice du document ne dirige la séance.
Inspection
La plus formelle : rôles définis (modérateur•rice, lecteur•rice, auteur•rice, relecteur•rices), critères d'entrée/sortie, métriques de défauts, réunion préparée en amont. Vise la détection maximale de défauts sur des documents critiques.
Exemple : Une spécification réglementaire (santé, finance) est inspectée selon un processus formel avec modérateur•rice désigné•e et rapport de défauts consigné, avant validation.
Le processus générique de revue
Quel que soit le niveau de formalisme, l'objectif est d'atteindre ces grandes étapes pour favoriser la compréhension de toutes les parties prenantes.
Planification
Le•la modérateur•rice définit le périmètre, sélectionne les documents à examiner, fixe les critères et le temps alloué, choisit les participant•es et leurs rôles.
Lancement
Les objectifs sont présentés à l'ensemble des participant•es, les documents distribués, les critères d'examen expliqués.
Préparation individuelle
Chaque participant•e examine seul·e le produit avant la réunion, à son rythme, et relève anomalies, questions et remarques.
Communication et analyse
En réunion, les écarts relevés sont discutés et consignés, classés (confirmés ou non) avec leur sévérité.
Correction et suivi
L'auteur•rice corrige les défauts confirmés ; l'avancement est suivi jusqu'à ce que les critères de sortie soient atteints.
06 — Les autres types de tests
Les approches complémentaires
Au-delà des cas scriptés, ces approches enrichissent la couverture et révèlent les défauts que les scénarios planifiés ne verraient pas.
Exploratoire
Conception, exécution et apprentissage en parallèle. Très efficaces pour découvrir des défauts inattendus.
Basé sur les risques
Priorisation par impact × probabilité. On teste d'abord ce qui impacterait plus la production.
Session-Based Test Management
Sessions chronométrées (60–120 min) avec une charte claire. Compromis entre liberté et traçabilité.
Tests basés sur les modèles (MBTModel-Based Testing)
Génération de cas à partir d'un modèle. Utile sur des comportements combinatoires.
A retenir
Ce qu'il faut retenir
Partir du risque
Qu'est-ce qui impacterait le plus la production ? C'est la question qui doit guider le choix des tests.
Statique et dynamique, complémentaires
Combiner les tests statiques (revues) et dynamiques (exécutions), puisqu'ils sont complémentaires.
Scripté et exploratoire
Compléter les cas scriptés par de l'exploratoire, pour découvrir l'inattendu.
Le non-fonctionnel compte aussi
Performance, sécurité, accessibilité : ces attributs font pleinement partie de la qualité.
Mise en pratique
Testez votre compréhension
Une sélection de questions basées sur ce que vous venez de lire.
Une équipe vérifie que les règles métier et les scénarios utilisateurs sont respectés, sans regarder le code. De quelle famille de test s'agit-il ?
Performance, sécurité, accessibilité, utilisabilité... Ces attributs qualité relèvent de quelle famille de test ?
Après la correction d'un bug, on rejoue précisément le scénario d'origine pour confirmer qu'il est bien résolu. Quel type de test est-ce ?
Un•e développeur•se écrit des tests en s'appuyant sur sa connaissance du code pour couvrir les branches et les chemins. C'est une approche...
Une revue de code ou une analyse via SonarQube, sans exécuter le programme, relève du test...
Un•e testeur•se conçoit, exécute et apprend en même temps, sans script préétabli, pour découvrir des défauts inattendus. Quelle approche est-ce ?
À 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