01 — Les grandes familles
Trois grandes familles
Boîte noire
Le•la testeur•se conçoit ses cas sans connaître le code interne. Il•elle 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•la testeur•se exploite la connaissance du code pour couvrir les instructions, branches et chemins. Souvent portés par les développeur•ses.
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. Cliquez sur une carte pour voir quand l'utiliser, comment, et un exemple. Les techniques marquées Hors syllabus Fondation sont utiles en pratique mais dépassent le programme actuel de l'examen ISTQB Fondation (v4.0).
Partitions d'équivalence
Quand : Lorsque 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–120] 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•e fidèle ? × panier > 100 € ? × code promo ?). 8 combinaisons à tester. Dans le tableau : O = Oui, N = Non.
| R1 | R2 | R3 | R4 | R5 | R6 | R7 | R8 | |
|---|---|---|---|---|---|---|---|---|
| Client•e fidèle ? | N | N | N | N | O | O | O | O |
| Panier > 100 € ? | N | N | O | O | N | N | O | O |
| Code promo ? | N | O | N | O | N | O | N | O |
| Remise appliquée | 0% | 10% | 5% | 15% | 5% | 15% | 10% | 20% |
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
Hors syllabus FondationVa au-delà du programme ISTQB Fondation actuel.
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
Hors syllabus FondationVa au-delà du programme ISTQB Fondation actuel.
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 sont de plus en plus exigeants, mais ne s'emboîtent pas automatiquement : 100 % de couverture de conditions n'implique pas 100 % de couverture de décisions (on peut faire varier chaque condition sans jamais évaluer la décision globale à faux). Cliquez sur une carte pour voir un exemple concret. Seules la couverture d'instructions et la couverture de décisions sont examinables au niveau Fondation ; les niveaux marqués Hors syllabus Fondation relèvent du niveau Advanced.
Couverture d'instructions
Chaque ligne de code est exécutée au moins une fois. Niveau le plus faible.
Exemple : Un test qui appelle la fonction une seule fois, sans se soucier des branches, suffit à couvrir chaque instruction.
Couverture de décisions (branches)
Chaque condition if / else est évaluée à vrai ET à faux. Standard pour la plupart des projets.
Exemple : Un if (age >= 18) exige au moins un cas avec age >= 18 et un cas avec age < 18.
Couverture de chemins
Tous les chemins d'exécution. Théorique : explose vite avec les boucles.
Exemple : Une simple boucle de 10 itérations avec 2 branches internes génère déjà des milliers de chemins possibles.
Couverture de conditions
Hors syllabus FondationVa au-delà du programme ISTQB Fondation actuel (niveau Advanced Technical Test Analyst). Ces informations sont utiles pour la pratique, mais ne font pas partie des besoins de connaissance niveau Fondation.
Chaque sous-condition booléenne prend les deux valeurs. Plus fin que la couverture de décisions.
Exemple : if (a && b) exige de faire varier a et b indépendamment, pas seulement le résultat global.
MC/DCModified Condition/Decision Coverage : chaque condition doit, seule, faire varier le résultat de la décision
Hors syllabus FondationVa au-delà du programme ISTQB Fondation actuel (niveau Advanced Technical Test Analyst). Ces informations sont utiles pour la pratique, mais ne font pas partie des besoins de connaissance niveau Fondation.
Modified Condition / Decision Coverage. Exigée pour le logiciel critique (DO-178C, aéronautique).
Exemple : Pour if (a && b), chaque condition doit, en changeant seule, faire basculer le résultat de la décision.
04 — L'exploratoire
Tests basés sur l'expérience
Le•la testeur•se 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).
Exemple : Explorer librement le tunnel de paiement pendant 60 minutes, sans script, en notant chaque anomalie rencontrée.
Error guessing
Le•la testeur•se expérimenté•e anticipe les zones fragiles : champs vides, débordement, dates aux changements d'heure, caractères spéciaux.
Exemple : Saisir une date de naissance au 29 février d'une année non bissextile pour voir si le formulaire la rejette correctement.
Checklists
Listes de vérifications réutilisables (formulaires, accessibilité, sécurité, mobile). Complètent sans remplacer une conception structurée.
Exemple : Reprendre la checklist accessibilité de l'équipe (contrastes, focus clavier, alt text) sur chaque nouvelle page livrée.
Attaques logicielles
Souvent utilisées en test d'intrusion : attaquer l'entrée, la sortie, la donnée, le calcul, l'interface.
Exemple : Injecter un script dans un champ de commentaire pour vérifier qu'il est bien échappé et non exécuté (XSSCross-Site Scripting : faille qui permet d'injecter du code (souvent JavaScript) exécuté dans le navigateur d'autres utilisateur•rices.).
05 — Exemple
Exemple : un champ « code postal »
Une même règle métier peut se décliner avec plusieurs techniques combinées, étape par étape.
Exigence
Le champ « code postal » accepte 5 chiffres pour la France.
Partitions
Valide : 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 (O = Oui, N = Non, – = valeur indifférente).
| R1 | R2 | R3 | |
|---|---|---|---|
| Code rempli ? | O | O | N |
| Format valide (5 chiffres) ? | O | N | – |
| Résultat | Accepté | Rejeté (format) | Rejeté (vide) |
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
Ce qu'il faut retenir
Boîte noire, depuis les exigences
Partir des exigences et du comportement attendu, sans regarder le code.
Boîte blanche, depuis le code
Partir du code et des chemins d'exécution pour couvrir la structure interne.
L'expérience, comme troisième voie
Exploiter intuition, contexte et connaissance du produit, quand la spécification ne suffit pas.
Le bon mix, selon le contexte
Le bon mix de techniques dépend des risques et du temps disponible.
Mise en pratique
Testez votre compréhension
Une sélection de questions basées sur ce que vous venez de lire.
Un champ « âge » est découpé en [0–17], [18–64] et [65+], puis on choisit un représentant par classe. Quelle technique est utilisée ?
Un mot de passe doit contenir entre 8 et 32 caractères. Quelles valeurs teste-t-on en priorité avec la technique des valeurs limites ?
Une remise dépend de trois critères combinés (client•e fidèle ? × panier > 100€ ? × code promo ?). Quelle technique couvre le mieux ces combinaisons ?
5 navigateurs × 4 OS × 3 langues représentent 60 combinaisons. Quelle technique réduit ce nombre sans perdre l'essentiel de la couverture ?
Un if (a && b) doit voir chaque sous-condition (a, puis b) faire varier seule le résultat de la décision. De quel niveau de couverture boîte blanche s'agit-il ?
Les spécifications sont floues et le temps manque. Quelle famille de techniques privilégier ?
À 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