Avant l'UAT
La plupart des UAT qui échouent échouent ici : un périmètre flou, des scripts que personne n'a vérifiés, des testeurs sans compte qui fonctionne.
Périmètre
- Convenez des processus et des user stories inclus dans l'UAT, et notez ce qui ne l'est pas.
- Désignez un responsable métier pour chaque processus : la personne qui valide.
- Convenez de ce que signifient Critical, High, Medium et Low avant d'enregistrer la première anomalie.
Cas de test
- Rédigez un cas de test par scénario métier, avec les mots des personnes qui le testent.
- Donnez à chaque étape une action et un résultat attendu, et des données de test quand c'est utile.
- Marquez chaque cas de test Must, Should ou Could, pour que les plus importants soient testés en premier.
- Ajoutez les cas d'erreur : une valeur erronée, un champ manquant, un utilisateur sans le bon rôle.
- Vérifiez que chaque user story du périmètre a au moins un cas de test.
- Faites relire les scripts par un utilisateur clé du métier avant les journées de test.
Testeurs
- Choisissez des testeurs qui font ce travail au quotidien, dans chaque équipe qui utilise le système.
- Attribuez à chaque testeur un groupe et ses propres scripts.
- Bloquez les journées de test dans leurs agendas et libérez-les de leur travail quotidien.
- Briefez-les en une demi-heure : comment enregistrer un résultat et comment signaler une anomalie.
Environnement et données de test
- Préparez un environnement de test proche de la production : configuration, intégrations et données.
- Créez un compte de test pour chaque rôle, et vérifiez que chacun peut se connecter.
- Chargez les données de test : clients, produits, listes de prix et enregistrements en cours.
- Utilisez des données de test plutôt que des données clients partout où c'est possible.
- Convenez du moment où les correctifs sont déployés dans l'environnement de test pendant les journées de test.
Planning
- Planifiez les journées de test par blocs, avec un créneau fixe pour le triage chaque jour.
- Réservez du temps pour un cycle de nouveau test après les correctifs.
- Fixez la date de la réunion go/no-go, et invitez dès maintenant le comité de pilotage.
- Vérifiez le calendrier des releases de Salesforce ou de Dynamics 365 : une release de la plateforme au milieu de votre UAT change ce que vous testez.
Critères d'entrée
- Le test système est terminé, et aucun défaut Critical qui en est issu n'est encore ouvert.
- L'environnement de test, les comptes de test et les données de test sont prêts.
- Le métier a relu les cas de test.
- Chaque testeur a été invité et s'est connecté au moins une fois.
Pendant l'UAT
Gardez des journées courtes et l'information en un seul endroit, pour que les problèmes soient trouvés, tranchés et corrigés le jour même.
Point quotidien
- Commencez chaque journée par quinze minutes : ce qui a été testé, ce qui bloque, ce qui est prévu aujourd'hui.
- Comparez l'avancement par groupe avec le planning, et déplacez les testeurs là où on a besoin d'eux.
Signaler les anomalies
- Signalez une anomalie par problème, avec l'étape, ce que vous attendiez et ce qui s'est passé à la place.
- Ajoutez une capture d'écran et le lien vers l'enregistrement.
- Cherchez d'abord une anomalie existante, pour que le même problème ne soit pas signalé deux fois.
- Veillez à ce que chaque étape en échec ait une anomalie, ou une raison de ne pas en avoir.
Triage
- Tenez le triage chaque jour, avec le métier et l'équipe de développement ensemble.
- Donnez à chaque nouvelle anomalie une gravité, une priorité et une personne chargée de la corriger.
- Décidez pour chacune : la corriger, la rejeter ou la transformer en demande d'évolution.
- Placez les demandes d'évolution dans le backlog, pas dans cette version.
Nouveaux tests
- Faites retester l'anomalie par le testeur qui l'a trouvée, une fois le correctif déployé.
- Notez sur quelle version et quel build chaque nouveau test a été fait.
- Lancez un nouveau cycle après un correctif important, et testez à nouveau les processus autour du correctif.
Clôturer l'UAT
L'UAT se termine par une décision. Prenez-la sur la base de faits, et notez qui a décidé quoi.
Critères de sortie
- Chaque cas de test Must est réussi.
- Aucune anomalie Critical n'est ouverte.
- Chaque anomalie High ouverte a un contournement ou une date de correction que le métier accepte.
- Chaque cas de test du périmètre a un résultat.
Validation
- Demandez au responsable de chaque processus de valider : accepté, accepté sous conditions ou rejeté.
- Notez chaque condition, avec qui s'en charge et pour quand.
Go/no-go
- Tenez la réunion go/no-go avec les chiffres à l'écran, pas de mémoire.
- Consignez la décision, les conditions et qui l'a prise.
Le rapport
- Indiquez ce qui était dans le périmètre, et ce qui n'a pas été testé.
- Présentez les résultats par groupe et par priorité, ainsi que la version et le build testés.
- Listez les anomalies ouvertes par gravité, avec la décision prise pour chacune.
- Ajoutez les validations, avec leurs conditions.
- Nommez les risques connus et les contournements pour les premières semaines après la mise en production.
Après la mise en production
- Conservez les cas de test : ils constituent le test de régression de la prochaine version du CRM.
- Notez ce qu'il faut faire autrement lors de la prochaine UAT, tant que c'est encore frais.
La même checklist, sans le tableur
UAT Studio prend en charge l'essentiel de cette liste pour vous. Le contrôle de préparation montre ce qui manque avant la journée de test, les testeurs se connectent avec un code et ne voient que leurs propres scripts, une étape en échec devient une anomalie avec capture d'écran, le triage se fait sur un écran partagé, et le rapport go/no-go est prêt dès que le dernier résultat est saisi. Essayez-le sur votre propre projet avec un pilote gratuit de 14 jours.
Vous testez une release Salesforce ou Dynamics 365 ? Consultez UAT Salesforce et UAT Dynamics 365.
