VERSIONING DES RÉFÉRENTIELS DE TEST
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.
​
Un défi rarement relevé qui aboutit à l’obsolescence du référentiel de test. L’enquête du CFTL de 2019 révèle que 82% des tests manager reconnaissent y être confrontés.
L’impact du versioning sur le référentiel de test
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 allez-vous 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 allez-vous gérer ces inchangés, ajoutés, obsolètes lors des tests de l’ancienne et de la nouvelle version ?
Le système de gestion des releases dans Scapin a pour but de répondre à ces problématiques.
Les Releases dans Scapin, outil d'automatisation de tests
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.
Utilisation des releases Scapin
Affectation de la plage de validité des objectifs et cas de test
Les objectifs et les cas de test ont tous une plage de validité, par défaut illimitée, c’est-à-dire de la release R0 à celle d’indice le plus élevé. Cette plage est modifiable dans l’interface d’édition des objectifs et des cas de test.
Release cible
Dans l’espace de travail « Test Jobs Workspace », le processus de création d’un job impose de choisir une release cible. Ainsi le job ne contiendra que des tests automatisés dont la plage de validité inclut la release cible.
La couverture de test par release
Le suivi de l’avancement des campagnes de test est facilité par cette gestion. La page d’accueil de l’atelier affiche les statistiques de couverture de test par release.
​
Dans l’exemple ci-dessous la release R0 n’en est qu’à ses débuts puisque qu’elle n’est exécutée avec succès qu’à 20%. Les 50% du reste à faire concernent des tests non exécutés et 30% des objectifs qui ne sont associés à aucun test. La release suivante R1 est encore moins avancée puisqu’elle est non exécutée à 67% et non couverte à 33%.
