Techniques de test
Concevoir des cas de test ne signifie pas en écrire beaucoup, mais en écrire des bons. Les techniques ISTQB structurent la conception pour couvrir le risque avec le moins de cas possible.
01 — Les grandes familles
Trois grandes familles
Boîte noire
Le testeur conçoit ses cas sans connaître le code interne. Il s'appuie sur les exigences, les règles métier et les contrats d'interface.
Exemples :
- Partitions d'équivalence
- Valeurs limites
- Tables de décisions
- Transitions d'état
- Cas d'utilisation
Boîte blanche
Le testeur exploite la connaissance du code pour couvrir les instructions, branches et chemins. Souvent portés par les développeurs.
Exemples :
- Couverture d'instructions, de décisions, de conditions, MC/DCModified Condition/Decision Coverage : chaque condition doit, seule, faire varier le résultat de la décision
- Couverture de chemins
Basés sur l'expérience
Quand la spécification est incomplète ou que le temps manque. La valeur vient de l'expertise et de la connaissance du domaine.
Exemples :
- Tests exploratoires
- Estimation d'erreurs (error guessing)
- Tests basés sur des checklists
- Attaques logicielles
02 — Boîte noire
Techniques boîte noire
Tester le logiciel de l'extérieur, en se basant sur les exigences, les entrées et les sorties attendues, sans regarder le code ni l'implémentation interne.
Partitions d'équivalence
Quand : Quand les entrées peuvent être groupées en classes traitées de la même façon.
Comment : Identifier les classes valides et invalides, puis un représentant par classe.
Exemple : Champ âge : [0–17] mineur, [18–64] adulte, [65+] senior, < 0 invalide, > 120 invalide. Au total 5 cas.
Valeurs limites
Quand : Aux frontières des partitions : c'est là que se cachent la majorité des bugs.
Comment : Tester min, min−1, min+1, max, max−1, max+1.
Exemple : Mot de passe entre 8 et 32 caractères → tester 7, 8, 9, 31, 32, 33.
Tables de décision
Quand : Plusieurs règles métier se combinent et produisent des résultats différents.
Comment : Lister les conditions en colonnes et les actions en lignes, pour couvrir chaque combinaison utile.
Exemple : Calcul d'une remise selon (client fidèle ? × panier > 100 € ? × code promo ?). 8 combinaisons à tester.
Transition d'état
Quand : Un système passe par des états successifs.
Comment : Modéliser les états, transitions, événements.
Exemple : Statut d'une commande : Panier → Payée → Préparée → Expédiée → Livrée. Tester aussi Payée → Remboursée.
Cas d'utilisation
Quand : Valider un parcours utilisateur de bout en bout.
Comment : Dérouler le scénario nominal, puis les scénarios alternatifs et d'exception.
Exemple : Acheter en ligne : ajout au panier → checkout → paiement OK / KO / 3DS3D Secure : protocole d'authentification renforcée pour le paiement en ligne / annulation.
Test par paires
Quand : Trop de combinaisons possibles entre paramètres (explosion combinatoire).
Comment : Couvrir toutes les paires de valeurs au lieu de toutes les combinaisons. Outils : PICT, AllPairs.
Exemple : 5 navigateurs × 4 OS × 3 langues × 2 thèmes = 120 combinaisons → ~20 avec pairwise.
03 — Boîte blanche
Techniques boîte blanche
Les niveaux de couverture s'empilent : chaque niveau supérieur implique le précédent. Plus c'est strict, plus c'est cher — à adapter selon le risque.
Couverture d'instructions
Chaque ligne de code est exécutée au moins une fois. Niveau le plus faible.
Couverture de décisions (branches)
Chaque condition if / else est évaluée à vrai ET à faux. Standard pour la plupart des projets.
Couverture de conditions
Chaque sous-condition booléenne prend les deux valeurs. Plus fin que la couverture de décisions.
MC/DCModified Condition/Decision Coverage : chaque condition doit, seule, faire varier le résultat de la décision
Modified Condition / Decision Coverage. Exigée pour le logiciel critique (DO-178C, aéronautique).
Couverture de chemins
Tous les chemins d'exécution. Théorique : explose vite avec les boucles.
04 — L'exploratoire
Tests basés sur l'expérience
Le testeur explore l'application en temps réel, en combinant découverte du produit, conception et exécution des tests, plutôt que de suivre un plan de test prédéfini ligne par ligne.
Tests exploratoires
Apprentissage, conception et exécution en parallèle. Cadré par des chartes (session-based test management).
Error guessing
Le testeur expérimenté anticipe les zones fragiles : champs vides, débordement, dates aux changements d'heure, caractères spéciaux.
Checklists
Listes de vérifications réutilisables (formulaires, accessibilité, sécurité, mobile). Complètent sans remplacer une conception structurée.
Attaques logicielles
Souvent utilisées en test d'intrusion : attaquer l'entrée, la sortie, la donnée, le calcul, l'interface.
05 — Exemple
Exemple combiné — un champ « code postal »
Exigence
Le champ « code postal » accepte 5 chiffres pour la France.
Partitions
Valides : 5 chiffres. Invalides : <5 chiffres, >5 chiffres, lettres, vide.
Valeurs limites
Tester en FR : 4 chiffres, 5 chiffres, 6 chiffres.
Table de décision
Code rempli ? × Format valide ? → on garde les 3 cas réalisables.
06 — Comment choisir
Choisir la bonne technique
"Tout tester"
Impossible, coûteux, inutile. Préférer un mix risque / couverture.
Spécifications claires & règle métier
Tables de décision, partitions, valeurs limites.
Workflow / cycle de vie
Transitions d'état, cas d'utilisation.
Spécifications floues ou peu de temps
Tests exploratoires + deviner où pourraient se cacher les erreurs.
Combinaisons multiples
En paire pour éviter l'explosion des cas possibles.
A retenir
En bref
- Boîte noire : partir des exigences et du comportement attendu ;
- Boîte blanche : partir du code et des chemins d'exécution ;
- Expérience : exploiter intuition, contexte et connaissance du produit ;
- Le bon mix de techniques dépend des risques et du temps disponible.
Pour aller plus loin