Analyse des valeurs limites (AVL)

Technique de test boîte noire consistant à tester les valeurs aux frontières des partitions d'équivalence, c'est-à-dire les valeurs juste en dessous, sur, et juste au-dessus des limites. Elle permet de détecter des défauts fréquents aux bornes des plages de valeurs.

Pour un transfert bancaire autorisé entre 10 € et 10 000 €, l'AVL conduit à tester les valeurs 9 €, 10 €, 10 000 € et 10 001 €.

ATDD (Acceptance Test-Driven Development)

Approche de développement piloté par les tests d'acceptation dans laquelle les critères d'acceptation sont définis collaborativement avant le développement et servent de base à la création des tests. Elle implique développeurs, testeurs et représentants métier.

Dans un projet Agile, l'équipe utilise l'ATDD pour rédiger des scénarios Given/When/Then avant de coder la fonctionnalité de connexion utilisateur.

Couverture des branches

Métrique de test boîte blanche mesurant le pourcentage de branches (issues de conditions vraie/fausse) d'un programme qui ont été exécutées par les cas de test. Une couverture à 100 % exige que chaque résultat possible de chaque condition soit testé.

Une fonction contenant deux conditions indépendantes possède quatre branches distinctes à couvrir pour atteindre 100 % de couverture des branches.

Couverture des instructions

Métrique de test boîte blanche mesurant le pourcentage d'instructions exécutables d'un programme qui ont été traversées lors de l'exécution des tests. Elle constitue le niveau minimal de couverture structurelle.

Pour atteindre 100 % de couverture des instructions dans une fonction contenant dix lignes exécutables, au moins un cas de test doit parcourir chacune de ces lignes.

Critères d'entrée

Conditions préalables devant être satisfaites avant qu'une activité de test puisse démarrer, garantissant que l'environnement et les livrables nécessaires sont disponibles. Ils sont opposés aux critères de sortie qui définissent les conditions de fin d'activité.

L'existence d'exigences approuvées et d'un environnement de test opérationnel constituent des critères d'entrée typiques avant le début des tests système.

Critères de sortie

Conditions devant être remplies pour qu'une activité de test soit considérée comme terminée, utilisées pour décider si le niveau de test en cours peut être clôturé. Ils peuvent inclure des seuils de couverture ou des taux de défauts résiduels acceptables.

L'exécution complète de tous les cas de test de non-régression prévus constitue un critère de sortie typique pour la phase de test système.

Défaillance

Manifestation observable d'un défaut lors de l'exécution du logiciel, se traduisant par un comportement du système différent du résultat attendu. Elle est la conséquence visible d'un défaut introduit par une erreur humaine.

Lorsqu'un utilisateur saisit un montant valide et que l'application affiche un message d'erreur incorrect, il s'agit d'une défaillance causée par un défaut dans le code de validation.

Défaut

Imperfection ou anomalie présente dans un produit logiciel, résultant d'une erreur humaine, qui peut provoquer une défaillance lors de l'exécution. Il est aussi désigné par les termes bug ou anomalie dans la littérature technique.

Un opérateur de comparaison incorrect dans une condition de calcul de remise constitue un défaut susceptible de provoquer des résultats financiers erronés.

Équipe intégrée

Approche organisationnelle Agile dans laquelle les testeurs sont intégrés directement au sein de l'équipe de développement plutôt que dans une équipe de test séparée. Elle favorise la collaboration, le partage de responsabilités qualité et un retour rapide.

Dans une équipe Scrum appliquant l'approche équipe intégrée, le testeur participe aux cérémonies et collabore quotidiennement avec les développeurs dès la phase de conception des User Stories.

Erreur

Action humaine produisant un résultat incorrect, qui peut conduire à l'introduction d'un défaut dans un produit logiciel ou sa documentation. L'erreur est la cause originelle, distincte du défaut qu'elle génère et de la défaillance qui peut en résulter.

Un développeur qui interprète incorrectement une règle métier et code une mauvaise formule de calcul commet une erreur, introduisant ainsi un défaut dans le logiciel.

Estimation à trois points

Technique d'estimation de l'effort de test basée sur trois scénarios — optimiste, le plus probable et pessimiste — combinés selon la formule (O + 4×P + Pe) ÷ 6 pour produire une estimation pondérée. Elle permet de réduire l'incertitude inhérente aux estimations uniques.

Avec des estimations optimiste de 6 jours, la plus probable de 15 jours et pessimiste de 24 jours, l'estimation à trois points donne (6 + 60 + 24) ÷ 6 = 15 jours.

Gestion de configuration

Discipline consistant à identifier, contrôler et suivre les versions des éléments de configuration (code, testware, environnements) tout au long du cycle de vie du logiciel. Elle garantit la traçabilité et la reproductibilité des activités de test sur des versions précises.

Lorsque plusieurs versions d'un logiciel sont testées en parallèle, la gestion de configuration assure que chaque rapport de défaut est associé à la version exacte du produit concernée.

Inspection

Type de revue formelle et structurée, le plus rigoureux, conduit par un modérateur formé et suivant un processus défini avec des critères d'entrée et de sortie explicites. Elle vise à détecter le maximum de défauts grâce à une préparation individuelle approfondie et une réunion de revue encadrée.

L'équipe qualité applique une inspection sur le document d'architecture avant le début du développement, en suivant un processus formalisé avec rôles assignés et liste de contrôle dédiée.

