Move2cloud : Tests de non-régression ? Arrêtez de perdre du temps !

De plus en plus d’entreprises migrent vers le cloud pour bénéficier de ses avantages. Elasticité, scalabilité, performances, coût à l’usage… La Data est alors extraite des bases de données On Premise et envoyée vers le nouveau socle technique (Snowflake, GCP, Azure, AWS…). Dans cet article, nous verrons comment accélérer vos tests de non-régression, étape primordiale de votre migration…

Différents outils permettent d’effectuer ces transferts, mais qui dit déplacement dit nécessité de s’assurer que les données soient bien conformes à l’arrivée ! Cette étape de comparaison s’appelle les tests de non-régression (TNR) et représente une étape obligatoire avant de rendre l’accès aux utilisateurs. L’objectif est d’assurer la qualité des données en validant de manière exhaustive l’ensemble du patrimoine, sans avoir à embarquer les utilisateurs métiers dans la conception de scénarios de tests.

Ce n’est malheureusement pas magique, et en fonction du patrimoine existant, cela représente une charge qui peut s’avérer être très coûteuse en temps et en argent !

Quand et comment faire des tests de non-régression ?

Dans un projet Move2Cloud, on trouve deux phases principales :

• « Snapshot » : on copie les données dans l’environnement de destination, et on vérifie qu’elles sont bien identiques à celles de l’environnement source.
• « Double Run » : les données ont été validées dans l’environnement de destination, il s’agit maintenant de s’assurer que les traitements quotidiens de type ETL/ELT fournissent les mêmes résultats que sur l’environnement source.

Les tests de non-régression s’appliquent également lors de mise à jour ou changement d’outil de transformation de données : Est-ce que cette évolution a pu altérer mes données ?

Bref, il est donc très fréquent de devoir vérifier si les données sont toujours conformes à la suite d’une modification tierce.

Si le principe est simple, comparer des données d’un système A à un système B, différentes approches sont envisageables pour les tests de non-régression :

• Faire pointer un tableau de bord existant sur la nouvelle source de donnée et comparer le résultat
• Compter le nombre de ligne par table pour chaque environnement
• Faire un échantillonnage et comparer la source et la cible
• Calculer des statistiques au niveau des colonnes telles que des sommes, moyennes, min, max…
• Exporter les données sous fichier plat et les comparer avec un outil tiers
• Utiliser des méthodes de hash ou de checksum entre les environnements.
• …

Alors que privilégier et comment l’automatiser ?

Chez Business & Decision, fort de notre expérience sur les projets move2cloud, nous avons développé un outil afin d’aider et de faire gagner du temps à nos clients.

Nous avons pris le parti de garantir une comparaison à 100% et d’écarter les méthodes à base d’échantillonnages. Notre outil utilise des méthodes de hachage (ou hashs) et permet de s’adapter aux spécificités des bases de données (format de date YYYYMMDD vers du DD/MM/YYYY par exemple : la valeur est la même, mais son affichage la fait remonter comme une erreur lors de la comparaison). Les données ne sont pas déplacées, elles peuvent être sensibles et un export pourrait altérer son contenu.  

Il peut s’exécuter à la demande ou se planifier via n’importe quel ordonnanceur existant, tout en lui précisant le périmètre des tables à comparer. L’outil peut donc être utilisé autant durant la phase de snapshot que durant la phase de double run.

Un bon dashboard vaut mieux qu’une longue analyse de log !

Automatiser, c’est bien, suivre et piloter, c’est encore mieux !

Nous pouvons maintenant vérifier la conformité des données, mais que faire si les données sont différentes ? Par où commencer l’analyse ?

Un bon dashboard vaut mieux qu’une longue analyse de log ! Nous avons donc réalisé un tableau de bord qui permet de suivre l’avancement de vos tests de non-régression (nombre de tables validées / nombre de tables à valider). Il permet de piloter de façon objective et de quantifier simplement la qualité et l’avancement de la migration, et de communiquer avec toutes les parties prenantes l’état du projet de migration.

Le tableau de bord apporte également des pistes de correction si les données sont différentes. En effet, en cas d’écart, l’outil lance une analyse de statistiques sur les colonnes de la table concernée. On peut rapidement identifier les erreurs « classiques » comme un champ tronqué ou un facteur de multiplication sur des colonnes numériques par exemple.

J’espère que cet article vous aura éclairé sur les tests de non-régression et de la nécessité de les automatiser. Il est important de recentrer les équipes sur des tâches à valeur ajoutée plutôt que sur des actions répétitives et automatisables.

Si vous souhaitez en savoir plus ou si vous avez une migration en cours ou à venir, n’hésitez pas à nous contacter !