Vérifier une approbation avec des critères d’acceptation clairs

Décrivez résultat et état initial

Pour chaque parcours important, définissez qui peut agir, dans quelles conditions et quel état doit ensuite être démontrable. GOV.UK décrit les critères d’acceptation comme des résultats vérifiant le besoin utilisateur. Une promesse générale comme « l’approbation fonctionne » devient vérifiable avec ces conditions.

Exemple : approuver une demande interne de changement

Ce plan est entièrement fictif. La demande CH-27 commence en draft, passe à pending avec une justification complète et peut devenir approved par la personne chargée de la revue. Utilisez données synthétiques et comptes adaptés dans un environnement de test contrôlé. Le tableau contient des résultats attendus, pas des tests exécutés.

La dernière ligne suppose un refus certain avant modification. Si seule la réponse manque, l’état enregistré reste d’abord incertain ; prévoyez un test distinct de l’état réellement enregistré.

Vérifiez état, droits et retour affiché

Masquer un bouton ne démontre pas le contrôle d’accès. OWASP exige une vérification adaptée des droits à chaque requête. Incluez appels directs et état réellement enregistré. Un message de succès à l’écran ne suffit pas.

Préparez chaque cas avec un état initial défini. Playwright recommande des tests indépendants aux données et sessions contrôlées. Le rôle ou l’état d’un cas précédent ne doit pas déterminer discrètement le suivant. Convenez avec l’équipe de réalisation des contrôles de composants et parcours complets à automatiser.

Consignez version, environnement, rôle et données utilisées. Séparez résultats réels, constats et attentes ; un cas non exécuté reste ouvert. Faites évaluer les écarts par le responsable métier et répétez les cas concernés après correction.

Sources

• GOV.UK: Writing user stories

• OWASP: Authorization checks

• Playwright: Best practices