Tests de non régression: Quel rôle dans la migration de solution BI?

Plusieurs d’entre vous font ou feront face un jour ou l’autre à l’inévitable. Vous devrez mettre à jours vos environnements BI. Que ce soit pour des raisons de compatibilité entre vos systèmes, de support/maintenance qui vient à échéance ou tout simplement d’une revitalisation de l’interface visuelle pour vos utilisateurs, on ne peut y échapper.

Phase de tests de non régression: Qu'est ce que c'est et pourquoi est-ce important?

Lors d’un projet de migration, toutes les étapes sont importantes et aucune ne devrait être négligée, comme le mentionne mon collègue Geoffrey Rabault dans son article “Trucs et astuces pour mener à terme un projet de migration en BI”. L'une des étapes, parfois oubliée et pourtant critique, est la "phase de tests de non régression". À quoi sert la phase de tests de non régression dans une migration de solution BI et pourquoi est-elle si importante? Cette étape est souvent la phase du projet qui est le plus demandant en termes d’effort. La raison est qu’il faut ouvrir chacun des rapports ou du moins un échantillon significatif de rapports et faire une validation complète de ceux-ci pour s'assurer de la réussite de la migration de solution BI.

Comment faciliter la phase de tests de non régression?

Pour éviter de couper les coins ronds et d’accélérer le processus tout en aidant à la gestion du changement, j’utilise la méthode “Diviser pour régner”. Disons, que vous avez 500 rapports à tester provenant de 10 départements différents et une poignée de testeurs de votre équipe projet. Il sera beaucoup plus facile d’effectuer la tâche si vous incluez dans votre équipe de migration un ou plusieurs supers utilisateurs de chacun des départements. Ils sont les mieux placés pour effectuer de bons tests sur leurs rapports. Ils seront de bons alliés et potentiellement de bon ambassadeurs de la nouvelle plateforme dans leur département respectif.

Maintenant, jusqu’où devons-nous aller avec les tests de non régression ? Cela dépend toujours de la complexité des rapports et de leur importance. Il est important de définir avec le client quels rapports doivent être irréprochables et lesquels peuvent être révisés un peu plus rapidement. Une fois défini, l’idéal

Par exemple, pour des rapports webi, voici les grandes lignes que devrait contenir votre grille pour effectuer de bon:

• Validation des formats (Polices, couleurs, etc…)
  
• Validation des invites et filtres (Est-ce que les valeurs sont bonne? est-ce que les filtres s’applique bien?)
  
• Validation de la donnée (Est-ce que mes données sont identiques ? est-ce que j’ai des erreurs dans certaines cellules ou totaux?)
  
• Validation des formules (Est-ce que le résultat est bon? est-ce que j’ai des erreurs dans des cellules?)
  
• Validation des requêtes (Est-ce que ma structure et syntaxe est la même? est-ce que j’ai une perte de performance?)
  
• Validation des sections et bris (Est-ce que mes bris et section sont encore présents? est-ce que mes totaux de bris et de section sont bons?)
  
• Validation que le nombre de pages est identique
  
• Validation que l’exportation fonctionne bien (Est-ce qu’on peut exporter en PDF par exemple)
  
• Validation que le rapport s’exécute correctement (Est-ce que l’on a des erreurs à l’exécution?)
  
• Validation du temps d’exécution (On migre pour le mieux et non pour le pire, on ne veut pas être plus lent qu’avant)

Rappelez-vous que de bons tests vous prendra inévitablement plus de temps en réalisation, mais les gains du côté de la gestion du changement sont énormes. Nous, les humains, sommes réticents au changement. Si en plus nous devons changer pour quelque chose qui fonctionne moins bien que ce que nous avions avant, je peux vous garantir que la route vers l’acceptation sera longue et très ardue. N’oubliez pas que cette migration doit être pour le bien de l’utilisateur, car c’est pour eux que vous la faites.