Tests de non-régression après une release CRM

Pourquoi un CRM a besoin de tests de non-régression

Après la mise en production, votre CRM continue de changer, même quand votre propre équipe ne change rien. Salesforce et Microsoft mettent à jour la plateforme pour tous leurs clients. La plupart des changements sont des améliorations. Certains modifient une page, un paramètre par défaut ou le fonctionnement d'une fonctionnalité, et de temps en temps, l'un d'eux casse quelque chose dont votre métier dépend.

Un test de non-régression répond à une seule question : ce que le métier a accepté à la mise en production fonctionne-t-il toujours ? Ce n'est pas une nouvelle UAT. C'est une vérification courte et ciblée des processus qui comptent le plus, faite avant que le changement n'atteigne vos utilisateurs, par des personnes qui connaissent le travail.

Vos propres releases demandent la même vérification. Une nouvelle intégration, un nouveau champ sur le devis, une modification du routage des requêtes : chacune peut toucher quelque chose qui fonctionnait auparavant.

Salesforce : trois releases par an

Salesforce a trois releases majeures par an : Spring, Summer et Winter. La release Winter arrive à l'automne et porte le numéro de l'année suivante. Chaque org est mise à niveau, à des dates que Salesforce publie à l'avance.

• La preview sandbox. Les sandbox sur une instance de preview reçoivent la nouvelle release quelques semaines avant la production. C'est votre fenêtre pour tester. Avant chaque release, Salesforce indique quelles instances sont en preview et ce qu'il faut faire pour y garder une sandbox. Un refresh peut faire entrer une sandbox dans la preview ou l'en faire sortir : vérifiez-le à temps.
• Les notes de version. Lisez-les pour les clouds et les fonctionnalités que vous utilisez. Repérez ce qui est activé automatiquement pour vous, et ce qui change l'aspect des pages où travaillent vos utilisateurs.
• Les release updates. Certains changements sont annoncés dans Setup avec une date à laquelle ils sont imposés. Testez-les dans la sandbox avant cette date, pour qu'ils ne vous surprennent pas en production.

Pour Salesforce, le rythme est donc donné : un cycle de non-régression dans la fenêtre de preview de chaque release, trois fois par an.

Dans UAT StudioChoisissez Salesforce comme CRM du projet. Environ deux mois avant une release, la page des projets affiche Coming CRM releases, avec la date de la preview sandbox, la date de mise en production et un lien vers les notes de version. Salesforce peut encore déplacer ces dates : vérifiez les notes de version.

Dynamics 365 : des mises à jour toute l'année

Microsoft ne regroupe plus les changements de Dynamics 365 en deux vagues de release par an. Les nouvelles fonctionnalités et les changements arrivent toute l'année. Les plans de release ont été archivés en octobre 2026 ; ce qui arrive figure désormais dans la feuille de route Microsoft à l'adresse aka.ms/AIatWorkRoadmap.

Il n'y a donc plus un grand moment dans l'année autour duquel planifier vos tests. Les changements arrivent par petites étapes, plus souvent. Attendre une grosse release ne fonctionne plus, et tester après chaque changement serait trop.

Choisissez un rythme fixe

La réponse est un cycle de non-régression à rythme fixe, quoi que Microsoft publie entre-temps :

• Chaque mois quand le CRM est au cœur du métier, que vous utilisez de nombreuses applications et fonctionnalités, ou que vous activez souvent de nouvelles fonctionnalités.
• Chaque trimestre pour une configuration stable avec peu de changements de votre côté.
• Un cycle supplémentaire avant la mise en production d'un changement de votre côté, ou quand un changement de Microsoft touche clairement l'un de vos processus clés.

Inscrivez les dates dans l'agenda des testeurs pour toute l'année. Un rythme fixe est plus facile à tenir qu'un cycle planifié chaque fois que quelque chose se présente.

Avant chaque cycle

• Lisez la feuille de route Microsoft et les messages destinés à vos administrateurs dans le Centre d'administration Microsoft 365, et notez les changements qui touchent vos processus.
• Essayez d'abord les fonctionnalités en préversion dans un environnement sandbox, avant qu'elles n'atteignent vos utilisateurs.
• Assurez-vous que la sandbox dans laquelle vous testez a la même version et les mêmes solutions que la production.

Dans UAT StudioChoisissez Dynamics 365 comme CRM du projet, et lancez chaque cycle avec Start a regression round, depuis le projet de votre mise en production ou de votre dernier cycle.

Dans UAT StudioDans Setup, choisissez Check the Dynamics 365 updates : Every quarter ou Every month. La page des projets affiche alors la période en cours avec un lien vers la feuille de route, et les administrateurs reçoivent un email par période, deux semaines avant son début.

Choisir quoi retester

Un cycle de non-régression n'est pas l'endroit pour tout retester. Choisissez, dans cet ordre :

1. Les cas de test Must. Ce qui doit fonctionner tous les jours : créer un devis, convertir un lead, router une requête, les approbations. Testez-les à chaque cycle.
2. Ce que touche le changement. Lisez les notes de version ou la feuille de route avec la liste de vos processus à côté. Un changement sur les devis implique les cas de test des devis, y compris les Should et les Could.
3. Les intégrations et l'automatisation. Les liaisons avec l'ERP, le site web ou l'email, et les flux qui tournent en arrière-plan. Ils cassent sans bruit : testez-les délibérément.
4. Les cas de test Should, quand il reste du temps.

Regardez ensuite ce que votre propre équipe a changé depuis le dernier cycle. Tout ce que vous avez construit vous-même et que personne n'a testé avec le changement de plateforme a aussi sa place dans le cycle.

Tenez une courte liste de ce qui est critique