Partitionnement en classes d'équivalence (EP)

Technique de test boîte noire divisant les données d'entrée en partitions au sein desquelles tous les éléments sont supposés être traités de manière identique par le logiciel. Un seul représentant par partition suffit théoriquement à couvrir l'ensemble des valeurs de cette classe.

Pour un champ de mot de passe acceptant 8 à 12 caractères, on définit au moins trois partitions : longueur valide, longueur trop courte et longueur trop longue, nécessitant un cas de test par partition.

Quadrants de test agile

Modèle organisant les types de tests selon deux axes : d'une part l'orientation technologique ou métier, d'autre part le soutien à l'équipe ou la critique du produit. Il aide les équipes à équilibrer les différents types de tests à chaque itération.

Les tests unitaires automatisés se situent dans le quadrant Q1 (technologique, soutien à l'équipe), tandis que les tests d'accessibilité se placent dans le quadrant orienté métier et critique du produit.

Rapport de défaut

Document enregistrant les informations relatives à un défaut détecté, incluant les étapes de reproduction, les résultats obtenus et attendus, la version du logiciel concernée et la sévérité. Il constitue le support formel de communication entre testeurs et développeurs pour la correction.

Un rapport de défaut incomplet omettant le résultat attendu empêche les développeurs de comprendre le comportement correct souhaité et ralentit la résolution.

Rétrospective

Cérémonie Agile tenue à la fin d'une itération permettant à l'équipe d'analyser son fonctionnement, d'identifier des problèmes de processus et de définir des actions d'amélioration concrètes. Elle est un mécanisme clé d'amélioration continue du processus de test.

Lors d'une rétrospective, l'équipe identifie que les testeurs reçoivent les User Stories trop tard et décide d'impliquer les testeurs dès la phase de raffinement du backlog pour y remédier.

Revue informelle

Type de revue ne suivant pas de processus défini ni de critères formels, réalisée de manière ad hoc sans rôles strictement assignés ni documentation obligatoire. Elle offre un retour rapide à faible coût mais avec une rigueur moindre qu'une revue structurée.

Un développeur demande à un collègue de relire rapidement son code avant de le soumettre sans utiliser de liste de contrôle formelle, ce qui constitue une revue informelle.

TDD (Test-Driven Development)

Approche de développement piloté par les tests dans laquelle les tests unitaires sont écrits avant le code de production, guidant ainsi la conception et l'implémentation. Le cycle suit la séquence : écrire un test en échec, implémenter le code minimal, refactoriser.

Un développeur appliquant le TDD rédige d'abord un test unitaire vérifiant le calcul d'une remise avant d'écrire la fonction correspondante dans le code source.

Test basé sur les checklists

Technique de test basée sur l'expérience utilisant des listes prédéfinies d'éléments à vérifier pour structurer et guider l'exécution des tests. Elle aide à éviter les oublis sans pour autant garantir une couverture exhaustive.

Un testeur utilise une checklist de critères d'accessibilité pour s'assurer que chaque écran de l'application respecte les exigences réglementaires sans avoir à mémoriser chaque point de contrôle.

Test de confirmation

Type de test exécuté après correction d'un défaut pour vérifier que ce défaut spécifique a bien été résolu et que le logiciel se comporte désormais conformément aux attentes. Il cible uniquement le défaut corrigé, contrairement au test de régression qui couvre l'ensemble du système.

Après correction d'un bug de calcul de TVA, le testeur exécute un test de confirmation reproduisant exactement le scénario qui avait initialement révélé le défaut.

Test de régression

Type de test visant à vérifier qu'une modification du logiciel (correction, nouvelle fonctionnalité, refactorisation) n'a pas introduit de nouvelles défaillances dans les fonctionnalités précédemment opérationnelles. Il est particulièrement adapté à l'automatisation dans les contextes d'intégration continue.

Après l'ajout d'un nouveau module de paiement, l'équipe exécute l'ensemble de la suite de tests de régression automatisée pour s'assurer que les fonctionnalités existantes restent opérationnelles.

Test exploratoire

Technique de test basée sur l'expérience dans laquelle la conception, l'exécution et l'apprentissage des tests se déroulent simultanément et de manière interactive, sans script prédéfini. Elle est particulièrement adaptée aux contextes où la documentation est limitée ou le temps contraint.

Face à une nouvelle application sans documentation détaillée et sous délai serré, le testeur adopte une approche exploratoire pour découvrir et documenter simultanément le comportement du système.

Tests par tables de décision

Technique de test boîte noire utilisant une table structurant toutes les combinaisons de conditions d'entrée et leurs actions ou résultats correspondants pour dériver des cas de test. Elle est particulièrement efficace pour tester des règles métier complexes avec de multiples conditions interdépendantes.

Pour un système de fidélité combinant le statut d'abonnement, l'âge et la possession d'un certificat, une table de décision permet d'identifier des combinaisons de conditions impossibles et de s'assurer que toutes les règles métier sont couvertes.

Traçabilité

Capacité à établir et maintenir des liens entre les exigences, les cas de test, les défauts et les résultats de test tout au long du cycle de vie du projet. Elle permet de vérifier la couverture de test complète et de mesurer l'impact des changements d'exigences.

Grâce à la traçabilité bidirectionnelle, le responsable de test peut démontrer aux parties prenantes que chaque exigence fonctionnelle est couverte par au moins un cas de test exécuté.