Les jeux de données (Datasets)
Les jeux de données sont des tableaux de données exploitables par les tests. Ils trouvent toute leur utilité dans diverses circonstances :
pour renseigner des données initiales
pour stocker des données intermédiaires collectées lors des tests
pour assurer la réutilisation des tests
... etc. la liste n'est pas exhaustive
Mise en œuvre d'un jeu de données
La mise en œuvre d'un jeu de données passe par la création d'un accessoire de type Dataset. Pour la création et la configuration de cet accessoire consultez la documentation sur le Type Dataset. L'exemple ci-dessous montre la présence de plusieurs Datasets dans le magasin des accessoires.
Dès lors qu'un accessoire Dataset est créé et configuré, rendez-vous dans le menu principal à la rubrique Datasets de la section Managment . Tous les accessoires de type Dataset sont dans la liste déroulante Dataset. En sélectionnant un Dataset dans cette liste vous accédez à son contenu.
Pour ajouter une ligne à la fin du tableau cliquez sur ADD ROW, saisissez la valeur de chaque colonne dans la boîte de dialogue et cliquez sur SAVE.
Pour importer des données cliquez sur le bouton IMPORT. Sélectionnez un fichier au format CSV. L'importation supprime le contenu existant et le remplace par celui importé.
Pour exporter le contenu du tableau cliquez sur le bouton EXPORT. Un fichier portant le nom du dataset avec l'extension txt est créé dans le répertoire de téléchargement par défaut.
Exemple d'utilisation d'un jeu de données dans un test
L'exemple ci-dessous concerne le remplissage d'un formulaire contenant beaucoup de champs. Plutôt que d'avoir à saisir les données de ces champs au lancement du test et afin de pouvoir le réutiliser facilement, nous avons utilisé un jeu de données.
A l'étape 0 l'instruction Get Row Handle filtre les lignes dont la 1ère colonne contient tout ou partie de la valeur de la variable $id et renvoie dans la variable $handle l'identifiant de la 1ère ligne trouvée. Au lancement du test, seule cette valeur devra être initialisée.
A l'étape 1 l'instruction Get Row Data utilise l'identifiant mémorisé par la variable $handle pour récupérer dans la variable $LastName le contenu de la colonne Last Name. Les étapes suivantes de 2 à 9 font de même pour récupérer dans des variables le contenu des différentes colonnes.
A l'étape 13 la valeur mémorisée à l'étape 1 est utilisée pour remplir une zone de saisie.
Les variables d'environnement
Les variables d'environnement sont des variables fréquemment utilisées, dont la valeur évolue peu et pour lesquelles il est pratique de ne pas avoir à les ressaisir à chaque lancement d'un test.
Cliquez sur ADD pour ajouter une variable, sur un crayon bleu pour modifier la valeur d'une variable et sur la poubelle rouge pour supprimer une variable.
La valeur des variables d'environnement est seulement proposée à l'initialisation d'un test. Il reste possible de changer cette valeur avant de lancer le test.
Les Releases
Existe-t-il un logiciel, une application web ou mobile qui reste figée dans sa version d’origine ? Bien sûr que non ! S’adapter aux tendances du marché, coller aux besoins et aux attentes des utilisateurs interdisent l’immobilisme. Les logiciels doivent s’améliorer, évoluer en permanence. Cela signifie la sortie régulière de nouvelles versions. Chacune d’elles apporte son lot d’ajouts, de modifications, de suppressions. Ces changements ont des impacts sur les tests existants. Leur gestion au sein du référentiel de test est un défi auquel la cellule Test/QA est confrontée au quotidien.
Les outils de gestion des référentiels de test sont généralement dépourvu de solution de gestion des changements.
Il devient très vite compliqué de savoir quel test est valide pour quelle version. Il s'en suit une dégradation progressive du référentiel.
En 2019 l'enquête du CFTL a révélé que 82% des tests manager sont confrontés à un problème d'obsolescence de leur référentiel de test
L'impact du versioning sur les tests
Le passage d’une version à une autre est généralement progressif. Concrètement cela entraîne l’obligation :
-
D’assurer la non-régression et la vérification des correctifs de la version en production.
-
De commencer activement les tests automatisés de la nouvelle version.
Comment mener de front ces deux activités sans que l’une n’empiète sur l’autre ?
Par ailleurs, dans une nouvelle version, il y a ce qui change et ce qui ne change pas. Cela signifie que des tests automatisés sont inchangés, d’autres sont ajoutés et d’autres enfin sont obsolètes.
Comment gérer ces inchangés, ajoutés, obsolètes lors des tests de l’ancienne et de la nouvelle version ?
C'est à ces problématiques que répondent les Releases dans SCAPIN
Principes de gestion des Releases dans SCAPIN
Le principe qui régit la gestion des releases dans Scapin est celui des plages de validité. La notion de plage de validité s’applique aux objectifs et aux cas de test. Elle s’exprime ainsi : Depuis quelle version et jusqu’à quelle version l’objectif ou le cas de test est valable. Les versions s’échelonnant dans le temps, cette notion revient à introduire une temporalité dans la gestion du référentiel de test.
La release est un marqueur qui introduit cette temporalité. Elle est notée par la lettre R suivie d’un indice. Cet indice s’incrémente à chaque déclaration d’une nouvelle release. Il existe au moins une release, la R0 qui est créée lors de l’initialisation du référentiel.
Concrètement la release R0 correspond à la version la plus ancienne prise en charge par le référentiel. La release d’indice le plus élevé correspond à la version la plus récente.
Dans l’exemple ci-dessous nous voyons que 2 releases existent. La R0 initiale et la R1, qui a été déclarée le 8 avril 2021.
Pour créer un marqueur temporel de release rendez-vous à la rubrique Releases de la section Managment du menu principal puis cliquez sur le bouton ADD. C'est tout ! La release est créée. Les champs Expected Delivery Date, Effective Delivery Date et Notes sont facultatifs. Ils sont là pour vous permettre de contextualiser le marqueur temporel.
Affectation des plages de validité
Les objectifs de test et les cas de test ont une plage de validité par défaut illimité. Cela signifie qu'ils sont toujours valides. Ce n'est que lorsqu'une évolution applicative impacte certains objectifs ou cas de test que ces plages de validité sont modifiées pour ces objectifs ou cas de test et uniquement pour ceux là.
Il n'est donc pas nécessaire de créer une Release à chaque nouvelle version de l'applicatif. Ce n'est utile et pertinent que si la nouvelle version introduit des changements dans le référentiel de test.
Les plages de validité sont modifiables dans les fiches d'objectif ou de cas de test en mode édition.
La plage de validité d'un cas de test est encadrée par celles des objectifs de test auxquels il est rattaché. Supposons un cas de test associé à deux objectifs. La plage de validité de l'un s'étend de R0 à R4, celle de l'autre à partir de R2. La page de validité du cas de test s'en trouve réduite de R2 à R4. A l'inverse les plages de validité des cas de tests n'ont aucune incidence sur celles des objectifs de test.
Les marqueurs temporels de Release constituent une solution simple et peu contraignante de gestion dans le temps long d'un référentiel de test.
