Tables de décision & transitions d'état

L'idée, en une ligne

Quand plusieurs conditions oui/non se combinent, écrivez chaque combinaison et son résultat. Cette grille est une table de décision, et elle vous empêche de tester le cas nominal et de crier victoire.

Combien de lignes ?

• Avec n conditions oui/non vous obtenez 2 puissance n combinaisons.
• 2 conditions → 4 lignes. 3 conditions → 8 lignes.
• La table garantit que vous avez considéré chacune, pas juste les évidentes.

Voyez-le à l'œuvre

En automatisation la table n'est pas un tableur — ce sont juste des données : une liste de lignes passée à un seul test. Nouvelle règle ? Ajoutez une ligne.

# Decision table as data: 2 conditions -> 4 rows
# (in_window, item_returned, expected_action)
rules = [
    (True,  True,  "refund"),
    (True,  False, "reject"),
    (False, True,  "reject"),
    (False, False, "reject"),
]

def decide(in_window, item_returned):
    return "refund" if in_window and item_returned else "reject"

for in_window, returned, expected in rules:
    assert decide(in_window, returned) == expected
print(f"{len(rules)} rules covered")   # 4 rules covered

Lisez-le de haut en bas : vous avez listé les quatre combinaisons, écrit la règle une fois, puis vérifié la règle contre chaque ligne. Rien ne passe à travers.

Avancé — quand l'ordre compte

Les tables de décision attrapent les mauvaises combinaisons. Mais certaines fonctionnalités ont une mémoire, où la même action signifie des choses différentes selon ce qui s'est passé avant. C'est là qu'intervient le test de transition d'état.

• Une connexion qui se verrouille après trois échecs — le quatrième essai se comporte différemment du premier.
• Une commande passant de nouvelle → payée → expédiée — chaque étape n'a de sens qu'à partir du bon point de départ.
• Testez les mouvements légaux et les illégaux : pouvez-vous expédier une commande qui n'a jamais été payée ?

Basé sur le guide Decision Table Testing de Guru99 (aligné sur l'ISTQB)