Les tables de décision sont utiles lorsque le comportement dépend de plusieurs conditions ensemble. QA organise systématiquement les combinaisons et voit quelles règles sont couvertes et lesquelles restent non testées.
Quand la technique est particulièrement utile
- →Plusieurs conditions d’entrée déterminent conjointement le résultat.
- →La logique textuelle devient difficile à suivre en détail.
- →Les combinaisons contradictoires ou rares comptent aussi, au-delà du parcours nominal.
- →Les membres de l’équipe peuvent interpréter différemment la même règle.
Construire une table de décision
- →Énumérez les conditions qui affectent le comportement.
- →Identifiez leurs états possibles : oui/non, valide/invalide, rôle A/rôle B, etc.
- →Enregistrez l’action attendue pour chaque combinaison significative.
- →Supprimez les combinaisons impossibles ou non pertinentes pour que le tableau reste lié au comportement réel.
Exemple
Considérez le paiement régi par trois facteurs : la disponibilité des stocks, un utilisateur authentifié et un paiement confirmé. Une table de décision clarifie plus clairement quand une commande peut être créée, quand une connexion est requise et quand l'opération doit être bloquée qu'une description en prose enchevêtrée.
Erreurs courantes
- →Inclure tous les états imaginables sans évaluer leur pertinence.
- →Ne pas distinguer les combinaisons impossibles des vraies.
- →Décrire vaguement les actions du système sans attentes concrètes.
- →Créer une table attrayante sans transformer ses règles en contrôles exécutables.
Les tables de décision transforment des règles métier vagues en carte de décision explicite. Elles sont particulièrement utiles en fintech, commerce électronique, contrôle d’accès, remises, tarification et processus métier.
Exemple de table de décision : remise pour les membres
Règle fictive : appliquer une remise de 10% seulement si le client est membre AND si le sous-total atteint au moins 100 unités monétaires entières. Sinon, aucune remise. Le sous-total est déjà validé ; taxes et livraison sont exclues. Les exemples utilisent des montants entiers pour éviter une règle d’arrondi non précisée.
Règle Membre ? Sous-total >= 100 ? Exemple de sous-total Remise Montant après remise
R1 Non Non 80 0% 80
R2 Non Oui 120 0% 120
R3 Oui Non 80 0% 80
R4 Oui Oui 120 10% 108Deux conditions booléennes indépendantes produisent quatre combinaisons ; tous les quatre sont réalisables selon cette spécification. Le tableau rend explicite la règle AND : l'adhésion seule est insuffisante, et un sous-total important seul est insuffisant. Si une condition est impossible dans le système réel, enregistrez pourquoi avant de supprimer sa règle.
Transformez une règle en scénario de test
Cas DT-R4
Préconditions : membre authentifié ; sous-total de 120 ; aucune autre promotion.
Action : demander le total de la commande.
Résultat attendu : remise de 10% ; montant de la remise de 12 ; montant après remise de 108.
Cas témoin DT-R2 : même sous-total, non-membre ; remise de 0 ; montant de 120.Toutes les règles de décision couvertes ne signifient pas que les limites numériques sont couvertes. Ajoutez les sous-totaux des membres 99, 100 et 101 : les taux attendus sont 0%, 10% et 10%. Si les montants exacts à payer peuvent être fractionnaires, définissez d’abord la précision et l’arrondi de la devise. Gardez ces contrôles distincts de l'application ou non de la réduction.
Exercice : remplacer AND par OR
Supposons que la règle devienne « client membre OR sous-total d’au moins 100 ». Quelles lignes changent ? R2 et R3 obtiennent maintenant 10% ; R1 reste sans remise et R4 garde 10%. Les montants attendus deviennent 80, 108, 72 et 108. Recalculez la table avant les tests pour ne pas conserver silencieusement l’ancienne hypothèse.