STLC - Le cycle de vie des tests logiciels
29 avril 2018

Licence Creative Commons

Dans le cadre d'un projet de développement logiciel, l'ensemble des activités de test peut être divisé en plusieurs étapes. Comme pour le cycle de vie de développement logiciel (SDLC), il existe également un cycle de vie pour les tests logiciels (STLC).



L'image ci-dessus est une représentation des différentes phases du cycle de vie des tests logiciels.


Phase 1 : Analyse des exigences

Il s'agit de la première étape du cycle. L'équipe de test analyse attentivement les exigences du produit. En cas de conflit, d'omission, d'imprécision ou d'incompréhension, l'équipe de test sera amené à discuter avec les différents acteurs du projet comme par exemple l'analyste fonctionnel ou l'architecte logiciel.


Phase 2 : Planification

Durant cette étape l'équipe de validation planifie l'ensemble des activités de test à travers la rédaction d'un plan de test. La rédaction de ce document sert principalement à déterminer :
  • les objectifs à atteindre.
  • les processus et les méthodes à mettre en place 
  • l'environnement et les outils qui seront utilisés.
  • les éléments à tester ou à ne pas tester.
  • l'organisation de l'équipe et la répartition des tâches.
  • les jalons des différentes activités.
  • les risques qui peuvent survenir.
En plus de la rédaction du plan de test, une estimation des coûts est réalisé pendant cette phase.


Phase 3 : Rédaction des tests.

Un analyste de test rédige les cas de test et vérifie que chaque exigence est couvert par un ou plusieurs tests grâce à une matrice de traçabilité test/exigence.


Phase 4 : Installation de l'environnement de test

Un environnement permettant de tester l'application et de reproduire les anomalies doit être mis à disposition. Sa mise en place est vérifié via l’exécution de smoke test.


Phase 5 : Exécution des tests

Il s'agit tout simplement de l’exécution des tests. Durant cette phase, les testeurs peuvent identifier d’éventuelles anomalies et tester les correctifs des développeurs. En général, l'échec d'un test est associé à un un bug. Des tests de non régression automatisé peuvent être lancés régulièrement.


Phase 6 : Clôture du cycle 

Le logiciel va être déployé. L'équipe de validation se réunit pour analyser les résultats et identifier les choses à améliorer pour les projets avenirs.


* STLC = Software Testing Life Cycle


Références:

Publié par

Rediger un plan de test
22 avril 2018

Licence Creative Commons

Selon l'Institute of Electrical and Electronics Engineers (IEEE), un plan de test est un document qui décrit l'étendue, l'approche, les ressources et la planification des activités prévues. Sa rédaction s'effectue généralement juste après la phase d'analyse des exigences.

Il existe deux types de plan de test :
  • Le plan de test maître qui a pour but de décrire la stratégie de test sur un projet particulier.
  • Le plan de test de phase qui a pour but de décrire de manière détaillé les activités à mettre en œuvre pour chaque niveau de test.

En fonction du contexte, le plan de test maître et le plan de test de phase peuvent former un seul et même document. D'après le standard IEEE 829-2008, ce document peut être structuré comme ci-dessous :

  1. Identifiant
  2. Références
  3. Introduction
  4. Eléments à tester
  5. Fonctionnalités à tester
  6. Fonctionnalités à ne pas tester
  7. Approche stratégique
  8. Critères de succès et d'échec
  9. Reprise et de suspension
  10. Environnement et outils
  11. Rôles et répartition des tâches
  12. Besoins en formation
  13. Planning des activités
  14. Risques et contingences
  15. Livrables
  16. Approbation
  17. Glossaire


01. Identifiant

Il permet d'identifier le document sans ambiguïté. Il s'agit le plus souvent d'un identifiant alphanumérique. Cet identifiant doit être unique. Pour un meilleur suivi des modifications, le plan de test doit contenir un historique de révision avec la date, la description et l'auteur de la modification.


02. Référence

La partie « Références » a pour but de lister les documents qui ont permis la rédaction du plan de test. Il peut s'agir de documents externes ou internes à l'organisation. Le dossier de spécifications fonctionnelles détaillées ou le cahier des charges sont des exemples de document qui peuvent être listé dans cette partie. L'emplacement de chaque document doit être indiqué.


03. Introduction

Il contient les objectifs et un résumé des informations que donnera le plan de test. Cette partie peut également contenir une brève description du produit et une explication du contexte. Le rôle des parties prenante concernés par la rédaction du plan de test doit être évoqué.


04. Eléments à tester

Il s'agit tout simplement de la liste des matériels et des logiciels à tester. Cela correspond à ce qui sera livré avec le produit et non les fonctionnalités fournies par le produit.


05. Fonctionnalités à tester

Cette partie décrit les caractéristiques fonctionnelles et non fonctionnelles qui doivent être testées. Il contient les références aux documents de spécification des exigences.


06. Fonctionnalités à ne pas tester

Ce sont les caractéristiques fonctionnelles et non fonctionnelles qui ne seront pas testées. Dans cette partie, les raisons expliquant pourquoi ces fonctionnalités ne seront pas testées doivent être décrites.


07. Approche stratégique

Il s'agit de la stratégie globale qui sera utilisé pour tester le produit. C'est dans cette partie que seront décrits le processus de gestion des anomalies, les types et les niveaux de test, les dispositifs de suivi et de contrôle des activités de test, etc


08. Critères de succès et d'échec

Cette partie décrit les critères à utiliser pour déterminer si une campagne de test est un échec ou un succès. On peut par exemple considérer qu'une campagne avec 98% de test à l'état réussi et deux bugs cosmétiques est une réussite.


09. Reprise et suspension

Dans cette partie, il faut spécifier les critères à utiliser pour suspendre ou reprendre les activités de test. Il faut également décrire les tâches à réexécuter en cas de reprise.


10. Environnement et outils

Il s'agit de lister les outils et les matériels nécessaires à l'exécution des tests et éventuellement de décrire le fonctionnement de l'infrastructure.


11. Rôles et répartition des tâches

Il faut identifier les tâches nécessaires à la préparation et à l'exécution des tests et indiquer les personnes responsables de chaque tâche.


12. Besoins en formation

Il s'agit de déterminer les compétences et les besoins en formation. Cela peut inclure les formations sur l'utilisation de l'application à tester et des formations sur l'utilisation d'outils et de méthodes.


13. Planning des activités

Il s'agit d'établir un planning pour les différentes activités de test.


14. Risques et contingences

Il s'agit d'identifier les contraintes et les risques important qui peuvent survenir durant l'exécution des activités de test. Il faut définir un plan d'urgence pour chaque risque.


15. Livrables

Il s'agit d'identifier tous les livrables qui seront produits au cours des activités de test, par exemple les cas de test, les rapports d'anomalies, les rapports de test, les fichiers logs.


16. Approbation

Il contient la liste des personnes qui doivent lire et approuver le plan de test. Les approbations doivent être datées et signées.


17. Glossaire

Cette partie doit fournir une définition des termes, des abréviations et des acronymes utilisés dans le plan de test.



Remarque :

Pour la rédaction des plans de test, il existe une autre norme beaucoup plus récente:  ISO/IEC/IEEE 29119-3 (Part 3) - Test Documentation



A lire aussi:

 Références:
Publié par

AUTRES ARTICLES