Jeu de données généré automatiquement pour réussir sa campagne de test

Nos lecteurs les plus fidèles le savent, le succès d’une campagne de tests automatisés repose sur plusieurs éléments :

• Les définitions préalables.
• Des équipes compétentes et organisés.
• Un plan structuré et des conditions réalistes.
• Des jeux de données (JDD) 

De la qualité des jeux de données dépend la réussite et l’aboutissement de la campagne de tests. Et mettre en place des jeux de données c’est loin d’être évident.

Les jeux de données sont rarement pensés au démarrage du projet de tests automatisés et ou parallèlement à la construction du scénario. Dans la majorité des cas rencontrés, les scénarios sont imaginés, les tests sont développés puis les jeux de données sont compilés. C’est une erreur critique car ils sont la pierre angulaire de la réussite d’un plan de tests et de la bonne exécution du patrimoine de test.

Tout cela conduit inexorablement à d’innombrable “défauts” remontés lors de l’exécution des tests qui sont en réalité uniquement dû à un jeu de données non conforme à l’exécution du patrimoine de test. Et, on ne mesure pas le temps nécessaire aux équipes impliquées pour identifier que le défaut n’est pas lié à une erreur de développement mais uniquement à un mauvais jeu de données.

Fort ce constat, nos équipes R&D ont commencé le développement d’une fonction DAET (déploiement automatique d’un environnement de tests).

DAET, Quésaco ?

L’idée est de générer automatiquement les jeux de données nécessaires à la campagne des tests et ce de manière itérative.

Les tests End User, directement réaliser via l’IHM, impose des jeux de données très variés. Une campagne de tests de montée en charge aura obligatoirement besoin de s’appuyer sur pléthore de credential (user/password),  une campagne de tests de non régression : sur des profils d’utilisateurs différents.

Notre analyse : ces données doivent être enregistrer via l’IHM qui permet de le faire. De fait, Il est possible de scripter les scénarios pour générer automatiquement les informations qui seront ensuite nécessaires à la bonne exécution de tests. Certains diront qu’il suffit de passer via des traitement batchs (insertion des données directement dans la base pour s’affranchir du front office) pour injecter les données mais cette solution n’est pas parfaite :

• Elle occulte toutes les règles de gestion activées suite à la saisie des données.
• Elle inhibe toutes les « défauts » (bugs ?)  qui seraient liés à l’ IHM (Interface Homme Machines) lors de la saisie de ces données.

Soyez-en sûr, vous allez intégrer des données non conformes aux développements et introduire des “défauts” dû aux jeux de données.

Démonstration par l’exemple :

Règle de gestion : La date de fin de contrat ne peut être inférieure à la date de début. La règle est codée et s’applique via l’IHM (et non via un trigger).

Vous créez un batch qui justement, erreur humaine, insère une date de fin de contrat inférieure à la date de début de contrat. Vous exécutez la campagne de TNR ou l’un des scénarios est de vérifier cette règle.

Résultat : le scénario est en défaut et dans notre cas en « erreur ».

Un ticket est créé et les équipes de développement vont perdre du temps à chercher le dysfonctionnement alors que le “défaut” n’est pas lié au développement. Vous trouverez la cause mais au bout de combien d’heures ? de jours ? et la tension générée entre les équipes … catastrophique. 

C’est pour s’affranchir de ces problèmes que nous travaillons actuellement sur le développement d’un outil qui permettra de générer automatiquement les jeux de données, via des scénarios scriptés.

Ce système sera structuré en plusieurs phases :

1 – Etude des tests à réaliser
2 – Définition des JDD nécessaires à l’exécution des tests
3 – Créations des scénarios pour générer les JDD
4 – Créations des scénarios pour exécuter la campagne de TNR

Puis le processus d’implémentation déploiement automatique des tests (DAET) :

I1 – Implémentation d’une BDD d’homologation vierge
I2 – Exécution des scénarios pour créer les jeux de données
I3 – Sauvegarde de la BDD contenant les JDD pour la campagne

Campagne de TNR ou TMC 

T1 – Implémentation de la BDD (Phase I3)
T2 – Exécution de la campagne de tests  (TMC ou TNR)
T3 – Analyse de défauts
T4 – Correctifs (si dysfonctionnement) 

Les phases T1 à T3 sont itératives tant qu’il est nécessaire de réaliser la phase 4.

Ce mode opératoire est réalisé désormais assez fréquemment lors de campagne de TMC. Mais encore de manière exceptionnelle pour les campagnes de TNR car beaucoup plus compliqué à mettre en œuvre.

—

Nous ne manquerons pas de vous tenir informé de la mise à disposition de cette évolution majeure pour la fiabilité de vos tests. Ainsi CloudNetCare permettra non seulement le MCO (Maintien en Condition Opérationnelle) du patrimoine et tests et de l’infrastructure pour exécuter vos tests, mais également de la génération de vos JDD.