BI.Quality : tests automatisés pour comparer des données entre SSAS et SQL Server

Comme je vous le disais tantôt, l’amélioration continue des équipes et des solutions passent par une automatisation des activités qui peuvent l’être. Ce n’est pas moi qui l’invente, c’est à la base de l’Agilité et du Lean. Notez que ce n’est pas une fin en soi, mais plutôt dans l’objectif de tendre vers un temps de production le plus court possible, toujours en qualité optimale.

Et une des principales manières d’avancer sur sujet c’est bien par l’automatisation des tests. C’est la raison pour laquelle je teste depuis peu BI.Quality, l’outil de test automatique gratuit développé par ORAYLIS et disponible sur le CodePlex.

BI.Quality

Ce qui est particulièrement intéressant avec cet outil c’est la possibilité de comparer des datasets en provenance de SSAS, de SQL Server, ou d’un fichier CSV. Vous comprenez l’intérêt immédiatement : avec ça on va pouvoir comparer de manière automatique son cube (via requêtes MDX) avec son DWH et/ou son ODS (via requêtes SQL). On pourra également comparer le résultat d’une même requête contre plusieurs environnements (production, intégration, développement…) pour valider que tout est bien synchro une fois la livraison terminée.

Joie !

Alors ok, l’interface ne fait pas rêver, et quasiment toute la « programmation » se fait dans des fichiers XML, donc à la main dans NotePad++. Mais la fonction rendue est tellement excellente qu’on apprend à vivre avec.

NUnit_1

Je vous fais un guide de démarrage rapide, vous allez voir c’est assez simple :

  1. Télécharger et installer NotePad++, si ce n’est pas déjà fait !
  2. Télécharger et installer NUnit (framework de test, c’est lui qui exécutera les tests créés dans BI.Quality), la version courante c’est la NUnit-2.6.2.msi
  3. Télécharger et installer BI.Quality (pas de panique, il termine sans prévenir, c’est un peu artisanal)
  4. Télécharger et lire la documentation :p
  5. Suite à ça, on dispose dans le menu démarrer :
    1. D’un répertoire BI.Quality, qui contient principalement un ZIP contenant la solution template, qui sera le modèle de départ pour tous les projets de tests. A dézipper là où vous le souhaitez pour chaque nouveau projet.
    2. D’un répertoire NUnit, qu’il va falloir associer avec votre projet de test (le répertoire dézippé), dans NUnit : File> Open Project > …\Lib\BI.Quality.dll

Une solution de test BI.Quality c’est donc un dossier composé de 4 sous-répertoires (le contenu du ZIP) :

  • \Bin\ et \Lib\ : on ne touche pas
  • \Connections\ : on va définir nos connexions là-dedans, un fichier XML correspondant à une connexion. On ne peut y utiliser que des belles chaînes de connexions OLE DB (SSAS, SQL Server < 2008R2, SQL Server 2012, à tester sur Excel, Access et SharePoint) :

BI.Quality_Connections

  • \Queries\ : on va définir nos tests là-dedans, un sous-répertoire correspondant à un test, avec :
    • des fichiers SQL, MDX ou CSV qui définissent les requêtes à utiliser dans le test
    • un fichier XML qui définit le test en lui-même

BI.Quality_Query

Franchement c’est pas sauvage non ? Je définis 2 sets de données, les <Query/>, que je compare dans un test <AssertTable/>.

Alors il existe plein de tests possibles, avec plein d’options, à voir dans le PDF de documentation ainsi que dans l’ensemble de tests livrés dans le template (1-Tutorial, 2-TechnicalTests, 3-BestPractices) que vous pouvez d’ailleurs enlever de votre projet si vous voulez avoir une solution bien propre.

Une fois que c’est fait, on retourne dans NUnit (on charge le projet si ce n’est pas déjà fait : File> Open Project > …\Lib\BI.Quality.dll), et on peut exécuter ses tests d’un simple RUN :

NUnit_2

Si la partie « Configuration Test » est gérée toute seule, NUnit va parser les XMLs de définition des connexions et des tests pour valider leur format, la partie « Query Test » est bien celle pilotée par vos tests du répertoires \Queries\ . Notez que si vous ne passez pas le « Configuration Test », c’est que vos XMLs sont mal montés : direction NotePad++ pour corriger tout ça. Si tout va bien, c’est parti pour vos tests à vous 🙂

Juste une petite remarque en passant : je n’ai définitivement pas réussi à ajouter un Delta sur un AssertTable, n’hésitez donc pas à faire plutôt des ROUNDs dans vos requêtes SQL ou MDX, si par exemple vous changez de précision entre les 2 sources. [MàJ 2013-08-19] En fait il est possible de définir un Delta dans un AssertTable, mais en utilisant une virgule plutôt qu’un point dans la valeur: delta=« 0,1%« . Trop bien 🙂

Et une deuxième petite remarque : pensez bien à recharger vos tests si vous les modifiez (File> Reload Project ou Reload Test) sinon ce ne sera pas pris en compte par NUnit.

