Types de test
Le bon test au bon moment. Comprendre les grandes familles aide à construire une stratégie ciblée. Fonctionnel ou non-fonctionnel, statique ou dynamique, boîte noire ou boîte blanche, chaque axe répond à une question différente.
01 — Les grandes familles
Quelles familles de test existent ?
Tests fonctionnels
Objectif : 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.
Incluent :
- Tests de fonctionnalités
- Tests de scénarios
- Tests de conformité métier
Techniques :
- Partitions d'équivalence
- Valeurs limites
- Tables de décision
- Transitions d'état
- Cas d'utilisation
Tests non-fonctionnels
Objectif : Vérifient comment le système se comporte : performance, sécurité, accessibilité, utilisabilité, fiabilité, compatibilité, portabilité.
Incluent :
- Performance / charge / stress / endurance
- Sécurité (OWASPOpen Web Application Security Project)
- Accessibilité (WCAGWeb Content Accessibility Guidelines 2.2)
- Utilisabilité
- Fiabilité & robustesse
Techniques :
- Modèle ISOInternational Organization for Standardization 25010
- SLOService Level Objective / SLIService Level Indicator
- Budgets de performance
Tests structurels
Objectif : Boîte blanche : exploitent la connaissance du code pour couvrir branches, conditions, chemins et instructions.
Incluent :
- Analyse de couverture
- Tests de mutation
- Revue de code orientée test
Techniques :
- Couverture d'instructions
- Couverture des décisions
- Couverture des chemins
Tests de régression
Objectif : Assurent qu'une modification (correction, évolution, refactor) n'a pas cassé ce qui fonctionnait déjà.
Incluent :
- Suite de régressionEnsemble de tests rejoués pour vérifier que les fonctionnalités existantes marchent toujours
- Smoke testsVérification rapide que les fonctions critiques marchent, avant d'aller plus loin
- Sanity checksContrôle ciblé et rapide qu'une correction précise fonctionne, sans tout retester
Techniques :
- Sélection par impact
- Priorisation par risque
- Tests automatisés en CIContinuous Integration
Tests de confirmation
Objectif : Retestent après correction d'une anomalie pour confirmer qu'elle est bien résolue dans tous les environnements ciblés.
Incluent :
- Rejeu du défaut
- Vérification multi-environnements
Techniques :
- Reproduction du scénario d'origine
Tests de maintenance
Objectif : Couvrent les évolutions, migrations de données, mises à jour techniques et retraits de fonctionnalités.
Incluent :
- Tests d'impactIdentifier et retester les zones du système affectées indirectement par un changement
- Tests de migration de données
- Tests post-déploiement
Techniques :
- Analyse d'impact
- Tests de migration
- Rollback testing
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).
Sécurité
Vulnérabilités, injection, authentification, gestion des sessions, exposition de données. Cadre : OWASPOpen Web Application Security Project, ASVSApplication Security Verification Standard, tests d'intrusion.
Accessibilité
Conformité WCAGWeb Content Accessibility Guidelines 2.2 (A/AA/AAA), navigation clavier, lecteurs d'écran, contrastes, alternatives textuelles.
Compatibilité
Navigateurs, OS, devices, résolutions, versions. Indispensable pour le web et le mobile multi-plateformes.
Utilisabilité
Tests utilisateurs, parcours guidés, mesure de satisfaction (SUSSystem Usability Scale, NPSNet Promoter Score task-based).
03 — Les différentes "boîtes"
Boîte noire, blanche, grise
Cet axe décrit le niveau de connaissance interne dont dispose le testeur.
Boîte noire
Sans connaissance interne. Basé sur les spécifications et le comportement observable. Tester comme un utilisateur final, sans connaître le code ni la structure interne.
Boîte blanche
Avec accès au code. Couvre branches, conditions, chemins. Typiquement piloté par les développeurs, conception des tests en fonction de la vision interne.
Boîte grise
Hybride. Connaissance partielle des structures internes pour guider des tests boîte noire plus ciblés.
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 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
En bref
- Partir du risque : qu'est-ce qui impacterait le plus la production ?
- Combiner les tests statiques (revues) et dynamiques (exécutions) puisqu'ils sont complémentaires ;
- Compléter les cas scriptés par de l'exploratoire pour découvrir l'inattendu ;
- Penser au non-fonctionnel : perf, sécurité, accessibilité, etc. qui font pleinement partie de la qualité.
Pour aller plus loin