Écrivez, une fois pour toutes, les dix à vingt processus dont le métier ne peut pas se passer une seule journée. Ils forment le cœur de chaque cycle de non-régression. Revoyez la liste tous les six mois avec les responsables des processus, et après chaque changement important de votre côté.

Dans UAT StudioAvec le module Release readiness, Review the release montre quels cas de test une release Salesforce ou une mise à jour Dynamics 365 touche, avec la raison, propose des cas de test pour ce qui n'est pas encore couvert et liste les mises à jour obligatoires avec leurs dates. Le cycle de non-régression reçoit alors exactement les cas de test Must, les cas touchés que vous gardez et les nouveaux que vous approuvez. Un échec dans le cycle indique avec quel changement il est arrivé. €99 par mois : ajoutez-le dans Plan & billing.

Réutiliser vos cas de test

Le meilleur test de non-régression dont vous disposez, c'est l'ensemble des cas de test de l'UAT de votre mise en production. Ils décrivent exactement ce que le métier a accepté, avec les étapes, les données de test et les résultats attendus. N'en écrivez pas de nouveaux à chaque cycle.

• Conservez les cas de test après la mise en production, à un seul endroit, avec leur priorité.
• Mettez-les à jour quand votre propre processus change, pour que le cycle suivant teste le CRM tel qu'il est aujourd'hui, et non tel qu'il était à la mise en production.
• Vérifiez les données de test avant chaque cycle. Un refresh de sandbox ou une copie de la production peut supprimer ou modifier les enregistrements utilisés par les cas de test.
• Ajoutez un cas de test pour chaque anomalie sérieuse trouvée en production, pour qu'elle soit détectée la prochaine fois.

Des cas de test que les testeurs métier peuvent suivre valent l'effort ici : ils sont réutilisés encore et encore. Voir Rédiger des cas de test que les testeurs métier comprennent.

Dans UAT StudioStart a regression round copie les cas de test du projet de départ, avec leurs étapes, données de test et résultats attendus. Choisissez ceux qui suivent : Must and Should, Only Must ou All test cases in scope ; un cas de test sans priorité compte comme Should. Le nouveau projet reprend les groupes et les paramètres, et vous invitez les testeurs sous Setup. Rien n'est inventé ni modifié.

Qui teste, et combien de temps

Qui

Un cycle de non-régression demande moins de monde qu'une UAT, mais les testeurs doivent quand même venir du métier. Demandez un ou deux utilisateurs clés par processus : des personnes qui font le travail tous les jours et voient tout de suite quand quelque chose cloche. L'admin CRM prépare le cycle et teste ce qui tourne en arrière-plan, mais ne devrait pas être le seul testeur.

Faites tester les mêmes personnes cycle après cycle. Elles gagnent en rapidité, et remarquent de petits changements qu'un nouveau testeur manquerait.

Durée

• Préparation : un jour ou deux pour lire les changements, choisir les cas de test et vérifier les données de test.
• Tests : quelques heures par testeur, réparties sur un ou deux jours pour un cycle mensuel, jusqu'à une semaine pour une release Salesforce avec de nombreux changements.
• Corrections et nouveaux tests : gardez quelques jours avant que le changement n'arrive en production, pour les anomalies que vous trouvez.

Pour Salesforce, tout cela doit tenir dans la fenêtre de preview. Commencez tôt dans la fenêtre, pas la dernière semaine.

Enregistrer ce que vous trouvez

Enregistrez les anomalies comme pendant l'UAT : l'étape, ce que vous attendiez, ce qui s'est passé à la place, une capture d'écran et le lien vers l'enregistrement. Triez-les chaque jour avec l'équipe CRM. Pour une anomalie causée par la plateforme, regardez d'abord dans les notes de version ou la feuille de route : il s'agit souvent d'un changement connu, avec un paramètre à ajuster.

Dans UAT StudioChaque cycle conserve sa release, son build et son environnement, pour que le rapport go/no-go dise ce qui a été testé. Après les corrections, Start round 2 sur le tableau de bord avec Failed and blocked only reteste uniquement ce qui a échoué ; les résultats du cycle précédent sont conservés.

Validation avant la production

Un cycle de non-régression se termine comme une UAT, par une décision, en plus court. Convenez des critères de sortie une fois, et utilisez-les à chaque cycle :

• Chaque cas de test Must est réussi.
• Aucune anomalie Critical n'est ouverte.
• Chaque anomalie High ouverte a un contournement que le métier accepte, ou une correction avant que le changement n'arrive en production.

Le responsable de chaque processus valide sa partie : accepté, accepté sous conditions ou rejeté. Pour une release Salesforce, vous ne pouvez pas arrêter la mise à niveau : un rejet signifie donc une correction ou un contournement avant la date de production, et un message aux utilisateurs. Pour un changement de votre côté, un rejet signifie qu'il attend.

Conservez le résultat de chaque cycle. Au bout d'un an, vous avez une trace claire de ce qui a été testé après chaque changement, et de qui l'a accepté. Pour préparer la décision, voir La décision go/no-go.

Dans UAT StudioUn cycle de non-régression est un projet à part entière, avec la release comme Release, pour que son rapport go/no-go dise de quelle release CRM il s'agit. Les responsables des processus valident par groupe, et la validation appartient à ce cycle.

Libre d'utilisation

La checklist UAT pour une mise en production CRM fonctionne aussi pour un cycle de non-régression, en fichier Excel gratuit. Pour chaque plateforme, voir UAT Salesforce et UAT Dynamics 365.

Salesforce est une marque de Salesforce, Inc. Microsoft et Dynamics 365 sont des marques du groupe Microsoft. UAT Studio n'est ni affilié à Salesforce ou à Microsoft, ni approuvé par eux.