Je vais vous présenter ci dessous les choses de base à savoir lorsque l’on se lance dans l’outil ALM HPQC. Cet outil est très prisé des grosses structures car il permet de gérer les specs, les cycles de vie du produit (ses différentes évolutions lors de son développement), les ados. Il permet aussi de faire de beaux graphes de reportons très prisés par le management. Il peut aussi être partiellement utilisé si vous ne voulez utiliser que la partie « gestion des anomalies ».

Clairement dans ce document on ne va pas aller dans les détails les plus obscurs de cet outil. Premièrement car c’est une « usine à gaz ». Il peut faire énormément de choses et on peut vite s’y perdre. Et dans un second temps, car ce n’est pas la vocation de cet article. L’objectif de cet article est le suivant: vous n’avez jamais touché à cet outil et vous devez « produire » rapidement. Vous ouvrez l’outil en me lisant, suivez mes étapes les unes après les autres et vous connaitrez les bases.

C’est pour cela que je présente en mode « recette de cuisine ». Si connaissez déjà un petit peu ALM alors il est probable que ce document vous soit inutile.

1. La première étape consiste à prendre connaissance des specs du projet

Bon jusque là rien de spécial, vous n’avez pas besoin d’ouvrir ALM.

2. Ensuite, il vous faut découper les specs de façon à déterminer plusieurs versions/évolutions du projet.

Ceci dépend de comment vous travaillez sur votre projet (en SCRUM par exemple ou autre). L’idée n’est pas de faire dès le début un découpage fonctionnel de l’ensemble de votre projet mais de prévoir les jalons de votre projet, avoir une idée de quelles fonctionnalités sont prévues et sur quel jalon/version du projet. Evidemment on est à ce moment là à une estimation à grande maille. Dans tout projet on comment par prévoir un besoin métier général, puis dans un premier temps on le découpe en grande fonctions et au fur et à mesure que le projet avance et que l’on avance dans nos versions on affine tout cela et ajoutant/enlevant des besoins et donc des specs. Chaque version de votre projet correspondra sur HP QC à une Release.

3. Comment gère-t-on les Releases dans HPQC ?

a) On créé nos différentes Releases (Menu Management à gauche)

b) On découpe chaque Release en Cycles. Chaque Cycle correspond à une étape/step du Plan de Test. (Ce sera développé en partie 6)

Release : Couvre un ensemble d’exigence à satisfaire. Version d’une app à livrer par exemple.

Cycle : Partie d’une release. Il couvrent soit les niveaux de test (Unitaire, intégration..) soit les phases de test (Nlle fonctionnalité, Non-Régression..)

c) Ensuite on va créér les Requirements*. Ils contiennent les fonctionnalités à mettre en place puis à tester . Ceci lors des différents Releases et Cycles. Ils peuvent être soit créés directement dans HPQC soit importés (à partir d’un doc Excel par exemple).

Principaux types d’exigence : Fonctionnel/Métiers, Technique/Environnements, Performances/Robustesse, Ergonomiques…

d) Les requirements ne pouvant pas être tous faits en même temps, il faut les ordonner dans le temps. Ainsi on va positionner leur développement sur les différents Release et Cycle de la vie du projet. (Dans le logiciel, et dans le détail de chaque Requirement, on remplit les champs « Target Release » et « Target Cycle »).

e) On va ensuite estimer le risque de test pour chaque Requirement et l’indiquer dans le logiciel dans la rubrique « Risk Quality Management » (criticité métier et probabilité d’échec).

Cela permet de gérer l’attribution des ressources selon le risque. Pour cela on commence par sélectionner un Requirement.

 

 

f) Une fois fait, on peut voir la prédiction proposée par HPQC en terme de risque/complexité (de 1 à 3, 1 étant le plus complexe) et sa prédiction de temps de test nécessaire.

g) On remplit le champ correspondant le temps que l’on attribut au Requirement.

h) On clique sur le bouton [Analyse and apply to children]

i) On va consulter les résultats pour chaque Requirement dans l’onglet « Risk Assessment » et sous-onglet « Assessment Result ».

4. Convertir les Requirements en cas de test

Tout d’abord notons que cela permet de dupliquer l’arborescence des requirements dans la partie Test Plan.

– Clic droit sur le dossier des requirements à convertir

