Les critères d’acceptation sont-ils suffisamment précis pour tester votre produit ?
Des critères d’acceptation imprécis créent des incompréhensions entre métiers, produit et IT. Découvrez comment les rendre testables et utiles.
QUALITÉ LOGICIELLE & QA
9/30/20253 min read
Une grande partie des difficultés de recette commence avant l’écriture du premier test.
Lorsque les critères d’acceptation sont vagues, chaque acteur peut avoir une interprétation différente du résultat attendu. Le métier pense avoir décrit le besoin, l’équipe produit pense avoir suffisamment détaillé la fonctionnalité et la QA découvre, au moment de la recette, qu’il manque des règles importantes.
Le test ne devrait pas être le premier moment où l’organisation cherche à définir ce que le produit doit faire.
Un critère d’acceptation doit permettre une décision
Un bon critère d’acceptation doit aider à répondre à une question précise :
La fonctionnalité peut-elle être considérée comme conforme dans cette situation ?
Il doit donc préciser :
le contexte ;
les données ou conditions de départ ;
l’action réalisée ;
le résultat attendu ;
les règles applicables ;
les cas d’erreur ;
les éventuelles limites.
« L’utilisateur peut créer une commande » est trop général.
Il faut notamment préciser :
quels utilisateurs peuvent la créer ;
quelles informations sont obligatoires ;
quelles règles s’appliquent ;
ce qui se passe si une donnée est invalide ;
quels systèmes sont mis à jour ;
quel message est affiché ;
comment la commande peut être modifiée ou annulée.
Les formulations qui posent problème
Certaines formulations semblent compréhensibles mais restent difficiles à tester :
« l’écran doit être rapide » ;
« la recherche doit être intuitive » ;
« le traitement doit être sécurisé » ;
« le résultat doit être cohérent » ;
« le système doit gérer les erreurs » ;
« le parcours doit être simple ».
Ces attentes doivent être transformées en éléments observables.
Par exemple :
temps de réponse attendu dans une condition donnée ;
nombre d’actions nécessaires ;
profils autorisés ;
message affiché ;
comportement en cas de données absentes ;
journalisation attendue ;
blocage ou poursuite du traitement.
La QA doit intervenir suffisamment tôt
Associer la QA au moment de la recette finale limite sa capacité à détecter les ambiguïtés.
Une intervention plus en amont permet de poser des questions utiles :
Que se passe-t-il dans les cas limites ?
Le besoin concerne-t-il tous les profils ?
Quelles données sont réellement disponibles ?
Quelles règles doivent être prioritaires ?
Que doit-il se passer en cas d’échec ?
Quels systèmes externes sont concernés ?
Ces questions ne retardent pas nécessairement le projet. Elles évitent surtout de déplacer les décisions au moment où elles coûtent le plus cher.
Tester le scénario nominal ne suffit pas
Un critère d’acceptation doit prendre en compte plusieurs situations :
fonctionnement normal ;
donnée absente ;
donnée invalide ;
doublon ;
droit insuffisant ;
service externe indisponible ;
interruption du traitement ;
volume inhabituel ;
reprise après erreur.
Les cas limites sont souvent à l’origine des anomalies les plus coûteuses, car ils sont peu visibles dans les démonstrations et les parcours nominaux.
La traçabilité apporte de la visibilité
Dans les projets complexes, il est utile de relier :
l’exigence ;
le critère d’acceptation ;
le cas de test ;
le résultat ;
l’anomalie éventuelle ;
la décision de mise en production.
Cette traçabilité ne doit pas devenir une production documentaire disproportionnée. Elle doit permettre de répondre rapidement à trois questions :
Qu’avons-nous décidé de vérifier ?
Quel a été le résultat ?
Quel risque reste éventuellement ouvert ?
À retenir
Des critères d’acceptation efficaces sont :
précis ;
observables ;
testables ;
associés à un contexte ;
complétés par des cas d’erreur ;
compris par les métiers, le produit et la QA.
Les principes ISTQB rappellent notamment que les tests doivent commencer tôt et qu’ils permettent de révéler la présence de défauts, sans prouver leur absence totale.astqb
pragmaIT accompagne les équipes sur la recette fonctionnelle, la stratégie de test, l’AMOA, l’analyse des exigences et l’industrialisation QA.
Nous connectons les talents IT aux besoins des entreprises.
Vous souhaitez être contacté ?
© 2025. pragmaIT S.A.S - Tous droits réservés
Mentions légales
Nos offres