Tests d'Acceptation Utilisateur (UAT)
Cadre UAT de bout en bout couvrant la génération de plans, l'exécution, la validation des parties prenantes et les décisions de mise en production (go/no-go). L'UAT est la dernière barrière de qualité avant la production — traitez-la comme telle. Aucune fonctionnalité n'est livrée sans une validation explicite des parties prenantes par rapport aux critères d'acceptation.
Prétraitement (Contexte Automatique)
Avant de commencer, rassemblez silencieusement le contexte du projet :
- Lisez
PORTFOLIO.mds'il existe dans la racine du projet ou les répertoires parents pour le contexte produit/équipe - Exécutez :
cat package.json 2>/dev/null || cat build.gradle.kts 2>/dev/null || cat Podfile 2>/dev/nullpour détecter la stack - Exécutez :
git log --oneline -5 2>/dev/nullpour les modifications récentes - Exécutez :
ls src/ app/ lib/ functions/ 2>/dev/nullpour comprendre la structure du projet - Utilisez ce contexte pour adapter toutes les sorties au projet réel
Étape 1 : Classifier le Besoin UAT
Déterminez le type d'UAT avant de construire le plan. Le type dicte la portée, la profondeur, l'implication des parties prenantes et le calendrier.
| Type d'UAT | Déclencheur | Portée | Durée Typique |
|---|---|---|---|
| UAT Nouvelle Fonctionnalité | Développement terminé, fusionné dans staging | Tous les critères d'acceptation du PRD/user stories, chemin heureux complet + cas limites | 2-5 jours ouvrés |
| UAT de Régression | Refactorisation majeure, mise à jour de dépendance ou migration de plateforme | Parcours utilisateur critiques revérifiés, aucune régression de comportement | 1-3 jours ouvrés |
| UAT Candidat à la Release | Branche de release créée, toutes les fonctionnalités intégrées | Périmètre complet de la release — chaque fonctionnalité, point d'intégration et comportement multiplateforme | 3-5 jours ouvrés |
| Validation de Correctif | Bug de production corrigé, patch déployé en staging | Périmètre restreint — vérifier le correctif, confirmer l'absence d'effets secondaires sur les flux adjacents | 2-4 heures |
Si le type d'UAT n'est pas clair, demandez avant de continuer. Une validation de correctif et une UAT de candidat à la release nécessitent des plans fondamentalement différents.
Collecte Automatique de Contexte
Avant de créer le plan UAT :
- Recherchez les specs de test existants, fichiers PRD, documents de critères d'acceptation
- Lisez toutes les specs trouvées pour extraire les exigences testables
- Recherchez les feature flags qui contrôlent les fonctionnalités testées
Génération d'Artéfacts (Requis)
Générer en utilisant Write :
- Plan UAT :
docs/uat/uat-plan.md— en utilisant le style de sortie du plan de test - Cas de test :
docs/uat/test-cases.md— cas de test détaillés avec étapes et résultats attendus - Formulaire de validation :
docs/uat/sign-off.md— modèle d'approbation pour les parties prenantes - Modèle de triage de bugs :
docs/uat/bug-triage.md— guide de classification de sévérité
Étape 2 : Rassembler le Contexte
Collectez toutes les entrées avant de rédiger le plan UAT. Un contexte manquant produit des plans incomplets.
| Entrée | Requise | Source | Notes |
|---|---|---|---|
| Nom de la fonctionnalité/version de release | Oui | PM/Chef Technique | Identifiant court pour le suivi |
| Critères d'acceptation | Oui | PRD, user stories, tickets Jira/Linear | Utiliser la sortie de la compétence /sdlc si disponible |
| Liste des parties prenantes | Oui | PM/Product Owner | Qui teste, qui valide, qui a un droit de veto |
| Environnement cible | Oui | Ingénierie | URL de staging, numéro de build, feature flags |
| Plateforme(s) | Oui | Ingénierie | Android, iOS, Web ou combinaison |
| Exigences de conformité | Facultatif | Juridique/Sécurité | Contraintes HIPAA, SOC 2, PCI-DSS, RGPD sur les données de test |
| Risques ou limitations connus | Facultatif | Ingénierie | Dette technique, problèmes connus, intégrations incomplètes |
| Résultats UAT précédents | Facultatif | QA/PM | Référence pour la comparaison de régression |
| Date limite de release | Oui | PM | Date ferme vs. flexible — influence la pression go/no-go |
Si les critères d'acceptation n'existent pas, arrêtez-vous et créez-les d'abord en utilisant la compétence /sdlc. L'UAT sans critères d'acceptation est un test basé sur l'opinion — il ne prouve rien.
Étape 3 : Génération du Plan UAT
3.1 Extraction des Critères d'Acceptation
Extrayez les critères d'acceptation de chaque source et normalisez-les en énoncés testables.
Format : Étant donné [précondition], Quand [action], Alors [résultat attendu]
Priorité des sources :
1. Critères d'acceptation du PRD (autoritaires)
2. Critères d'acceptation des user stories (détaillés)
3. Spécifications de conception / prototypes (comportement visuel et d'interaction)
4. Contrats API (formes de réponse, codes d'erreur)
5. Cas limites identifiés lors de la revue de code ou /feature-audit
Chaque critère d'acceptation devient un ou plusieurs scénarios de test. Si un critère ne peut pas être testé manuellement, signalez-le et spécifiez la méthode de vérification automatisée.
3.2 Matrice de Scénarios de Test
Construisez la matrice complète des scénarios. Chaque scénario a exactement un résultat attendu.
| ID | Catégorie | Scénario | Précondition | Étapes | Résultat Attendu | Plateforme | Priorité |
|---|---|---|---|---|---|---|---|
| UAT-001 | Chemin Heureux | [Flux de succès principal] | [État initial] | [1. 2. 3.] | [Résultat attendu] | Toutes | P0 |
| UAT-002 | Chemin Heureux | [Flux de succès secondaire] | [État initial] | [1. 2. 3.] | [Résultat attendu] | Toutes | P0 |
| UAT-003 | Cas Limite | [Condition limite] | [État initial] | [1. 2. 3.] | [Résultat attendu] | Toutes | P1 |
| UAT-004 | État d'Erreur | [Entrée invalide / échec] | [État initial] | [1. 2. 3.] | [Gestion d'erreur] | Toutes | P1 |
| UAT-005 | Multiplateforme | [Comportement spécifique à la plateforme] | [État initial] | [1. 2. 3.] | [Attente plateforme] | Spécifique | P1 |
| UAT-006 | Accessibilité | [Lecteur d'écran / navigation clavier] | [AT activé] | [1. 2. 3.] | [Résultat accessible] | Toutes | P1 |
| UAT-007 | Performance | [Temps de chargement / réactivité] | [Conditions standard] | [1. 2. 3.] | [Dans le budget] | Toutes | P2 |
| UAT-008 | Hors ligne/Dégradé | [Aucune connectivité / signal faible] | [Mode avion / limité] | [1. 2. 3.] | [Gestion gracieuse] | Mobile | P1 |
Définitions des priorités :
- P0 — Fonctionnalité de base. En cas d'échec, la fonctionnalité ne fonctionne pas. Bloque la release.
- P1 — Comportement important. En cas d'échec, la fonctionnalité fonctionne mais avec des lacunes significatives. Doit être corrigé avant la release.
- P2 — Vérification agréable à avoir. En cas d'échec, peut être livré avec un problème connu documenté.
3.3 Liste de Vérification de l'Environnement
Vérifiez l'environnement de test avant le début de l'UAT. Un environnement cassé fait perdre du temps aux parties prenantes et érode la confiance.
LISTE DE VÉRIFICATION PRÉ-UAT DE L'ENVIRONNEMENT
[ ] Environnement de staging déployé avec le bon build/version
[ ] Version du build documentée : _______________
[ ] Feature flags activés pour le périmètre UAT :
[ ] Flag : _____________ = ON/OFF
[ ] Flag : _____________ = ON/OFF
[ ] Données de test amorcées (comptes, contenu, transactions)
[ ] Comptes de test créés avec les rôles/autorisations requis
(voir la compétence /test-accounts pour le provisionnement des comptes)
[ ] Intégrations tierces en mode test/sandbox :
[ ] Stripe : mode test avec clés API de test
[ ] Processeur de paiement : environnement sandbox
[ ] Email/SMS : intercepté ou utilisant des destinataires de test
[ ] Analytics : propriété dev/staging (pas la production)
[ ] Backend/API pointant vers le staging (pas la production)
[ ] Base de données amorcée avec un volume de données représentatif
[ ] Notifications push configurées pour le staging
[ ] Deep links / Universal Links configurés pour le domaine de staging
[ ] Certificats SSL valides sur le staging
[ ] Accès VPN/réseau configuré pour tous les testeurs
3.4 Tableau des Rôles des Parties Prenantes
Définissez qui fait quoi. L'ambiguïté dans les rôles signifie des lacunes dans la couverture.
| Rôle | Personne | Responsabilités | Autorité de Validation |
|---|---|---|---|
| Responsable UAT | [Nom] | Possède le plan UAT, coordonne les sessions, trie les bugs, produit le rapport | Recommandation finale go/no-go |
| Product Owner | [Nom] | Valide que les critères d'acceptation sont remplis, teste les scénarios métier | Oui — validation métier |
| Responsable Design | [Nom] | Valide la fidélité visuelle, les modèles d'interaction, la cohérence de la marque | Oui — validation design |
| Responsable Ingénierie | [Nom] | Disponible pour l'investigation des bugs, les corrections d'environnement, explique les contraintes techniques | Oui — validation technique |
| Testeur QA | [Nom] | Exécute les scénarios de test systématiquement, documente les résultats avec preuves | Non — rapporte au Responsable UAT |
| Expert Métier | [Nom] | Teste les workflows spécifiques au domaine (finance, santé, juridique) | Oui — validation métier |
| Testeur Accessibilité | [Nom] | Test de lecteur d'écran, navigation clavier, vérification WCAG AA | Consultatif — remonte au Responsable UAT |
La validation minimale requise nécessite : Product Owner + Responsable Ingénierie. Toutes les autres validations sont recommandées mais dépendent du périmètre.
Étape 4 : Cadre d'Exécution UAT
Voir reference/details.md (section « Step 4: UAT Execution Framework ») pour les détails complets.
Étape 5 : Validation et Décision Go/No-Go
5.1 Matrice de Décision Go/No-Go
La décision go/no-go est basée sur les données, pas sur l'opinion. Notez chaque critère et calculez le résultat pondéré.
MATRICE DE DÉCISION GO / NO-GO
Fonctionnalité/Release : _______________
Date : _______________
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┌──────────────────────────────────┬────────┬────────┬───────┬───────┐
│ Critère │ Poids │ Statut │ Score │ Notes │
├──────────────────────────────────┼────────┼────────┼───────┼───────┤
│ Tous les scénarios P0 réussissent│ 30% │ GO/NOGO│ X/30 │ │
│ Tous les scénarios P1 réussissent│ 25% │ GO/NOGO│ X/25 │ │
│ Aucun bug P0 ouvert │ 20% │ GO/NOGO│ X/20 │ │
│ Aucun bug P1 ouvert (ou risque accepté)│ 10% │ GO/NOGO│ X/10 │ │
│ Test d'accessibilité (WCAG AA) │ 5% │ GO/NOGO│ X/5 │ │
│ Performance dans le budget │ 5% │ GO/NOGO│ X/5 │ │
│ Parité multiplateforme vérifiée │ 5% │ GO/NOGO│ X/5 │ │
├──────────────────────────────────┼────────┼────────┼───────┼───────┤
│ TOTAL │ 100% │ │ X/100 │ │
└──────────────────────────────────┴────────┴────────┴───────┴───────┘
Seuils de décision :
GO >= 90/100 Tous les critères P0 doivent être GO.
CONDITIONNEL 70-89/100 Livrer avec des conditions documentées et un calendrier de résolution.
NO-GO < 70/100 Ne pas publier. Corriger et re-tester.
Blocages durs (NO-GO automatique quel que soit le score) :
- Tout bug P0 ouvert
- Scénario de perte ou de corruption de données
- Vulnérabilité de sécurité (contournement d'authentification, exposition de données)
- Plantage sur un parcours utilisateur critique
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5.2 Modèle de Validation
VALIDATION DES PARTIES PRENANTES
Fonctionnalité/Release : _______________
Build/Version : _______________
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┌──────────────────┬──────────────┬──────────┬────────────┬─────────┐
│ Partie Prenante │ Rôle │ Décision │ Conditions │ Date │
├──────────────────┼──────────────┼──────────┼────────────┼─────────┤
│ [Nom] │ Product Owner│ GO/NOGO │ [si applicable] │ [date] │
│ [Nom] │ Chef Ingé. │ GO/NOGO │ [si applicable] │ [date] │
│ [Nom] │ Chef Design │ GO/NOGO │ [si applicable] │ [date] │
│ [Nom] │ Expert Métier│ GO/NOGO │ [si applicable] │ [date] │
│ [Nom] │ Resp. UAT │ GO/NOGO │ [si applicable] │ [date] │
└──────────────────┴──────────────┴──────────┴────────────┴─────────┘
Validation conditionnelle signifie : "GO, à condition que les éléments suivants soient résolus d'ici [date] :"
1. [Condition]
2. [Condition]
Si TOUTE partie prenante signe NO-GO, la release est bloquée jusqu'à ce que son problème soit résolu.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5.3 Plan de Retour Arrière
Chaque release doit avoir un plan de retour arrière documenté avant la décision go/no-go. Pas de plan de retour arrière = NO-GO automatique.
PLAN DE RETOUR ARRIÈRE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Déclencheur : [Conditions qui déclenchent le retour arrière — ex., taux de crash > 2%, bug P0 en production]
Propriétaire : [Qui initie le retour arrière]
Étapes :
1. [Désactiver le feature flag / annuler le déploiement]
2. [Vérifier que le retour arrière a réussi]
3. [Notifier les parties prenantes]
4. [Surveiller pendant 30 minutes après le retour arrière]
Données : [Une migration de données doit-elle être annulée ? Gestion de version des documents Firestore ?]
Comms : [Qui communique aux utilisateurs si nécessaire — équipe support, page de statut]
Post-mortem : [Planifier dans les 48 heures suivant le retour arrière]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5.4 Projet de Notes de Version
Générez les notes de version à partir des résultats UAT. Les testeurs UAT connaissent mieux la fonctionnalité que quiconque à ce stade.
NOTES DE VERSION (à partir des résultats UAT)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Version : _______________
Date : _______________
NOUVEAUTÉS
- [Fonctionnalité/capacité ajoutée — langage utilisateur]
AMÉLIORATIONS
- [Amélioration d'une fonctionnalité existante — ce qui est mieux pour l'utilisateur]
CORRECTIFS
- [Bug corrigé pendant l'UAT — ce qui était cassé et est maintenant résolu]
PROBLÈMES CONNUS
- [Bugs P2 livrés avec cette release — solution de contournement si disponible]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Étape 6 : Rapport UAT
Produisez le rapport UAT complet une fois toutes les sessions terminées et les validations collectées.
═══════════════════════════════════════════════════════════════
RAPPORT UAT
Fonctionnalité/Release : [NOM]
Version/Build : [VERSION]
Date : [AUJOURD'HUI]
Responsable UAT : [NOM]
═══════════════════════════════════════════════════════════════
RÉSUMÉ EXÉCUTIF
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Décision : GO / CONDITIONNEL / NO-GO
Scénarios Totaux : [N]
Réussis : [N] ([X]%)
Échoués : [N] ([X]%)
Bloqués : [N] ([X]%)
Non Exécutés : [N] ([X]%)
Blocages Ouverts : [N] P0 / [N] P1 / [N] P2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
TAUX DE RÉUSSITE PAR CATÉGORIE
┌──────────────────────┬──────────┬────────┬─────────┬────────┐
│ Catégorie │ Total │ Réussi │ Échoué │ Taux │
├──────────────────────┼──────────┼────────┼─────────┼────────┤
│ Chemin Heureux │ [N] │ [N] │ [N] │ [X]% │
│ Cas Limites │ [N] │ [N] │ [N] │ [X]% │
│ États d'Erreur │ [N] │ [N] │ [N] │ [X]% │
│ Multiplateforme │ [N] │ [N] │ [N] │ [X]% │
│ Accessibilité │ [N] │ [N] │ [N] │ [X]% │
│ Performance │ [N] │ [N] │ [N] │ [X]% │
│ Hors ligne/Connectivité │ [N] │ [N] │ [N] │ [X]% │
├──────────────────────┼──────────┼────────┼─────────┼────────┤