– Clic sur « Convert to test »

– On sélectionne la 3ème option proposée : « convert all requirements to subjects »

– On choisit l’emplacement de destination : un dossier créé à l’avance dans le module « Test Plan » (qui contiendra l’ensemble des cas de test et qui portera le nom du projet par exemple)

– On clique sur le bouton [Finish]

A noter que les cas de test peuvent être importer depuis Excel par exemple.

5. Construction du Test plan

Le Test Plan qui permet la gestion des cas de test que l’on vient de créer.

a) On ouvre l’arborescence que l’on vient de créer à partir des Requirements.

b) On créé, dans chaque dossier correspondant à un Requirement un ou plusieurs cas de test.

c) On associe les cas de tests aux Requirements dans l’onglet « Req coverage » + bouton [req coverage]

d) On crée les Steps d’un cas de test que l’on vient de produire.

Ce sont les différentes étapes à valider. On y voit l’action à réaliser et le résultat attendu.

 

 

Si besoin, on peut utiliser plusieurs configurations à chaque Step. NB : Pour chaque Step on peut associer un ou plusieurs paramètres définis à l’avance dans l’onglet « Parameters ». Il suffit ensuite de les insérer dans les steps selon le besoin. Cela donne des choses comme ceci :

– Sélectionner << Paramètre #1 >>
– Vérifier l’affichage de << Paramètre #2 >>

Dans HPQC, << Paramètre #1>> et <<Paramètres #2>> seront remplacés par leurs valeurs définies à l’avance.

e) On définit les différentes configurations qui seront utilisées dans les cas de test.

6. Organisation des campagnes et scénarios de test

Une fois que l’on a créé plusieurs cas de test, on va pouvoir les organiser en campagnes. Ceci se fait dans la partie Test Lab de HPQC.

a) On créé un dossier à la base de l’arborescence

b) On lie ce dossier à un Cycle avec « assign to cycle ». Une fois fait, on voit le symbole des Cycles s’afficher sur le symbole du dossier.

c) On créé un scénario avec « New Test Set »

d) On ajoute des cas de test (créés en parte 4/) au scénario que l’on vient de créer.

Pour cela on se positionne sur notre scénario. On clique sur l’onglet « Execution Grid ». Puis « Test Plan Tree » (sur la droite) et on choisir les cas de tests (et leurs différentes configurations) à ajouter.

7. Exécution manuelle de notre scénario de test

Une fois le scénario créé on va pouvoir l’exécuter manuellement (A noter qu’il est possible de configurer un scénario automatique RobotFRamework ou autre).

a) On se positionne sur le scénario

b) On va sur l’onglet « Execution Grid »

c) On clique sur « Run test set » pour que les cas de test s’exécutent les uns après les autres ou sur « Run » pour que le lancement se fasse à la main pour chaque cas de test.

d) Les tests lancés, on complète les champs :

– Expected est le résultat attendu

– Actuel est le résultat visible (si différent de Expected, il y a de fortes chances que la partie testée soit KO)

– On valide ou pas le step avec les boutons du haut « Pass selected « ou « Fail Selected »

– Dans le cas où le test serait KO, on clique après sur le bouton « New Defect » pour créer une anomalie (cf après)

– Une fois l’exécution du cas de test finie, on clos en cliquant sur « End Run » (un carré bleu)

8. Les anomalies :

On vient de voir dans l’étape précédente comment et quand créer une anomalie. Il suffit de remplir les différents champs proposés, rajouter ou pas une pièce jointe… L’anomalie que l’ont vient de créer peut être liée à une autre que l’on aurait crée plus tôt. Il faut dans ce cas le signaler en les liants entre elles.

a) Dans le module « Defects » de la colonne de gauche

b) On sélectionne notre anomalie à lier

c) On clique sur l’onglet (menu du bas) « Linked Entities »

d) Puis sur le sous onglet « Defects »

e) Puis on déroule le bouton-menu « Link Defect Entities »

f) On choisit l’anomalie à rattacher selon les infos que l’on a sur elle. Une fois que l’on est sur une anomalie, on peut chercher les anomalies liées ou les
anomalies similaires (pas forcément liées) avec le bouton-menu « Find similar Defects » (en haut).

 

© Romain GRANIER | Consultant & expert Klanik