D’un point de vue stratégie de tests, je suis partie sur les éléments suivants :

  • D’abord des agrégations de haut niveau (mon CA par an sur les 5 grands pôles d’activité), qui valident que le total général est le même partout
  • Des tests sur chaque dimension, indépendamment des faits, pour valider qu’on n’oublie personne en route et que les hiérarchies tiennent la route
  • Des tests portant sur les valeurs des mesures clefs pour chaque code atomique de chaque dimension (autant de tests que de dimensions). On a vérifié les hiérarchies dans l’étape précédente, il suffit donc de valider que chaque code dispose des bons montants unitairement pour chaque dimension pour valider quasiment tout
  • Des scénarios de référence (SQL/MDX vs valeurs en dur dans des CSV). Si les valeurs historiques (2009,2010…) n’évoluent plus, on peut se faire quelques extraits, les stocker en CSV, et les comparer régulièrement contre le cube ou le DWH. Histoire de prendre en flagrant délit la régression sur l’historique
  • Les requêtes des rapports SSRS, qu’on peut valider contre des valeurs de références ou entre plusieurs environnements
  • Enfin, toutes les requêtes issues des analyses d’anomalie, écrites pour renvoyer du vide si tout va bien

Si on maintient bien à jour sa base de tests, et qu’on exécute le projet régulièrement, il va devenir vraiment difficile de livrer du code défectueux !

Je conclue en vous livrant l’avis de Chris Webb sur l’outil, et en vous recommandant chaudement de l’essayer sur votre prochain projet ou prochaine recette. C’est simpliste, certes, mais ça fait le job, et pouvoir tous les jours exécuter toute sa batterie de test en 1 clic c’est juste magique ! Seul petit bémol: la dernière mise à jour du projet date de fin 2010, le dernier commentaire des admins de fin 2012… Alors allez le télécharger, histoire de bien montrer qu’on a besoin d’eux 😉

Electronic Arts ne teste pas ses tests?

J’ai reçu un second mail d’EA, le lendemain du premier:

Greetings from EA,

The e-mail you received yesterday was sent in error to some users during a test procedure. The e-mail is not dangerous, and your address has not been shared with any third parties. We apologize if the email caused any confusion, and the message content itself can safely be ignored. Thank you for your understanding.

If you have any other questions about this issue, your account, or any of our games, don’t hesitate to contact our support team.

Sincerely,

Electronic Arts

Le côté positif : ils assument l’erreur. Je mets quand même un mauvais point sur le « We apologize if… », la formule creuse qu’il faut définitivement arrêter d’employer si l’on est sincère.

Le côté négatif : une campagne de test qui passe en production? Hu hu faut revoir les procédures de déploiement les gens, si c’est vraiment ce qu’il s’est passé ça craint 🙂

Electronic Arts ne teste pas ses mailings, tss tss tss…

(Mise à jour 11/04/2011)

Et je trouve ça grave!

Aujourd’hui j’ai reçu ce mail:

Mailing reçu de Eletronic Arts

Mailing reçu de Eletronic Arts

L’adresse source me semble propre: EA@em.ea.com. Entre nous, va savoir ce qu’est le em dans l’adresse. Ca doit surement avoir du sens dans l’organisation interne de la boite, ou par le nom du serveur ou du projet à l’origine de la chose, mais est-ce vraiment nécessaire de le faire apparaître dans un mail publique comme celui là? Mais passons, là n’est pas le débat.

Le problème est que je ne me souviens pas avoir créé un compte chez eux ces derniers jours. J’ai bien installé un jeu en début de semaine dernière mais je ne crois pas qu’il soit EA, et de plus je doute qu’ils mettent 1,5 semaines à créer un nouveau compte.

Donc pour moi il doit y a erreur: je ne devrais pas recevoir ce mail. Puisqu’existe l’option dans le mail (en taille de police deux fois plus petite que le reste, vous avez honte ou quoi?) je vais désactiver et fermer le compte et oublier toute cette histoire.

Le problème c’est que quand je clique sur ce lien, j’arrive là:

Echec critique Electronic Arts!

Echec critique Electronic Arts!

Pour ceux qui ne verraient pas l’image, on me demande un login et un mot de passe… pour désactiver un compte dont je n’ai pas le mot de passe (et en espérant que le login soit l’adresse mail).

Alors peut être que le serveur « profile » est down ce matin, peut être qu’une configuration a sauté dans le dernier reboot, je ne sais pas, mais faudrait peut-être penser à tester tout ça, régulièrement. Parce que là clairement c’est la honte dans le user flow.

Donc je fais quoi moi? Je dois me rajouter un item à ma todo list pour réessayer plus tard? Je dois perdre 10 minutes pour trouver une adresse de contact et me plaindre? Perdre 30 minutes pour un article de blog (clairement la meilleure option ;))? C’est nul comme gestion des clients. Et le pire c’est que je ne sais même pas si je suis client dans ce cas…