10 Jul 2012

10 Jul 2012

Le développement décisionnél orienté test en méthode Agile – “Trompez vous jusqu’à que ca fonctionne!”

By:

Category: New Feature, News

Le développement décisionnél orienté test en méthode Agile – “Trompez vous jusqu’à que ca fonctionne!”

Le développement de l’utilisation de la méthodologie Agile au cours des dernières années a affecté le cycle de développement et les processus de test. Le concept est de travailler en cycles de développement courts et de commencer le développement avec l’écriture d’un scénario de TEST définissant la fonctionnalité attendue. Le TEST lui-même échouera bien sur au début puisque le développent en lui même n’a pas commencé. Mais il accompagnera le développeur au cours du processus de développement. Par conséquent, chaque processus de développement est une évolution cyclique guidée par le concept de “Trompez vous jusqu’à que ça fonctionne!”. Le but étant de travailler selon les étapes d’un processus cyclique.

  1. Créer un test – le test échouera jusqu’à ce que la fonctionnalité souhaitée fonctionne. Le test devra être guidé selon les exigences Métier et les résultats attendus,
  2. Exécuter tous les tests et constater l’échec du test,
  3. Commencer votre développement jusqu’à que le test soit lancé avec succès. A ce stade, le code peut ne pas être optimal mais la cible est atteinte.
  4. Nettoyez/optimisez votre code pour un résultat optimal..
  5. Lancer tous les tests
  6. Répéter les étapes si nécessaire.

 

TestDrivenDevelopmentCycle

Le développement BI orienté test permet de travailler avec des unités de codage courtes se rapportant généralement à un groupe de fonctions.  Cette méthodologie est très classique dans le secteur du logiciel mais son utilisation dans le décisionnel reste parfois floue. L’introduire par la méthodologie réduit le temps de débogage et de QA apparaissant en phase de développement. Cela réduit les “surprises” à la livraison ou lors de l’acceptation des tests. En conséquence, le niveau de risque lors de la livraison diminue également.

Dans le secteur du décisionnel, l'unité sera généralement un modèle ou une partie "logique" d'un modèle et peut-être une fonctionnalité principale de l'entrepôt de données ou encore une fonctionnalité secondaire tel qu'un rapport ou un tableau de bord.

Comment appliquer le concept “Trompez vous jusqu’à que ca fonctionne!”  dans les environnements décisionnel en utilisant QualityGates?

  1. Crée le scénario de test et le test lui-même en utilisant les assistants QualityGates.
  2. Commencer le développement – de manière rapide et grossière lors de cette phase, vous pourrez isoler une nouvelle logique/partie de code de votre processus ETL. Le code va correspondre à la logique de test et pourra ainsi être répondre aux résultats finaux (enregistrements, reporting, tableaux de bord).
  3. Lancer les tests durant le cycle – Lors de cette phase, il s’agit de valider que la nouvelle logique correspond aux nouveaux tests et que tous les autres tests passent avec succès – il n’y a donc aucune régression possible. Dans le cas contraire, vous la détecterai à un stade précoce. Les tests de non régression QualityGates peuvent inclure l’exécution des tests sur d’autres parties logiques du modèle, ou en comparant l’ensemble des résultats obtenus entre les versions (applicables aux versions de base de données ainsi qu’aux versions des reportings et tableaux de bord) en utilisant l’un des tests de comparaison de QualityGates.
  4. Répéter si nécessaire.

Comment tester la logique complexe sans la dupliquer une nouvelle fois?

Le principe directeur est “aussi simple que possible” – concentré sur le résultat final.

Les enregistrements erronés ajoutés à vos données vous suivront le long de toutes les étapes du processus jusqu'au résultat final. Ayant créé vous même ces enregistrements, vous saurez quel est le résultat ou le seuil final désiré. QualityGates vous permet de créer un flux d’exécution qui produira les enregistrements erronés et les reliera à ceux de votre test. Vous pourrez également combiner le test depuis votre processus de traitement externe vers n'importe quel outil de traitement (ETL tools, Qlikview, SAP loading, etc…).
Cette méthode couvre les tests de logique à 90% - elle ne couvre pas les scénarios spéciaux qui donneront des données surprenantes mais vous pourrez couvrir ce risque grâce à d'autres tests supplémentaires (les totaux, seuils cumulés conformément aux normes métiers, etc...). Les tests qui sont plutôt des duplications de la logique ETL n'est pas optimale car vous dupliquez aussi vos éventuels bugs, et cela ne vous aidera pas à valider votre code.


Essayez QualityGates dans votre environnement gratuitement ici