Pourquoi les tests de régression CCM devraient être automatisés

Toutes les plateformes de gestion de contenu client (CCM) — qu'il s'agisse OpenText , de Quadient Inspire ou de SMART Communications — comportent le même risque latent : une simple modification d'un modèle, d'un mappage de données ou d'un paramètre de configuration peut, sans qu'on s'en aperçoive, corrompre des dizaines de documents en aval. La modification est mise en production. Personne ne s'en rend compte jusqu'à ce qu'un client appelle ou qu'un auditeur demande pourquoi son relevé semble différent ce trimestre.

Ce n'est pas une hypothèse. C'est l'un des problèmes les plus courants — et les plus faciles à éviter — dans les environnements de production de contenu multimédia (CCM). Et la solution ne réside pas dans davantage de vérifications manuelles. La solution réside dans les tests de régression automatisés pour le contenu multimédia (CCM).

Le piège des tests manuels

La plupart des équipes de gestion de contenu (CCM) ont mis en place un processus de vérification. Elles examinent des échantillons de sortie avant la publication, comparent les fichiers PDF côte à côte et passent en revue une liste de contrôle. Cela fonctionne… jusqu’à ce que ça ne fonctionne plus.

Les tests manuels posent trois problèmes fondamentaux dans le contexte du CCM :

• Ce n'est pas évolutif.Un environnement CCM peut générer des milliers de variantes de documents selon les segments, les langues, les canaux et les règles métier. Aucune liste de contrôle ne permet de toutes les couvrir.
• Ce n'est pas fiable.Sous la pression du temps, on peut passer à côté de certaines choses. Un même test réalisé par deux personnes différentes donne des résultats différents.
• Cela ne génère aucune trace d'audit.En cas de problème, il est difficile de prouver ce qui a été testé, à quel moment et par qui — ce qui revêt une importance capitale dans les secteurs réglementés tels que les services financiers, l'assurance ou les services publics.

La question n'est pas de savoir si votre système CCM finira par tomber en panne. La question est de savoir si vous vous en rendrez compte avant ou après vos clients.

Ce que les tests de régression permettent réellement de protéger

Les tests de régression dans un environnement CCM ne visent pas à détecter les bogues évidents. Il s'agit plutôt de repérer les légères anomalies qui s'accumulent au fil du temps : un champ qui s'affichait correctement auparavant et qui est désormais tronqué, un bloc conditionnel qui se déclenche alors qu'il ne le devrait pas, un PDF qui s'affiche correctement à l'écran mais qui ne respecte pas les spécifications d'impression.

Intégrité des modèles et des résultats

Chaque fois qu'un modèle est modifié — même s'il s'agit d'une simple modification rédactionnelle —, l'ensemble de la famille de documents à laquelle il appartient doit être validé. Des tests automatisés comparent les nouveaux résultats aux versions de référence approuvées et signalent tout écart, notamment les modifications de mise en page, le contenu manquant et les changements de formatage.

Fiabilité des API et des intégrations

Les plateformes CCM ne fonctionnent pas en vase clos. Elles reçoivent des données provenant de systèmes ERP, de plateformes CRM et de couches d'intégration. Des tests API automatisés vérifient que les connexions dont dépendent vos documents renvoient les bonnes données, au bon format et avec la bonne authentification, avant chaque déploiement.

Validation spécifique au canal

Un document destiné à l'impression n'a pas les mêmes exigences qu'un document transmis par e-mail, via un portail ou via Kivra. Les tests de régression peuvent être adaptés à chaque canal, ce qui permet de détecter les problèmes qui n'apparaissent que dans certains chemins de sortie spécifiques.

L'automatisation bouleverse les règles du jeu en matière de mise en production

L'une des principales raisons pour lesquelles les équipes CCM hésitent à adopter l'automatisation réside dans les coûts de mise en place. « Nous passerions plus de temps à créer les tests qu'à les exécuter manuellement. » Ce calcul change rapidement dès lors que l'on prend en compte le coût réel de l'alternative : une mise à jour qui provoque une panne en production, un week-end consacré au diagnostic et à la restauration, ainsi que le coût en termes de réputation lié à l'envoi massif de communications erronées aux clients.

Une fois mis en place, les tests de régression automatisés s'exécutent en quelques minutes. Ils fonctionnent de manière constante à chaque fois. Et ils apportent aux responsables de processus et aux chefs de produit quelque chose de véritablement utile : un statut clair (« réussi » ou « échoué ») avant que la décision de mise en production ne soit prise. Pas une simple liste d'éléments vérifiés, mais un résultat vérifiable.

Pour les organisations qui procèdent à des mises à jour régulières de leur plateforme de gestion de la relation client (CCM) — que ce soit tous les mois, toutes les deux semaines ou plus fréquemment —, c'est ce qui fait la différence entre un processus de mise à jour qui donne le sentiment d'être maîtrisé et un processus qui ressemble à un pari.

À quoi ressemble une pratique de test CCM bien rodée

Les organisations qui ont investi dans les tests de régression automatisés pour la gestion du cycle de vie des contenus (CCM) présentent généralement certaines caractéristiques communes :

• Les cas de test sont gérés sous contrôle de version au même titre que les modèles et les configurations : toute modification apportée à l'un d'entre eux entraîne la réexécution des autres.
• L'exécution des tests fait partie intégrante du pipeline de déploiement ; il ne s'agit pas d'une étape distincte que l'on peut ignorer en cas de pression.
• Les résultats sont enregistrés avec suffisamment de détails pour permettre les audits et les contrôles de conformité : il ne s'agit pas seulement d'une simple indication « réussi/échoué », mais aussi de savoir ce qui a été testé, quel était le résultat attendu et quel a été le résultat réel.
• Les parties prenantes non techniques — responsables de processus, responsables de la conformité, interlocuteurs chargés de la validation métier — peuvent lire et interpréter les résultats des tests sans avoir besoin qu'un développeur les leur explique.

Voici le tableau de bord du cadre de test ENIT présentant les résultats des tests automatisés du CCM.

Par où commencer

Il n'est pas nécessaire de tout automatiser d'un seul coup. Un bon point de départ :

• Identifiez la catégorie de documents la plus à risque, c'est-à-dire celle où une erreur aurait les conséquences les plus graves.
• Définissez à quoi ressemble un résultat « correct » pour un ensemble représentatif de cas de test.
• Créez une petite suite de tests automatisés autour de cette famille et exécutez-la sur votre prochaine version prévue.
• Élargir progressivement la couverture, en accordant la priorité au volume et à la sensibilité réglementaire.

L'objectif de la première phase n'est pas d'atteindre une couverture totale. Il s'agit plutôt de mettre en place les habitudes et les outils nécessaires, et de montrer à l'entreprise que la confiance dans les livraisons ne repose pas nécessairement sur l'espoir.