00 - Summary
1. Existing test families
2. Non-functional testing
3. Black-box, white-box, and grey-box testing
4. Static vs. dynamic Testing
5. Complementary approaches
6. Key takeaways
01 - Tha main families
Which test families exist
01
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.
INCLUT :
-
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é.
INCLUT :
-
Performance / charge / stress / endurance
-
Sécurité (OWASP Top 10 - Mobile Application Security Verification Standard)
-
Accessibilité (WCAG 2.2 - Règles pour l’accessibilité des contenus web (WCAG) version 2.2)
-
Utilisabilité
-
Fiabilité & robustesse
TECHNIQUES :
-
Modèle ISO 25010 - (voir site)
-
SLO (Service Level Objective - Objectif de niveau de service) / SLI (Service Level Indicator - Indicateur de niveau de service)
-
Budgets de performance
03
Tests structurels
Objectif - Boîte blanche : exploitent la connaissance du code pour couvrir branches, conditions, chemins et instructions.
INCLUT :
-
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à.
INCLUT :
-
Suite de régression
-
Smoke tests (tests de fumée - couverture des principales fonctionnalités)
-
Sanity checks (test de validation)
TECHNIQUES :
-
Sélection par impact
-
Priorisation par risque
-
Tests automatisés en CI
Tests de confirmation
Objectif — Retester après correction d'une anomalie pour confirmer qu'elle est bien résolue dans tous les environnements ciblés.
INCLUT :
-
Rejeu du défaut
-
Vérification multi-environnements
TECHNIQUES :
-
Reproduction du scénario d'origine
-
Tests autour de la correction
06
Tests de maintenance
Objectif — Couvrent les évolutions, migrations de données, mises à jour techniques et retraits de fonctionnalités.
INCLUT :
-
Tests d'impact
-
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 (ISO 25010) définissent la frontière entre un logiciel qui marche 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 : OWASP, ASVS (Application Security Verification Standard), tests d'intrusion.
Accessibilité
Conformité WCAG 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 (SUS - System Usability Scale - mesure de satisfaction et d’utilisabilité perçue, NPS task-based - Net Promoter Score - satisfaction autour d’une tâche précise).
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.
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, SAST).
Dynamique
Le logiciel est exécuté avec des données d'entrée. Inclut tous les tests fonctionnels, non-fonctionnels et structurels exécutés.
On fait tourner le programme (ou un composant) avec des entrées définies et on vérifie les sorties, les interactions, les performances, les erreurs, etc.
Sert à valider ce que le logiciel fait quand il tourne.
04 - Les tests statiques et dynamiques
Statique vs dynamique
Tester ne veut pas toujours dire exécuter. L'ISTQB distingue deux grandes catégories complémentaires.
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 ferait le plus mal en 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 (MBT)
Génération de cas à partir d'un modèle. Utile sur des comportements combinatoires.
06 - A retenir
En bref :
-
Partir du risque : qu'est-ce qui ferait le plus mal en production ?
-
Combiner les tests statiques (revues) et dynamiques (exécutions) — l'un ne remplace pas l'autre.
-
Compléter les cas scriptés par de l'exploratoire pour découvrir l'inattendu.
-
Ne pas oublier le non-fonctionnel : perf, sécurité, accessibilité, etc. qui font pleinement partie de la qualité.