Test basé sur les risques — décider quoi NE PAS automatiser

L'idée, en une ligne

Dépensez votre effort de test là où une panne ferait le plus mal. Chaque test automatisé est du code que vous écrivez une fois et maintenez pour toujours, donc répartir l'effort uniformément sur toute l'app est un geste de débutant. Le test basé sur les risques vous aide à le dépenser à dessein.

Comment le noter

Le risque, c'est deux choses multipliées ensemble :

• Probabilité — quelle est la probabilité que ça casse ? Notez de 1 à 5.
• Impact — à quel point c'est grave si ça casse ? Notez de 1 à 5.
• Risque = probabilité × impact. Plus le chiffre est grand, plus ça mérite de test.

Voyez-le à l'œuvre

# Rank features by risk to decide how much to test each
features = [
    {"name": "checkout_payment", "prob": 4, "impact": 5},
    {"name": "profile_avatar",   "prob": 2, "impact": 1},
    {"name": "help_footer_link", "prob": 1, "impact": 1},
]

for f in features:
    f["risk"] = f["prob"] * f["impact"]

# Highest risk first -> most testing effort
for f in sorted(features, key=lambda f: f["risk"], reverse=True):
    plan = "automate deeply" if f["risk"] >= 8 else "smoke or skip"
    print(f'{f["name"]:16} risk={f["risk"]:>2}  -> {plan}')

Lisez-le de haut en bas : vous avez noté chaque fonctionnalité, multiplié, trié le plus risqué en premier, puis tracé une ligne — automatisation approfondie au-dessus, une vérification rapide ou rien en dessous.

Avancé — la technique suit le risque

Le risque ne décide pas juste si automatiser — il décide à quel point. La logique à haut risque mérite les outils rigoureux des deux dernières leçons : tables de décision complètes et balayages de valeurs limites. Les entrées à faible risque reçoivent une seule valeur d'un compartiment. Même boîte à outils, effort adapté à ce qui est en jeu.

Basé sur le guide Risk-Based Testing de Guru99 (probabilité × impact)