Comment définir une stratégie de test de migration

Les risques métier et de conformités sont directement impactés par les erreurs de migration de données. Réduire considérablement ces risques est un objectif atteignable grâce à une stratégie de test rigoureuse adaptée.

L’approche recommandée pour concevoir des stratégies de tests de migration consiste à :

1. identifier le risque,
2. estimer sa probabilité d’occurrence,
3. puis à définir les moyens d’atténuer le risque par des tests.

L’identification des risques est délicate et une grande partie du processus sera spécifique au système en cours de migration.

Passons en revue deux systèmes pour illustrer ce point :

1. Dans le premier cas, la migration des données financières dans la banque de détail est généralement définis par des migrations de volume élevé (des dizaines ou des centaines de millions d’enregistrements) où les enregistrements de la source à la destination sont assez similaires et impliquent une traduction minimale et peu ou pas d’enrichissement des données.
2. Pour un deuxième exemple, prenons la gestion des réclamations d’une entreprise de produits de consommation. Ces systèmes ne sont généralement pas matures et les nouvelles implémentations, ainsi que les processus opérationnels qui leur sont associés, doivent s’adapter à des exigences commerciales et de conformité variables. Ces systèmes ont un volume modeste en comparaison (des dizaines, ou des centaines de milliers d’enregistrements) avec des traductions complexes et un enrichissement des données pour compléter les nouveaux enregistrements au fur et à mesure de leur migration.

Dans les deux cas, il est essentiel que les données migrées soient représentées avec précision dans le système de destination. Toutefois, le processus de définition de la précision variera considérablement entre ces deux systèmes et les migrations qui leur sont associées.

1. Dans le premier cas, le secteur des services financiers a évolué au point qu’il existe des normes d’échange de données, ce qui simplifie grandement ce processus.
2. Dans le cas où les données de gestion des plaintes sont transférées, une analyse initiale beaucoup plus poussée sera nécessaire pour « adapter » au mieux les données existantes dans le nouveau système.

• Enrichir les données pour compléter les enregistrements incomplets
• Nettoyer les données source avant la migration
• Lancer la migration (à sec)
• Vérifier les résultats de la migration

L’échantillonnage est une bonne technique de test de migration si elle est utilisée avec d’autres techniques dans le cadre d’une stratégie cohérente.

L’échantillonnage seul ne permet pas d’éprouver de la confiance dans son produit, il implique une multiplication des itérations de test et de correction sans pouvoir contrôler les régressions.

Stratégie de test de migration :

Les points-clé de la stratégie de test de migration de données sont structurés par phase  comme suit :

1- Tests de pré-migration

1. Vérifier le périmètre des systèmes source (SAP…) avec le PO et l’équipe de Dev.
   • Données à inclure
   • Données à exclure
2. Définir  la cartographie de haut niveau entre la source et la destination pour chaque catégorie de données et vérifier que cette catégorie a bien été prévue dans le système de destination.
3. Vérifier les exigences des données du système de destination comme : noms des champs, types des champs, champs obligatoires, liste des valeurs valides ainsi que les autres contrôles de validation au niveau des champs.
4. Vérifier que les données de la source répondent aux exigences du système de destination, en utilisant la cartographie entre la source et la destination (mapping). Par exemple :
   • Si le système de destination a un champ obligatoire, vérifier que le champ source correspondant n’est pas null
   • Si le champ de destination a une liste de valeurs valides, vérifier que les champs sources correspondants ont bien ces valeurs valides.

• Tester les champs qui lient de manière unique les enregistrements source et destination et s’assurer qu’il existe une correspondance définitive entre les ensembles d’enregistrements
• Tester la connexion à partir de la plateforme de migration aux systèmes source et destination
• Tester la configuration de l’outil de migration par rapport à la spécification de migration qui peut souvent être complétée par un test de la boîte noire, champ par champ.

2- Réaliser une revue formelle de la spécification de la migration de données.

Cette spécification doit contenir :

1. L’identification des systèmes source 
2. Les données et les requêtes du système source
3. La cartographie des champs (mapping) entre le système source et le système de destination
4. Le Nombre des enregistrements source
5. Le Nombre des enregistrements créés par unité de temps (utile pour définir le temps nécessaire pour effectuer la migration)
6. Les Exigences de nettoyage des données source
7. Les Exigences de performance
8. Les Exigences de test

La revue de spécification doit impliquer un représentant des utilisateurs (Product Owner), l’équipe de développement et le management, elle doit se dérouler avant de s’engager dans le gros des travaux de configuration de l’outil de migration.

3- Tests de post-migration

1. Tester le débit du processus de migration (nombre d’enregistrements par unité de temps)
2. Réaliser la vérification qualitative – Comparer les dossiers de la source aux dossiers générés par le système de destination (sans calcul) – S’assurer que les dossiers transférés sont complets et correspondent au contexte approprié.

Cette activité nécessite un échantillonnage pertinent des données de test :

1. Objets riches : Champs remplis, pièces jointes en nombre, et historique rempli.
   • Séances riches : objets multiples de types différents et des décisions variées
   • Jetons de présences riches : personne, parti, global, avec des rectifications comptables positives et négatives
   • Extraits du CA riches
   • Tâches de commissions, départements, délégations, administratives
   • … etc.
2.  Réaliser la vérification quantitative – Il existe plusieurs techniques qui permettent d’obtenir des informations sommaires, notamment le comptage des dossiers et checksums. Ici, le nombre d’enregistrements migrés est compilé à partir du système de destination et ensuite comparé au nombre d’enregistrements migrés. Cette approche ne fournit que des informations sommaires et, si un problème existe, elle ne permet pas souvent d’en connaître la cause première.

• Comparer les enregistrements calculés à partir de la source aux enregistrements de la destination – Les tests doivent vérifier que les valeurs des champs sont migrées conformément à la spécification de migration. En bref, les valeurs des sources et les correspondances au niveau des champs sont utilisées pour calculer les résultats attendus à la destination. Ce test peut être réalisé par échantillonnage si nécessaire ou si la migration comprend des données qui présentent un risque commercial ou de conformité important, 100 % des données migrées peuvent être vérifiées à l’aide d’un outil de test automatisé.

4- Tests d’acceptation utilisateur de la migration de données

Les subtilités fonctionnelles liées à la cohabitation des données migrées et des données créés dans le nouveau système sont difficiles à identifier tôt dans le processus de migration. Cette étape est la première opportunité pour les utilisateurs d’interagir avec les données historiques dans le nouveau système avant la production.

5- Migration de la production

1. Tous les tests effectués avant la migration de la production ne garantissent pas que le processus de production se fasse sans erreur.
2. Parmi les difficultés rencontrées à ce stade figurent les erreurs de procédure et, parfois, les erreurs de configuration du système de production. Si un outil de test automatisé a été utilisé pour tester les données et le contenu après la migration, il est recommandé de l’utiliser pour effectuer un test en production.
3. Si une approche automatisée n’a pas été utilisée, un certain niveau d’échantillonnage est recommandé.