Quoi - Comment
Les réponses à vos questions
Quelques informations générales sur les arborescences
A la racine de l'arborescence, seule la création de sous-dossier est possible. Les fiches ne peuvent être ajoutées que dans les sous-dossiers de la racine.
Sauf pour Test Jobs, un nom par défaut est attribué au dossier à sa création, comme le montre l'exemple ci-dessous.
Notez les icônes de droite pour déplacer le dossier, créer un sous-dossier ou le supprimer. L'icône de suppression n'est visible que si le dossier est vide. A tout moment, l'utilisateur peut renommer le dossier en cliquant sur l'icône approriée.
Point d'attention : Pensez à valider le renommage par la touche <Entrée>
Pour savoir comment déplacer un dossier rendez-vous ici
Comment déplacer des fiches ou des dossiers dans l'arborescence ?
Pour déplacer une fiche ou un dossier, cliquez sur l'icône représentant une croix qui apparait lorsque la fiche ou le dossier est sélectionné.
Des cases à cocher s'affichent au droit des fiches et des dossiers. Cochez la case du dossier dans lequel vous voulez déplacer une fiche ou un dossier.
Pourquoi les objectifs de test et comment les rédiger ?
La rédaction des objectifs de test ne va pas de soi. C'est une étape que l'on a tendance à zapper pour aller directement au concret, c'est-à-dire plonger dans l'ingénierie des tests. C'est oublier que les objectifs de test constituent le point de départ d'une démarche Qualité cohérente et efficace.
La Plateforme de Qualification SCAPIN vous aide à "Structurer une démarche Qualité"
Sur quelles bases et à partir de quoi rédiger des objectifs de test ?
L'espace de travail Test Goals vous permet d'organiser et de hiérarchiser les objectifs de test. Il vous appartient de les rechercher dans les documents produits par les promoteurs du projet. Selon les organisations, leur taille, leur degré de maturité, vous disposerez tantôt de documents bien formalisés, tantôt de simple emails. Parfois même serez-vous amené à recueillir des informations précieuses au cours d'entretiens informels avec les acteurs du projet.
Comment rédiger ces objectifs de test ?
Une bonne pratique consiste à adopter une structure commune à tous les objectifs de test. Ceci afin de focaliser la rédaction sur ce qu'il est important de tester et assurer une certaine cohérence de l'ensemble. Ci-dessous un exemple de rédaction :
SCAPIN n'impose aucun formalisme. C'est au Test Manager de mettre en place le formalisme le mieux adapté à la situation et au projet.
Notez qu'il est possible d'insérer des liens vers des sources documentaires internes à l'entreprise ou externe.
Point d'attention : L'écueil à éviter, c'est de mettre tout un tas de choses dans un même objectif de test. La rédaction doit être succincte, claire et ciblée. Veillez à bien répartir les différents enjeux, contraintes, règles de gestion et autres exigences dans des objectifs de test distincts.
Soigner la rédaction du cas de test
La rédaction de la description du cas de test mérite d'être soignée. Pour cela, une bonne pratique consiste à mettre en place dès le début du projet une structure commune à tous les cas de test comme dans l'exemple ci-dessous :
SCAPIN n'impose aucun formalisme. C'est au Test Manager de mettre en place celui qui lui convient.
Cette description est visible depuis l'espace de travail Test Goals sur la fiche d'objectif de test à laquelle est associée le cas de test. C'est pourquoi sa rédaction est importante. En effet, il est fréquent que la vérification d'un objectif de test nécessite plusieurs cas de tests. Par exemple un test pour vérifier le cas passant et un autre le cas non passant de l'application testée. Par conséquent, outre des informations pratiques telles que les prérequis, il est important de bien préciser ce que fait le test et en quoi il sert l'objectif auquel il est associé.
Comment dupliquer un cas de test ?
Avec la duplication de cas de test, la création de variantes de tests existants est rapide et facile à mettre en œuvre. Pour dupliquez un cas de test, rendez-vous sur sa fiche et cliquez sur le bouton cerclé de rouge :
Une boîte de dialogue s'affiche qui propose 2 options de duplication. La 1ère est une copie brute du cas de test sans reprise des objectifs de test associés :
Cette option de copie est intéressante lorsque l'on veut repartir d'un test qui existe déjà pour en créer un tout à fait différent mais dont une partie du déroulé est commun.
La 2ème option consiste à créer une variante du test initial suite à une évolution du comportement de l'application apparue dans une nouvelle version :
Dans ce cas les objectifs de test sont conservés et les plages de validité du test initial et de sa copie sont modifiées pour acter du fait que le test initial est valable jusqu'à la version précédente et qu'il est remplacé par le test copié dans la nouvelle version.
En savoir plus et comprendre Les Releases
Verrouillage des cas de test
Lorsque le cas de test est finalisé, il peut être verrouillé pour qu'il ne soit plus modifiable. D'un simple coup d’œil, l'aspect de l'icône attachée au cas de test nous renseigne sur son statut.
Cas de test modifiable
Cas de test verrouillé
Dans l'espace Test Goals l'aspect des icônes renseigne sur le statut des cas de test associés de la fiche d'objectif de test.
Le verrouillage du cas de test est nécessaire pour qu'il soit intégré à une campagne de test. Afin de prévenir des incohérences entre le cas de test et les rapports d'exécution de ce test, le déverrouillage est impossible tant qu'il existe de tels rapports.
Les campagnes de test
Pour commencer une campagne de test, rendez-vous dans l'espace de travail Test Jobs, sélectionnez un dossier et cliquez sur le bouton CREATE A NEW TEST JOB
Dans la boîte de dialogue qui s'affiche, saisissez le nom de votre campagne et validez. La fiche de campagne s'affiche ainsi :
Constitution du jeu de tests
La constitution du jeu de tests obéit à des règles strictes. Ceci pour assurer la cohérence de la démarche qualité que structure la Plateforme de Qualification SCAPIN.
1ère règle :
La campagne est associée à une Release cible, c'est-à-dire à un marqueur temporel de validité des objectifs et des cas de test. En conséquence :
2ème règle :
Ne peuvent être inclus dans le jeu de tests que les tests associés aux objectifs de tests valides pour la Release cible.
3ème règle :
Ne peuvent être inclus dans le jeu de tests que des tests valides pour la Release cible.
4ème règle :
Seuls les cas de test verrouillés peuvent être inclus dans le jeu de tests.
Pour en savoir plus sur la gestion des marqueurs temporels et leur impact sur les tests et les objectifs de test, reportez-vous à la documentation Les Releases
Cliquez sur le bouton BUILD TEST SET pour constituer votre jeu de tests.
Choisissez la livraison cible, naviguez dans l'arborescence pour sélectionnez les objectifs de test poursuivis par la campagne de test puis cliquez sur le bouton NEXT. Seuls les objectifs de test éligibles apparaissent dans l'arborescence.
Constituez votre jeu de tests. Seuls les tests éligibles apparaissent dans l'arborescence. Notez qu'un même test peut apparaitre plusieurs fois dans le jeu de tests. Cliquez sur SAVE pour sauvegarder le jeu de test
Lancement d'une campagne
Le jeu de tests étant constitué, la rubrique TEST SET de la fiche de campagne a été mise à jour. Cliquez sur l'icône cadenas pour verrouiller le jeu de tests. Ce n'est qu'une fois verrouillé qu'il devient possible de lancer la campagne de test.
Cliquez sur le bouton CREATE A NEW JOB pour ouvrir l'assistant de lancement de la campagne de test qui se déroule en 3 étapes.
La 1ère étape est l'étape de valorisation des données initiales des tests du jeu. Lorsque tous les champs de la colonne Value sont renseignés, cliquez sur le bouton NEXT pour passer à l'étape de compilation des tests.
La 2ème étape est une étape de contrôle de la compilation et de la valorisation. La capture ci-dessous donne un exemple de cas d'erreur de compilation. Dans ce cas cliquez sur le bouton BACK pour revenir à l'étape précédente.
La 3ème étape définit les conditions de lancement de la campagne :
Par défaut les tests sont lancés en parallèle sur l'ensemble des terminaux de test disponibles. La campagne peut aussi être lancée en différé en cliquant sur la bascule Delayed Launch et en fixant une date et une heure de démarrage de la campagne. Pour lancer la campagne, cliquez sur le bouton LAUNCH JOB
Note importante
Contrairement aux tests d'une campagne qui sont par défaut exécutés en parallèle sur l'ensemble des terminaux disponibles, les campagnes de tests s'exécutent l'une après l'autre. Elles sont mises dans une file d'attente et ne démarrent qu'à leur tour et à condition que des terminaux de test soient disponibles.
Les statuts d'une campagne
Pending :
La campagne est en attente d'exécution. Le bouton DELETE permet de retirer la campagne de la liste d'attente.
Running :
La campagne est en cours d'exécution. Dans ce cas une barre de progression indique l'avancement de la campagne. Le pourcentage indique la proportion d'étapes de test exécutées sur le total cumulé des étapes de tests de tous les tests du jeu. Un bouton placé à droite de la barre de progression permet d'interrompre l'exécution de la campagne.
Done :
La campagne est terminé. Dans ce cas un bouton apparait pour accéder au reporting d'exécution de la campagne. Le bouton est vert si la campagne s'est déroulée sans erreur, rouge dans le cas contraire.
Le reporting d'exécution
Lorsque l'on clique sur le bouton SEE REPORT une 1ère boîte de dialogue montre le résultat d'exécution test par test :
Cliquez sur l'une des lignes pour accéder au reporting d'exécution d'un test :
Le reporting se présente en triptyque avec :
A gauche, le déroulé du test que l'utilisateur peut parcourir avec la souris et les touches clavier haut/bas
Au centre, le détail de l'étape sélectionnée telle qu'elle a été mise en œuvre dans le StepBuilder.
Si l'étape sélectionnée est celle d'une interaction avec un élément graphique de l'application, l'image de l'écran est affichée et l'élément concerné est mis en évidence par un rectangle rouge.
Au dessus du cartouche Paramètre sont affichés le libellé de l'élément et l'instruction exécutée.
Le cartouche contient les paramètres de l'instruction et leurs valeurs telles qu'elles sont appliquées dans le StepBuilder.
A droite le reporting d'exécution de l'étape sélectionnée. Cette partie est composée d'un bandeau et de plusieurs cartouches :
Le statut de l'étape de test dans le bandeau.
Le cartouche Initialized Variables liste les variables initialisées au lancement du test.
Le cartouche Internals Variables liste les variables dont la valeur est modifiée au cours de l'exécution du test. Leur valeur est celle au moment de l'exécution de l'étape.
Le cartouche Paramètres liste les paramètres de l'étape et leur valeur après résolution des expressions au moment de l'exécution de l'étape.
L'exemple donné ci-dessus montre le cas d'une résolution d'expression au cours de l'exécution d'un test. La variable $inc a été modifiée lors d'une étape précédente et l'expression ="Jean_"&$inc du paramètre Text a été résolue pour donner Jean_2 juste avant l'exécution de l'étape.
