Editions ENI Livres | Vidéos | e-Formations
Exécution des tests
Objectif
L’objectif de l’exécution des tests est de dérouler les cas de tests préparés pendant la phase en amont de conception et de préparation. Il s’agit de vérifier que le résultat obtenu dans le logiciel ou l’application est conforme au résultat attendu défini dans le cas de test
Lorsque le résultat obtenu est différent du résultat attendu, les écarts sont analysés et, si l’anomalie est avérée, un ticket anomalie doit être créé pour tracer et suivre le traitement de l’anomalie.
La phase d’exécution est une étape clé, attendue par les équipes projet, car c’est à ce moment que l’application est confrontée à la réalité. Les résultats des tests permettent de valider son bon fonctionnement ou de révéler des anomalies. Ces dernières sont ensuite suivies et traitées à l’aide d’outils tels que HP ALM, Jira ou Squash.
Campagne de tests
Préparation
Une campagne de tests est un ensemble de tests, sélectionnés et regroupés pour être exécutés sur une période donnée pour une version de l’application.
Chaque campagne de tests a des exigences en termes d’objectifs et en termes de délai ou de durée. L’objectif d’une campagne de tests peut être :
-
Tester les nouvelles fonctionnalités du logiciel.
-
Tester la non-régression suite à une nouvelle mise à jour ou évolution du logiciel.
-
Tester le bon fonctionnement du logiciel suite à une migration de serveur de données.
En fonction de l’objectif de la campagne de tests, le testeur va venir « piocher » dans le référentiel ou le patrimoine de tests préparés. Les tests à intégrer correspondent à la préparation de la campagne de tests.
Avant de démarrer l’exécution des tests, il faut préparer une campagne de tests.
Des outils de gestion de tests comme HP ALM et Jira Xray permettent de créer et gérer les campagnes de tests et de suivre les résultats des tests.
Le testeur est responsable de la création et de l’organisation de sa campagne de tests, le chef de projet test peut approuver si le périmètre de test est complet et si les priorités...
Gestion des anomalies
1. Objectifs
Nous avons vu dans les chapitres précédents qu’une anomalie est un écart entre un résultat attendu et un résultat obtenu détecté sur les environnements de test. Une anomalie est aussi appelée bug ou défaut, on utilise plus souvent le terme anomalie.
Nous appelons les anomalies détectées en production des incidents.
La gestion des anomalies est une étape importante dans le processus de test et de développement. La bonne gestion du portefeuille des anomalies ou ce qu’on appelle aussi backlog des anomalies doit se faire via une méthodologie et un processus bien défini.
La gestion des anomalies commence depuis la détection de l’anomalie jusqu’à son traitement et sa clôture. Une anomalie demeure active tant qu’elle n’est pas corrigée, validée et clôturée.
C’est pour cela qu’une bonne gestion des anomalies tant sur le plan opérationnel que managérial est un facteur clé pour garantir une bonne qualité des livraisons et un pilotage avec des indicateurs fiables et efficaces.
Hormis le respect des critères d’acceptance et la satisfaction des utilisateurs, qui reste l’objectif final et collectif, une bonne gestion des anomalies permet la détection des actions correctives et aussi préventives dans le cadre d’une amélioration continue des livrables, des processus et des bonnes pratiques de tests et de développement afin de capitaliser d’une livraison à une autre.
Une bonne gestion des anomalies facilite également l’organisation et la priorisation des travaux des testeurs et développeurs et facilite surtout la communication et la collaboration entre ces deux équipes.
2. Processus de traitement des anomalies
Comme évoqué dans la section précédente, la gestion d’une anomalie commence depuis sa détection jusqu’à sa fermeture. Entre les deux états, l’anomalie passe par différentes étapes : c’est ce que l’on appelle le cycle de vie de l’anomalie, en anglais workflow de l’anomalie.
Le cycle de vie d’une anomalie est défini par chaque organisation et formalisé dans la stratégie de tests...
Rapport de tests
Le rapport de tests est l’un des livrables importants de l’activité de tests et spécifique à la phase d’exécution des tests. La fréquence d’envoi du rapport de tests, son contenu et la liste des destinataires sont définis dans la stratégie de communication établie par le projet.
Nous distinguons deux types de rapports de tests : le rapport de tests journalier et le rapport de tests final, établi avant chaque livraison. L’objectif du rapport journalier est de rapporter l’activité de tests en partageant les indicateurs de suivi des tests et des anomalies avec l’ensemble des parties prenantes :
-
le nombre de tests exécutés ;
-
le taux d’échec et de réussite des cas de tests ;
-
le reste à faire en matière d’exécution des tests ;
-
le nombre d’anomalies actives à date, leur sévérité et statut ;
-
les faits marquants et blocages du jour.
Cela permet de suivre au quotidien la courbe d’avancement des tests, de mesurer la vélocité des tests et du traitement des anomalies, de prendre connaissances des alertes et blocages à temps et d’adapter le dispositif en fonction.
Le pilotage des tests est différent du pilotage projet et demande un grand retour d’expérience...
Bilan de test
1. Définition
Le bilan de test est différent du rapport de tests. C’est une sorte de retour d’expérience ou ce qui est désigné sous le terme rétrospective dans le cadre d’une méthode agile. Il est planifié à la fin de chaque campagne pour partager ce qui a bien fonctionné et ce qui a moins fonctionné, dans l’objectif d’améliorer et de capitaliser sur les bonnes pratiques. Tout cela est formalisé dans un document structuré.
Le bilan de test est préparé avec toutes les parties prenantes lors d’un point dédié ou des interviews individuelles. Parmi les techniques utilisées pour animer la réunion, on peut citer le starfish.
2. Méthode de starfish
L’utilisation de la métaphore des starfish (étoiles de mer) dans les rétrospectives est une technique populaire pour structurer la réflexion d’une équipe sur ce qui s’est bien passé, ce qui pourrait être amélioré et sur ce qui pourrait évoluer. Cette méthode est souvent appelée la « starfish retrospective » et consiste à diviser les retours en cinq catégories, chacune représentant un bras de l’étoile de mer. Voici les cinq catégories pour mettre en œuvre cette méthode :...
