Editions ENI Livres | Vidéos | e-Formations
Introduction aux tests
Définition des tests
Le test est un ensemble d’étapes permettant de vérifier qu’un logiciel répond aux exigences fonctionnelles et non fonctionnelles du client.
Tester c’est vérifier que le résultat obtenu est conforme au résultat attendu, mais pas seulement : les tests doivent aussi permettre d’améliorer l’ergonomie de l’application c’est ce qu’on appelle de nos jours l’UX (User eXperience).
Un test peut être manuel ou automatique. Il existe plusieurs niveaux et types de tests que nous détaillerons dans la section Niveaux et types de test.
Notons qu’il faut tout tester :
-
composants ;
-
services ;
-
applications IHM ;
-
processus métier ;
-
habilitations ;
-
interfaces ;
-
flux ;
-
batches ;
-
initialisation des données ;
-
migration des données ;
-
procédures d’exploitation ;
-
processus de mise en service.
Attention, il faut aussi savoir s’arrêter.
Objectif des tests
Un projet informatique est un ensemble de processus, de tâches et de livrables associés.
Les tests permettent de maîtriser les risques liés aux défaillances d’un projet et donc de bien en garantir le bon fonctionnement.
Lorsque le testeur teste une application, il cherche à trouver le maximum de défauts. Et plus il en trouve, plus la satisfaction augmente. Mais tester dans le seul but de trouver des défauts ne suffit pas, il faut aussi tester pour s’assurer que le produit est fonctionnel et répond aux exigences du client.
Vous bâtissez la confiance de vos clients progressivement tout au long du cycle de réalisation du projet. Grâce aux tests vous éliminez le risque lié à l’incertitude et abordez sereinement la réception.
Et en termes de coût, le projet est gagnant : la non-qualité et le désordre coûtent très cher. Ce ne sont pas que des dires, mais l’expérience l’a largement démontré. Plus tôt un défaut ou une anomalie est détecté, moins cher coûtera sa correction.
On teste tout, certes, mais il faut savoir quand s’arrêter car la surqualité peut également engendrer des coûts.
Nous constatons encore, sur des projets, l’absence de la phase de tests qui fait partie des fondamentaux encore dépriorisés...
Niveaux et types de tests
1. Définition
Un niveau de test est un ensemble d’activités de tests gérées et organisées par phases.
Chaque phase de tests comprend des objectifs et types de tests à dérouler, des critères d’entrée et de sortie, un environnement concerné, un porteur et des livrables associés.
Le nombre et types de phases de tests identifiées pour un projet dépendent du processus, du cycle de développement utilisés ainsi que de la taille du projet.
Dans le syllabus de l’ISTQB (International Software Testing Qualifications Board) sont identifiées quatre phases de tests :
-
tests de composants ;
-
tests d’intégration ;
-
test système ;
-
tests d’acceptation.
Les types de tests représentent quant à eux des catégories de tests.
Selon l’ISTQB, un type de test est un groupe d’activités de test dont l’objectif est de tester un composant ou un système sur un ou plusieurs attributs liés entre eux. Un type de test est focalisé sur un objectif de test spécifique (ex. : test de fiabilité, d’utilisabilité, de régression, etc.) et peut couvrir un ou plusieurs niveaux de test et une ou plusieurs phases de test (d’après TMap -Test Management Approch).
En fonction des types de tests, les exigences fonctionnelles et non fonctionnelles sont vérifiées.
2. Types de tests non fonctionnels
Si les phases de tests sont basées sur un enchaînement séquentiel et temporel, les types de tests eux, sont orientés objectif et peuvent être déroulés dans plusieurs phases de tests. Ci-dessous, les types de tests permettant de couvrir des exigences non fonctionnelles.
Test de performance
Il s’agit d’un test démontrant que l’application respecte les contraintes de performance requises telles que le temps de réponse et la tenue à la charge.
Test de robustesse
Il s’agit d’un test démontrant la résistance de l’application aux erreurs des utilisateurs, aux incidents et au stress.
Test...
Les tests dans le cycle de développement en V
1. Définition
Le cycle en V est un modèle traditionnel de gestion de projet lié au développement logiciel. Les étapes du processus de développement sont organisées en une structure séquentielle où chaque étape de la phase d’expression de besoin en termes de spécification ou de conception correspond à une phase de test ou de validation.
Comme l’illustre l’image ci-dessus, le cycle en V se compose d’une partie gauche pour l’évolution des étapes de conception et d’une partie droite pour l’évolution des états.
La partie gauche représente les étapes de consolidation des besoins et la construction des spécifications et la partie de droite les phases de tests.
2. Les étapes du cycle en V
Voici les étapes principales du cycle en V et les activités de test associées.
a. Définition des exigences
L’objectif de cette étape est de recueillir les besoins fonctionnels et non fonctionnels du client. Le document qui décrit les exigences métier est le cahier des charges.
Les tests associés sont les tests de réception appelés aussi les tests d’acceptation utilisateur. Ces tests sont menés par les utilisateurs pour vérifier que le logiciel répond à leurs attentes en se basant sur des scénarios liés à des cas d’utilisation réels.
b. Conception fonctionnelle
L’objectif de cette étape est d’analyser les exigences métier et les décliner en fonctionnalités. Ces fonctionnalités sont ensuite décrites dans un document de spécifications fonctionnelles détaillées. L’équipe en charge de rédiger les spécifications fonctionnelles est l’équipe des business analysts.
La phase de tests associée est la phase de tests de validation. Ces tests permettent de s’assurer que chaque fonctionnalité est bien implémentée conformément aux spécifications fonctionnelles. Ces tests sont menés par les testeurs en se basant sur les scénarios de test préparés en amont, pour couvrir les fonctionnalités et les règles de gestion...
Les tests de non-régression
1. Objectif
L’approche de non-régression est utilisée principalement dans le domaine de développement logiciel. L’objectif étant de vérifier que les modifications ou les évolutions apportées à un logiciel n’impactent pas les fonctionnalités déjà existantes.
On parle d’une régression pendant les tests lorsqu’un test qui était concluant lors d’une campagne antérieure ne l’est plus dans une autre campagne. L’anomalie identifiée dans ce cas est taguée comme étant une régression.
Les tests de non-régression sont la réitération sélective de tests pour vérifier que les modifications n’ont pas provoqué de dégradation du fonctionnement du système par rapport à la version précédente et que le système modifié satisfait toujours aux exigences spécifiées. On entend par modification toute modification dans le code des développeurs ou dans les données et la configuration de l’environnement.
Beaucoup d’incertitudes se posent quant à la pertinence et la complétude des tests sélectionnés pour la non-régression.
Pour cette raison, la profondeur des tests et la liste des scénarios à rejouer pour chaque...
