Recette Salesforce (UAT) : le guide pratique

Quand faire une UAT dans Salesforce

Un test d'acceptation utilisateur répond à une seule question : le métier peut-il faire son travail dans cette version de Salesforce ? Ceux qui font le travail le testent, avec leurs propres mots, avant la mise en production. Vous en avez besoin à ces moments-là.

• Une mise en production. Le premier Sales Cloud ou Service Cloud, ou une migration depuis un autre CRM.
• Un nouveau cloud ou un changement important. L'ajout de Service Cloud à côté de Sales Cloud, CPQ, une nouvelle intégration avec l'ERP ou une nouvelle façon de router les requêtes.
• Chaque release Salesforce. Salesforce publie trois releases par an : Spring, Summer et Winter. La release Winter arrive à l'automne et porte le numéro de l'année suivante. Chaque release peut changer le fonctionnement de votre org, même si vous n'avez rien modifié vous-même.
• La préversion sandbox. Les sandbox d'une instance de préversion reçoivent la nouvelle release quelques semaines avant la production. C'est votre fenêtre pour tester. Avant chaque release, Salesforce publie les instances qui font partie de la préversion et ce qu'il faut faire pour y garder une sandbox. Vérifiez-le à temps, car un refresh peut faire entrer une sandbox dans la préversion ou l'en faire sortir.

Une mise en production demande une UAT complète. Une release demande un test de régression plus court des processus les plus importants. Pour en savoir plus, voir Après la mise en production.

La sandbox

Ne testez jamais en production. Salesforce propose quatre types de sandbox. Deux d'entre eux conviennent à une UAT.

Planifier le refresh

Un refresh remplace tout le contenu de la sandbox par une nouvelle copie de la production. Chaque type de sandbox a un délai minimum entre deux refreshs, et c'est une sandbox Full qui a le plus long. Alors planifiez-le :

• Faites le refresh avant l'UAT, jamais pendant. Vérifiez quand la sandbox pourra être rafraîchie la prochaine fois.
• Déployez la release dans la sandbox après le refresh. Le travail qui n'existait que dans la sandbox est perdu.
• Faites les étapes post-refresh : pointez les intégrations et les informations d'identification nommées vers des systèmes de test, pas vers la production, et désactivez les tâches planifiées qui ne doivent pas s'exécuter.
• Vérifiez la délivrabilité des emails. Une sandbox nouvelle ou rafraîchie n'envoie que les emails système. Les réponses Web-to-Lead, les approbations et les emails des requêtes demandent davantage, mais une sandbox Full contient les vraies adresses email de vos contacts. Utilisez des adresses de test avant de l'ouvrir.

Données de test

Les testeurs perdent des heures quand les données ne sont pas prêtes. Préparez-les avant la première journée de test :

• Des comptes et des contacts pour chaque type de client que vous testez, avec le bon propriétaire, la bonne région et le bon type d'enregistrement.
• Des produits et des catalogues de prix. Un produit doit avoir un prix dans le catalogue de prix standard avant de pouvoir figurer dans un autre catalogue de prix. Vérifiez que les catalogues de prix de chaque équipe commerciale sont actifs.
• Des enregistrements ouverts sur lesquels travailler : des opportunités à différentes étapes, des requêtes ouvertes, et des requêtes proches d'une étape importante si vous testez les droits.
• Pas de vraies données personnelles quand vous pouvez l'éviter. Une sandbox Full copie tout : masquez ou anonymisez ce que les testeurs n'ont pas besoin de voir.

Des utilisateurs par profil et ensemble d'autorisations

Une UAT prouve que chaque rôle peut faire son travail, et uniquement son travail. Créez un utilisateur de test pour chaque combinaison de profil, de rôle et d'ensembles d'autorisations que vous testez, par exemple un commercial, un responsable commercial et un agent du service client. Chaque testeur a son propre utilisateur, pour que deux personnes ne travaillent jamais en même temps avec le même utilisateur.

Après un refresh, Salesforce ajoute le nom de la sandbox à chaque nom d'utilisateur et .invalid à l'adresse email de chaque utilisateur. Mettez comme email de chaque utilisateur de test une adresse que le testeur lit, sinon les réinitialisations de mot de passe et les emails d'approbation n'arrivent nulle part.

Se connecter en tant que (Log in as) permet à un administrateur de voir Salesforce avec les yeux d'un autre utilisateur. C'est un bon moyen d'examiner un problème signalé par un testeur. Pour le test lui-même, les testeurs utilisent leur propre utilisateur de test : c'est ainsi que vous savez que le profil et les ensembles d'autorisations sont corrects.

