Les techniques de conception de cas de test sont des méthodes systématiques pour décider quelles entrées tester. Les cinq principales sont : le partitionnement par équivalence, l'analyse des valeurs aux limites, les tables de décision, le test de transitions d'état, et le test combinatoire par paires.

Partitionnement par équivalence : arrêter de tester la même chose deux fois

L'idée centrale est simple : si deux entrées produisent le même comportement, vous n'avez besoin d'en tester qu'une seule. Vous divisez l'espace d'entrée en groupes (appelés partitions ou classes d'équivalence) où chaque valeur du groupe se comporte de la même façon. Ensuite, vous testez une valeur représentative de chaque groupe.

Prenez un formulaire d'inscription avec un champ âge. L'exigence dit que les utilisateurs doivent avoir entre 18 et 65 ans. Vous pourriez tester chaque entier de 0 à 120, mais ça fait 121 cas de test. Le partitionnement par équivalence vous dit qu'il n'y a que quatre groupes qui comptent :

| Partition | Plage | Valeur exemple |

|---|---|---|

| Valide | 18 à 65 | 35 |

| Trop jeune (invalide) | En dessous de 18 | 10 |

| Trop âgé (invalide) | Au-dessus de 65 | 80 |

| Mauvais type (invalide) | Non numérique | "vingt" |

Quatre cas de test au lieu de 121. La logique : si 35 passe et que 36 passe aussi, tester 36 ne donne aucune information supplémentaire. Si 10 échoue correctement, 11 échouera aussi.

Le partitionnement par équivalence s'applique à toute entrée avec une plage valide définie. Cela inclut les champs texte avec limites de longueur et les menus déroulants avec valeurs autorisées. Les uploads de fichiers avec restrictions de taille et les paramètres API avec valeurs valides énumérées en sont aussi des exemples.

Analyse des valeurs aux limites : là où les bugs se cachent vraiment

Les développeurs font des erreurs aux limites. Une erreur de décalage d'un ressemble à if (age > 18) au lieu de if (age >= 18). Le partitionnement par équivalence trouve les partitions ; l'analyse des valeurs aux limites (AVL) teste les frontières entre elles.

Pour le même champ âge entre 18 et 65, l'AVL produit ces cas de test :

| Valeur | Frontière | Résultat attendu |

|---|---|---|

| 17 | Juste en dessous de la borne inférieure | Rejeté |

| 18 | Borne inférieure | Accepté |

| 19 | Juste au-dessus de la borne inférieure | Accepté |

| 64 | Juste en dessous de la borne supérieure | Accepté |

| 65 | Borne supérieure | Accepté |

| 66 | Juste au-dessus de la borne supérieure | Rejeté |

Six cas de test qui couvrent les deux limites des deux côtés. Combiné avec le partitionnement par équivalence (qui gère le milieu et le cas de mauvais type), vous obtenez une suite de tests complète pour ce champ. En tout, environ 8 à 10 cas de test suffisent.

L'AVL fonctionne partout où il y a une frontière. Cela couvre les longueurs maximales de caractères, les quantités minimales de commande, et les limites de taille de fichier. Les plages de dates, les nombres de pages de pagination, et les limites de débit des API en sont d'autres exemples courants. Le schéma est toujours le même : tester la valeur à la limite, une en dessous, et une au-dessus.

Quand vous trouvez un bug avec l'AVL, c'est presque toujours exactement à la limite. Un champ âge qui rejette 65 mais accepte 64 et 66 révèle une erreur de décalage d'un. Nommez cela précisément dans votre rapport de bug. "Défaillance de condition aux limites à la borne supérieure" aide le développeur à le trouver plus vite.

Tables de décision : rendre la logique métier visible

Certaines fonctionnalités n'ont pas une seule entrée avec une plage ; elles ont plusieurs conditions qui se combinent pour produire différents résultats. Remises au checkout, règles d'accès au contenu, mises à niveau d'abonnement, préférences de notification : tout cela a une logique combinatoire complexe difficile à comprendre depuis les seules exigences.

Les tables de décision rendent cette logique explicite. Chaque colonne est un cas de test. Chaque ligne est soit une condition, soit un résultat.

Prenez une fonctionnalité de remise : les utilisateurs obtiennent une remise s'ils ont une carte de fidélité ou si leur total d'achat dépasse 100 €. Les combinaisons ressemblent à ceci :

| | Cas 1 | Cas 2 | Cas 3 | Cas 4 |

|---|---|---|---|---|

| A une carte de fidélité | Non | Oui | Non | Oui |

| Achat > 100 € | Non | Non | Oui | Oui |

| Obtient la remise | Non | Oui | Oui | Oui |

C'est une règle OU, donc trois cas sur quatre aboutissent à une remise. Quatre cas de test, un par colonne. Si la règle était ET (doit avoir une carte de fidélité ET un achat de plus de 100 €), seul le Cas 4 serait éligible. La table le montrerait immédiatement, et vous sauriez qu'il faut tester les quatre combinaisons pour confirmer la logique.

Les tables de décision excellentissent quand les exigences contiennent des mots comme "si", "quand", "sauf si", "mais seulement si". Ces mots signalent que la logique conditionnelle doit être cartographiée. La table vous force à énumérer chaque combinaison, ce qui révèle souvent des cas que les exigences n'ont pas spécifiés. Que se passe-t-il si l'utilisateur n'a pas de carte de fidélité et que sa commande est exactement à 100 € ? La table rend cette ambiguïté visible avant le développement, quand elle est peu coûteuse à résoudre.

Pour une fonctionnalité avec trois conditions binaires, vous obtenez 2³ = 8 combinaisons. Pour quatre conditions, 16. Les tables de décision n'exigent pas toujours de tester toutes les combinaisons, car certaines peuvent être impossibles ou non pertinentes. Elles vous aident à voir l'espace complet avant de décider lesquelles éliminer.

Test de transitions d'état : les fonctionnalités qui se souviennent de leur chemin

Certaines fonctionnalités ne se contentent pas de répondre aux entrées ; elles maintiennent un état, et les actions valides dépendent de l'état dans lequel elles se trouvent. Les flux d'authentification, les workflows de statut de commande, la gestion des abonnements, le cycle de vie d'un compte utilisateur : tous se comportent différemment selon ce qui s'est déjà passé.

Le test de transitions d'état cartographie les états dans lesquels une fonctionnalité peut se trouver. Il identifie aussi les événements qui causent des transitions entre états, et les comportements attendus lors de chaque transition.

Prenez la gestion des comptes utilisateur. Un compte peut être Actif, Bloqué, ou Suspendu. Les transitions entre eux sont déclenchées par des événements spécifiques :

| État actuel | Événement | État suivant | Comportement attendu |

|---|---|---|---|

| Actif | 5 échecs de connexion | Bloqué | Afficher message de blocage, bloquer les tentatives |

| Actif | Suspension admin | Suspendu | Afficher notification de suspension, déconnecter les sessions |

| Bloqué | 15 minutes s'écoulent | Actif | Permettre à nouveau les tentatives de connexion |

| Bloqué | Déblocage admin | Actif | Accès immédiat restauré |

| Suspendu | Réintégration admin | Actif | Compte restauré, utilisateur notifié |

| Suspendu | 5 échecs de connexion | Suspendu | Rester suspendu (pas de transition) |

De cette table, vous dérivez deux types de cas de test. Le premier vérifie les transitions valides : confirmer que "Actif + 5 échecs de connexion → Bloqué" fonctionne comme documenté. Le second vérifie les transitions invalides, par exemple qu'un compte Suspendu ne peut pas passer à Bloqué en tentant une connexion, et que le système gère correctement ce cas limite.

La table révèle aussi les lacunes. Que se passe-t-il si un compte Bloqué reçoit un événement "Suspension admin" ? Les exigences ne le disent peut-être pas. Les diagrammes de transitions d'état rendent ces lacunes visibles sous forme de cellules vides.

Le test de transitions d'état est particulièrement utile pour les workflows que les QA juniors ont tendance à sous-tester. Que se passe-t-il si vous déclenchez une action sur un objet déjà dans le "mauvais" état ? Et si vous réalisez l'étape 3 avant l'étape 2 ? Les transitions valides sont évidentes ; c'est dans les invalides que les bugs se cachent.

Test combinatoire : quand les combinaisons explosent

Certaines fonctionnalités ont tellement de variables d'entrée qu'une table de décision complète est impraticable. Un filtre de recherche avec 5 options, chacune avec 3 à 4 valeurs possibles, produit des milliers de combinaisons. Vous ne pouvez pas toutes les tester.

Le test par paires (aussi appelé all-pairs testing) est la réponse pratique. La recherche montre que la plupart des bugs sont causés par des interactions entre deux variables, pas trois ou plus. Le test par paires garantit que chaque paire de valeurs de différentes variables apparaît dans au moins un cas de test.

Imaginez tester un formulaire de réservation de voyage avec ces options :

  • Destination : Europe, Asie, Amériques (3 valeurs)
  • Type de voyage : aller simple, aller-retour (2 valeurs)
  • Classe : Économique, Affaires, Première (3 valeurs)
  • Mois de départ : Été, Hiver (2 valeurs)

Test factoriel complet : 3 × 2 × 3 × 2 = 36 combinaisons. Le test par paires couvre toutes les paires en environ 9 cas de test.

Vous ne construisez pas les ensembles de tests par paires à la main. Des outils le font pour vous. PICT (Pairwise Independent Combinatorial Testing) est un outil en ligne de commande gratuit de Microsoft. AllPairs en est un autre. Vous définissez vos paramètres et valeurs, exécutez l'outil, et obtenez un ensemble de tests minimal.

Le test par paires est le bon choix quand vous avez 4 variables ou plus avec plusieurs valeurs chacune. Il convient aussi quand la couverture combinatoire complète n'est pas faisable dans le temps disponible. Utilisez-le dès que vous avez besoin d'une méthode défendable pour réduire le périmètre des tests sans deviner quelles combinaisons sauter.

Quelle technique utiliser : guide de décision

Les techniques ne sont pas mutuellement exclusives. La plupart des fonctionnalités réelles en utilisent plus d'une. Voici comment choisir :

Le partitionnement par équivalence convient à toute entrée avec une plage valide définie : champs âge, plages de prix, limites de longueur de caractères, valeurs valides énumérées. Utilisez-le pour organiser les entrées avant d'écrire les cas de test individuels. L'analyse des valeurs aux limites s'associe au partitionnement par équivalence pour les mêmes situations. Chaque fois que le partitionnement identifie une limite, ajoutez des cas de test AVL autour de cette limite. Toujours. Les tables de décision conviennent aux fonctionnalités avec plusieurs conditions indépendantes qui se combinent pour produire différents résultats. Si les exigences utilisent une logique "si/et/ou/sauf si", construisez une table de décision avant d'écrire des cas de test. Le test de transitions d'état convient aux fonctionnalités qui ont un cycle de vie ou un workflow défini. Si un objet (utilisateur, commande, ticket, abonnement) peut être dans différents états et transition entre eux, cartographiez d'abord les états, puis dérivez les cas de test. Le test par paires convient aux tests de configuration et aux fonctionnalités avec de nombreuses variables indépendantes. Si vous avez plus de 3 à 4 variables et que la couverture complète est impraticable, utilisez un outil de test par paires.

Pour un champ de saisie simple sans état et sans logique multi-conditions, le partitionnement par équivalence plus l'AVL est tout ce dont vous avez besoin. Pour un flux de checkout complexe (remises, niveaux d'utilisateur, méthodes de paiement), les tables de décision plus le test de transitions d'état donnent une couverture plus complète que l'instinct seul.

