Prioriser les tests par le risque : AMDEC et ROAM

Noter chaque fonction selon la gravité, la fréquence et la probabilité de non-détection (AMDEC) pour décider quoi tester en priorité, et traiter les risques en Resolved, Owned, Accepted ou Mitigated (ROAM).

Pour qui, pour quand

Qualité logiciellePriorisationGrand groupeB2BSaaSPOPMEngineering Manager

En résumé

Comme tout ne peut pas être testé à chaque sprint, l'AMDEC priorise. Chaque fonction est notée de 1 à 4 sur la gravité de l'impact (en binôme avec le PO), la fréquence d'apparition et le coût d'une non-détection. La criticité (le produit des notes) dit quoi tester d'abord et délimite le périmètre de non-régression.

Le modèle ROAM classe les risques identifiés : Resolved (écarté), Owned (quelqu'un s'en charge), Accepted (l'équipe en assume les conséquences), Mitigated (atténué). Tout risque doit finir dans une de ces quatre cases.

Méthode étape par étape

dans l'ordre, sans en sauter

01Lister les fonctions du périmètre.
02Noter chacune de 1 à 4 : gravité (avec le PO), fréquence, non-détection.
03Calculer la criticité et trier.
04Tester en priorité les plus critiques et en faire le socle de non-régression.
05Classer chaque risque restant en ROAM, avec un responsable.

Questions à me poser

avant de te lancer

→Quelle fonction, si elle casse, coûte le plus aux clients ?
→Quels risques avons-nous acceptés, et qui le sait ?

Ce qui coûte cher

les pièges déjà vus sur ce sujet

Répartir l'effort de test de façon égale entre toutes les fonctions.

Des risques identifiés que personne ne suit.

Dans ma bible

Tests logiciels · p. 214-216

Chargement du passage…

Mes notes

ce que tu retiens, ton contexte

À jour · stocké dans ce navigateur

Situations couvertes

· On ne peut pas tout tester à chaque sprint
· Je dois gérer les risques d'une livraison

Provenance

Ma bible PM · Tests logiciels, p. 214-216

ajoutée le 2026-09-18

Mots-clés

amdecfmearoamrisquescriticitétests de régressionpriorisation des tests