Ce qu'il faut dire aux testeurs sur la sandbox

• L'adresse de la sandbox. Elle contient le nom de la sandbox, ou ils se connectent via test.salesforce.com. La page de connexion normale de Salesforce ouvre la production.
• Leur nom d'utilisateur, qui se termine par le nom de la sandbox, et comment ils obtiennent leur mot de passe.
• Que les données sont des données de test : rien de ce qu'ils font n'atteint un vrai client, et rien de ce qu'ils voient n'est à jour.
• Qui appeler quand ils ne parviennent pas à se connecter, avant de perdre une matinée.

Dans UAT StudioChaque testeur reçoit un Test role et un Test account, affichés en haut de ses tests sous la forme Log in as …. Les Notes for testers contiennent l'adresse de la sandbox, les boîtes mail de test et qui appeler.

Des cas de test à partir des user stories et des processus

Partez des processus du métier, pas des objets de Salesforce. Deux processus couvrent l'essentiel d'une UAT Salesforce :

• Lead-to-cash. Une piste arrive via Web-to-Lead, est attribuée et convertie. L'opportunité reçoit des produits du catalogue de prix, un devis est créé et approuvé, l'affaire est gagnée, et la commande ou le contrat passe à l'équipe ou au système suivant.
• Gestion des requêtes. Une requête arrive via Email-to-Case ou le portail, est routée vers la bonne file d'attente ou le bon agent, suit son droit et ses étapes importantes, est résolue avec un article Knowledge, escaladée si nécessaire, puis clôturée.

Découpez chaque processus en cas de test portant chacun sur un seul scénario métier, par exemple Convertir une piste avec un compte existant. Vérifiez ensuite que chaque user story du périmètre a au moins un cas de test.

Des étapes que les testeurs métier comprennent

Rédigez chaque étape comme une action et un résultat attendu, avec les mots du testeur. Ajoutez des données de test là où c'est utile. Un testeur ne doit jamais avoir à deviner si une étape a réussi.

Priorité et risque

Tous les cas de test n'ont pas la même importance. Marquez chacun Must, Should ou Could : Must, c'est ce qui doit fonctionner dès le premier jour, comme créer un devis ou router une requête. Ajoutez le risque : ce que cela coûte si cela tourne mal après la mise en production. Les testeurs commencent par Must et risque élevé, pour que les tests importants soient faits même quand le temps manque.

Ajoutez aussi les cas d'échec : un champ obligatoire laissé vide, une remise au-dessus de la limite, un utilisateur qui ne devrait pas voir un enregistrement.

Dans UAT StudioImportez vos cas de test depuis Excel avec les colonnes Priority et Risk, ou partez des scripts Salesforce de la bibliothèque de modèles, une option de chaque formule payante. Les testeurs voient d'abord leurs cas de test Must.

Testeurs

Choisissez des personnes qui font le travail au quotidien : des commerciaux, des agents du service client, et leurs managers pour les approbations, les prévisions et les rapports. Prenez des testeurs dans chaque équipe et chaque pays qui utilise Salesforce, car leurs processus et leurs catalogues de prix diffèrent.

Combien de temps

Demandez le temps par testeur, pas par équipe, et faites-le valider par leur manager. Planifiez les scripts pour que chaque testeur sache combien il a à faire. Gardez du temps pour les nouveaux tests après les correctifs. Des testeurs qui continuent à prendre des appels ou à visiter des clients ne finiront pas.

Une réunion de lancement

Commencez par une courte réunion de lancement : pourquoi leur test compte, comment se connecter à la sandbox, comment enregistrer un résultat et comment signaler une anomalie. Faites se connecter chaque testeur une fois pendant le lancement. La plupart des problèmes d'utilisateurs et de mots de passe apparaissent là, pas le jour du test.

Une journée de test ou une semaine

• Une journée de test, dans une seule salle ou un seul appel, apporte de la concentration et des réponses rapides. Elle convient à un petit périmètre et à des testeurs difficiles à libérer plus longtemps.
• Sur une semaine, par blocs de quelques heures, laisse de la place pour les correctifs et les nouveaux tests entre les blocs. Cela convient à une mise en production avec de nombreux processus.

Dans les deux cas, fixez un créneau pour le triage chaque jour.

Pendant l'UAT

Signaler les anomalies

Une bonne anomalie peut être corrigée sans réunion. Demandez aux testeurs :

• L'étape, ce qu'ils attendaient et ce qui s'est passé à la place.
• Une capture d'écran de la page.
• Le lien vers l'enregistrement. Il se trouve dans la barre d'adresse du navigateur et mène le développeur directement à l'opportunité ou à la requête où le problème est survenu.
• L'utilisateur avec lequel ils ont testé, pour que l'équipe sache quel profil et quels ensembles d'autorisations ont été utilisés.