Comment appliquer ça dès lundi matin

Vous n'avez pas besoin de tout refondre votre processus de test d'un coup. Prenez une fonctionnalité que vous testez cette semaine et appliquez une technique.

Si vous testez un champ de saisie avec des contraintes min/max : rédigez les partitions d'équivalence sur papier avant d'ouvrir l'application. Identifiez les limites. Rédigez les cas de test AVL. Vous aurez un test de champ complet en cinq minutes au lieu de taper des valeurs aléatoires pendant vingt.

Si vous testez une règle métier avec plusieurs conditions (logique de remise, contrôle d'accès, déclencheurs de notification) : construisez la table de décision avant d'écrire des cas de test. Chaque colonne devient un cas de test. Vérifiez si des combinaisons sont ambiguës dans les exigences et demandez avant de tester.

Si vous testez un workflow avec des changements de statut (gestion des commandes, cycle de vie des utilisateurs, routage des tickets de support) : dessinez le diagramme d'état, même grossièrement. Listez les transitions valides et les événements qui les déclenchent. Puis écrivez deux cas de test par transition, un qui confirme que ça fonctionne et un qui essaie une transition invalide depuis un état similaire.

L'objectif n'est pas d'appliquer chaque technique à chaque fonctionnalité. C'est d'arrêter de s'appuyer sur la mémoire et l'instinct pour des décisions qui ont des réponses correctes et systématiques. Les techniques transforment "que dois-je tester ?" d'une question à laquelle vous répondez différemment à chaque fois en un processus que vous pouvez répéter, défendre et enseigner.

→ See also: Comment Écrire un Cas de Test: Format, Exemples et Erreurs Courantes | Tests Basés sur les Risques: Prioriser ce qu'il Faut Tester Quand On Ne Peut Pas Tout Tester | Partition d'Équivalence et Analyse des Valeurs Limites: Guide Pratique | Cas de Test vs Scénario de Test: Différence et Quand Utiliser Chacun