Comprenez l’intérêt des tests
À quoi ça sert de tester ?
On pense souvent qu’on teste un produit pour détecter des anomalies. Cela est vrai en partie, mais c’est réducteur. L’objectif des tests est beaucoup plus large.
Ils consistent à :
évaluer un produit, c’est-à-dire donner de l’information sur un niveau de qualité ;
vérifier la conformité du produit aux exigences, spécifications ou User Stories, c’est-à-dire donner de l’information sur un niveau de complétude ;
prévenir les défauts ;
construire la confiance dans le niveau de qualité du logiciel ;
réduire les coûts : cela coûte moins cher de corriger au plus tôt ;
assurer la satisfaction client car si un logiciel arrive en production avec plusieurs anomalies, les utilisateurs ne seront pas satisfaits et risquent de ne plus utiliser ce produit même si ces anomalies sont corrigées par la suite.
D’une manière plus générale, le test désigne toutes les activités qui consistent à rechercher des informations quant à la qualité du système afin de permettre la prise de décisions.
Voici les sept principes généraux du test à avoir à l’esprit :
Les tests montrent la présence de défauts, mais ils ne peuvent pas garantir l’absence de défauts.
Les tests exhaustifs sont impossibles. On aura beau faire tous les tests qu’on imagine, il y en aura toujours auxquels on n’aura pas pensé.
Tester au plus tôt.
Le regroupement de défauts. Cela peut sembler étonnant, mais bien souvent, quand il y a une anomalie sur une fonctionnalité, alors il y a de fortes chances d’en trouver d’autres à proximité.
Le paradoxe du pesticide.
Les tests dépendent du contexte. On ne testera pas de la même façon une application bancaire avec des exigences élevées de sécurité qu’une application pour consulter la météo.
L’illusion d’absence d’erreur. Il est important de comprendre que l'absence apparente d'erreurs lors des tests ne garantit pas l'absence réelle d'erreurs. Il est possible que les tests effectués ne couvrent pas tous les scénarios possibles.
À titre d’exemple, il ne sert à rien de multiplier les tests sur Chrome si l’ensemble des utilisateurs utilise Firefox pour des raisons de politique d’entreprise !
Au-delà de ces principes, j’ajouterais que bien tester c’est aussi savoir quand arrêter de tester. 😉
Passons maintenant aux niveaux de test.
Identifiez les niveaux de test
D’après l’ISTQB (International Software Testing Qualifications Board), les niveaux de test sont les suivants :
les tests unitaires ou tests de composants :
ils sont effectués par les développeurs ;
le développeur vérifie son code au niveau du composant qu’il doit réaliser ;
il vérifie que chaque “brique” est correcte et répond aux spécifications.
les tests d’intégrations :
ils peuvent être effectués par les développeurs ou les testeurs ;
ils permettent de s’assurer que plusieurs composants du système interagissent entre eux conformément aux spécifications (Est-ce que les composants communiquent bien entre eux ?).
les tests système :
ils sont effectués par les testeurs ;
ils vérifient la conformité aux spécifications au niveau système, c’est-à-dire une fois que toutes les briques sont assemblées.
les tests d’acceptation :
ils sont effectués par les testeurs et par le PO ou le client ;
ils vérifient la conformité au besoin pour les utilisateurs finaux (conformité à l’attendu client).
Voici une analogie pour bien comprendre ces différents niveaux de test :
Prenons un client qui souhaite un mur de 2 m × 5 m.
Les ouvriers (développeurs) vont construire les briques. Il faudra vérifier qu’elles sont de la bonne taille. Cela correspond aux tests composants (ou unitaires).
Ensuite ils vont assembler les briques deux à deux. Il faudra s’assurer qu’elles s’emboîtent comme il faut. Cela correspond aux tests d’intégrations.
Puis ils vont construire le mur. Il faudra vérifier qu’il fait bien 2 m × 5 m (spécifications du client). Cela correspond aux tests système.
Et enfin, le client va venir contrôler le mur. Là, le client n’est pas satisfait du résultat. Il ne voulait pas un mur en brique mais un mur en pierre !
Cette analogie vous permet de bien identifier les différents niveaux de test et de comprendre l’objectif de chacun. Elle permet également de vous montrer qu’avant d’entamer un développement, il faut bien comprendre le besoin final et que les spécifications soient rédigées en conséquence.
Maintenant que vous avez vu les niveaux de test, nous allons passer aux types de tests pour bien comprendre la différence entre ces deux terminologies.
Identifiez les types de tests
D’après l’ISTQB, la définition des types de tests est celle-ci :
Les tests sont classés en deux grandes catégories :
les tests fonctionnels ;
les tests non fonctionnels.
Les tests fonctionnels concernent les tests des fonctionnalités d’un produit. Cela permet de valider que le produit fonctionne correctement et répond au besoin.
Les tests non fonctionnels concernent les tests de :
robustesse : pour s’assurer que le site respecte les critères de robustesse, comme tant de requêtes en tant de temps. Par exemple, simuler un pic d’utilisateurs sur un temps très court ;
performance : temps de réponse de chargement d’une page d’un site web par exemple ;
montée en charge : augmenter progressivement le nombre de requêtes sur un site web pour vérifier à quel moment celui-ci ne supporte plus la charge ;
compatibilité : est-ce que le logiciel fonctionne sous Windows et sous Mac OS ? ;
ergonomie et utilisabilité : est-ce que le site est facilement utilisable aussi bien sur téléphone que tablette, ordinateur ou télévision ? ;
sécurité : pour s’assurer que des hackeurs ne pourront pas récupérer ou utiliser les données utilisateurs.
Les tests non fonctionnels visent à évaluer les aspects implicites d’un produit conformément aux attentes des clients, même s’ils ne sont pas nécessairement explicitement mentionnés dans les spécifications.
À vous de jouer
Dans le domaine du test logiciel, il existe deux grandes catégories de tests : les tests fonctionnels et les tests non fonctionnels.
Voici une liste de tests. Classez les tests suivants selon les deux catégories.
Vérifier que le système offre une bonne performance et une bonne réactivité.
Vérifier que le formulaire de contact envoie un email au destinataire choisi.
Vérifier que le système répond aux exigences du cahier des charges.
Vérifier que le système respecte les règles métier et les scénarios d’utilisation.
Vérifier que le système est compatible avec les différents navigateurs, systèmes d’exploitation et appareils.
Vérifier que le système affiche les messages d’erreur appropriés en cas d’anomalie.
Vérifier que le système affiche un message d’erreur si l’utilisateur entre un mot de passe incorrect.
Vérifier que le système est robuste et stable face aux pannes et aux interruptions.
Vérifier que le système est évolutif et maintenable.
Vérifier que le temps de chargement d’une page web ne dépasse pas 3 secondes.
Vérifier que le système peut supporter 1 000 utilisateurs simultanés sans ralentissement.
Vérifier que le système gère correctement les entrées et les sorties de données.
Triez vos tests sous forme d’un tableau. Une colonne par catégorie de tests.
En résumé
Les tests ne se limitent pas à trouver des anomalies. Ils ont aussi pour objectifs d'évaluer un produit, prévenir des défauts, construire la confiance en la qualité logiciel, réduire les coûts, assurer la satisfaction client.
Les niveaux de test permettent de comprendre le découpage des tests à chaque niveau et par qui ils sont réalisés.
Les niveaux de test sont les tests unitaires, intégration, système et les tests d'acceptation.
Les tests sont classés en deux types de test : les tests fonctionnels et les tests non-fonctionnels.
Les types de tests indiquent les différentes manières de tester un produit.
Maintenant que vous en savez plus sur les tests, attachons-nous à la posture du testeur et à ses qualités.