Dans UAT StudioL'extension de navigateur pour Chrome et Edge affiche les tests dans un panneau latéral à côté de Salesforce. Une étape en échec emporte la capture d'écran, le lien vers l'enregistrement et les messages d'erreur de la page. Une anomalie affiche l'enregistrement sous forme de lien, sandbox comprise.

Triage

Passez en revue les nouvelles anomalies chaque jour, avec le métier et l'équipe Salesforce ensemble. Donnez à chacune une gravité et une personne qui la corrige, et décidez :

• Corriger : un vrai problème, corrigé dans cette release.
• Rejeter : Salesforce fonctionne comme prévu, ou le test était erroné.
• Demande d'évolution : un souhait, pas un défaut. Elle va dans le backlog, pas dans cette release.

Nouveau test

Quand un correctif est déployé dans la sandbox, le testeur qui a trouvé l'anomalie teste à nouveau l'étape. Notez sur quel build chaque nouveau test a été fait. Après un correctif important, testez aussi à nouveau les processus autour.

Statut quotidien

Envoyez chaque jour au comité de pilotage un court statut : l'avancement par rapport au plan, les anomalies ouvertes par gravité et ce qui bloque. Tenez-vous-en aux faits. Pas de surprises à la réunion go/no-go.

Dans UAT StudioLe triage se fait sur un écran partagé avec Fix, Reject et Change request. Ready for retest envoie un email à la personne qui refait le test. Un récapitulatif quotidien par email, ou dans Microsoft Teams, montre les résultats et les anomalies de la veille.

Validation et go/no-go

L'UAT se termine par une décision du métier. Convenez des critères de sortie avant la première journée de test, pour que personne n'en discute à la fin :

• Aucune anomalie Critical n'est ouverte.
• Chaque cas de test Must est réussi.
• 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.

Qui valide

Le responsable de chaque processus valide, par exemple le directeur commercial pour le lead-to-cash et le responsable du service client pour la gestion des requêtes. Il choisit : accepté, accepté sous conditions ou rejeté. Notez chaque condition, avec qui s'en charge et pour quand. Le comité de pilotage décide ensuite de la mise en production.

Ce que contient le rapport

• Ce qui faisait partie du périmètre, et ce qui n'a pas été testé.
• Les résultats par processus ou par équipe, et par priorité.
• La sandbox, la release et le build testés.
• Les anomalies ouvertes par gravité, avec la décision pour chacune.
• Les validations, avec leurs conditions, et les risques connus pour les premières semaines.

Dans UAT StudioValidation par groupe : Accepted, Accepted with conditions ou Rejected. Par défaut, personne ne peut accepter tant qu'une anomalie Critical est ouverte. Le rapport go/no-go est prêt en PDF ou en diapositives dès que le dernier résultat est saisi.

Un cycle de régression à chaque release Salesforce

Après la mise en production, les releases continuent d'arriver : trois par an. Chacune peut changer une page, un flow ou une autorisation. Vos cas de test d'UAT sont le meilleur test de régression dont vous disposez, car ils décrivent exactement ce que le métier a accepté.

• Conservez les cas de test après la mise en production, avec leurs étapes, leurs données de test et leurs résultats attendus.
• Lisez les notes de version de la prochaine release, et vérifiez quelles fonctionnalités sont activées automatiquement pour vous.
• Vérifiez que votre sandbox d'UAT fait partie de la préversion sandbox, et planifiez le cycle dans la fenêtre de préversion.
• Testez à nouveau les cas de test Must, et Should s'il reste du temps, avec quelques testeurs du métier.
• Enregistrez les anomalies comme pendant l'UAT, et corrigez-les avant que la release n'atteigne la production.

Dans UAT StudioChoisissez Salesforce comme CRM du projet. La page des projets affiche alors les prochaines releases Salesforce, avec la date de la préversion sandbox, la date de la production et les notes de version. Start a regression round copie les cas de test choisis : Must and Should, Only Must ou All test cases in scope.

Libre d'utilisation

Pour tout ce qu'il faut organiser avant, pendant et après l'UAT, voir la checklist UAT pour une mise en production CRM, également en fichier Excel gratuit. Pour ce que UAT Studio apporte à une UAT Salesforce, voir UAT Salesforce.

Salesforce, Sales Cloud et Service Cloud sont des marques de Salesforce, Inc. UAT Studio n'est ni affilié à Salesforce ni approuvé par Salesforce.