La complexité de mise en place des TNR sur SalesForce.

On ne présente plus SalesForce, le logiciel CRM par excellence le plus utilisé au monde. Les entreprises s’y appuient pour développer leurs ventes, piloter les actions marketing ou encore l’utilisent comme plateforme collaborative. Et, comme si les fonctionnalités natives ne suffisaient pas, Salesforce met à disposition via sa plate forme AppExchange des applications et des composants professionnels. Les possibilités sont infinies. Mais, le revers de la médaille, c’est qu’il vous faudra une vigilance extrême pour vous assurer du bon fonctionnement de l’ensemble des applications car, à vos dépens, vous venez de multiplier les sources de régression par 3.

Le composant que vous avez ajouté via AppExchange.

Comme pour tout développement, avant mise en production vous effectuez des tests de non régression, du moins on l’espère. Lors de sa première version vous avez validé l’ensemble des fonctionnalités selon différents scénarios et sur les environnements les plus utilisés. Et il en ira de même pour chaque mise à jour ou correction évolutive. Nous sommes dans un schéma relativement classique. A chaque nouvelle version de ce composant vous devrez en vérifier le bon fonctionnement dans le contexte de « votre » SalesForce.

Salesforce en personne.

On ne va pas remettre en cause les équipes de Salesforce et partons du postulat que toutes les nouvelles versions passées en production ne présentent aucune régression. Cela pourrait éviter un point de vigilance sauf si, Salesforce décide de mettre à jour ou de migrer, fusionner voir supprimer une fonctionnalité exploitée par une de vos extensions.

Ce n’est pas pour rien que Salesforce recommande de tester chaque mise à jour en l’activant pendant les heures creuses dans votre environnement Developer Sandbox ou de production.

Pour assurer une transition sans heurt, chaque mise à jour comporte une période d’adoption durant laquelle vous pouvez activer et désactiver manuellement et à volonté la mise à jour afin d’évaluer son impact sur votre organisation et de modifier les personnalisations affectées si nécessaire. Et pour évaluer ce fameux impact, il vous faudra mettre en place des tests de non régression contre la montre.

Là aussi, testez différents scénarios, différents jeux de données et sur plusieurs environnements.

Les travaux de votre intégrateur.

La mise en œuvre, l’implémentation, la customisation des flux, des profils, .. tout cela évolue et doit être maintenu. De fait au fil des diverses adaptations de « Votre » SalesForce il va être nécessaire de tester si cela est conforme aux nouveaux besoins, mais aussi s’il n’y a pas de régression !

Vous avez également  fait développé par votre intégrateur (ou un partenaire expert de Salesforce) des spécificités pour « votre »  Salesforce, mais ne communiquent-elles pas entre elles aussi ? Et c’est là qu’est le point de vigilance le plus critique. Il faudra s’assurer que toutes les évolutions d’une extension ne génèrent pas de régressions par effet de bord sur les autres utilitaires, sans parler de la fonction spécifique elle-même.

Au final vous pouvez vite vous retrouver à devoir réaliser des tests de non régression en continu pour être sûr de la fiabilité de votre applicatif. Et, comme à chaque fois, avec plusieurs jeux de données, sur différents environnements et terminaux.

Pour conclure.

Dans l’article présenté on vous a épargné l’utilisation de Salesforce dans un contexte international, avec différentes langues, habilitations fonctions des pays, … La conduite manuelle de tests de non régression devient alors impossible manuellement si l’on ne veut pas déroger sur la qualité. Une alternative est d’ignorer des environnements d’utilisation, des scénarios, voire faire l’impasse sur des release de SalesForce, de votre intégrateur, avec bien sur tous les risques que cela implique pour le business de votre entreprise, sans parler de l’image de votre équipe aux yeux de vos collègues qui utilisent Salesforce !!