Glossaire ISTQB Fondation

Activité de développement qui consiste à localiser, analyser et corriger les causes des défaillances dans un logiciel.

Imperfection ou défaut dans un élément de travail (comme du code ou des exigences) qui peut conduire à une défaillance lors de son exécution.

Événement physique ou comportement constaté où le système ne réalise pas sa fonction requise dans les limites spécifiées (écart constaté par rapport aux attentes).

Activités axées sur la fourniture de la confiance que les exigences de qualité seront satisfaites. Elle vise à prévenir l'introduction de défauts dans les processus.

Activités opérationnelles visant à vérifier que le produit logiciel répond à ses exigences de qualité (essentiellement les tests).

Éléments de travail produits pendant le processus de test pour planifier, concevoir, exécuter et évaluer les tests (plans, cas de test, scripts, rapports, etc.).

Confirmation par examen et apport de preuves tangibles que les exigences pour un usage spécifique ou une application prévue ont été satisfaites (Est-ce le bon produit ?).

Confirmation par examen et apport de preuves tangibles que les exigences spécifiées ont été satisfaites (Le produit est-il construit conformément aux spécifications ?).

Niveau de test axé sur des modules, classes ou fonctions individuelles, généralement réalisé par les développeur•ses.

Niveau de test axé sur les interactions et les interfaces entre différents composants ou systèmes.

Niveau de test qui évalue le comportement global d'un système complet et intégré, par rapport aux exigences fonctionnelles et non fonctionnelles.

Niveau de test axé sur l'aptitude à l'utilisation par les utilisateur•rices ou le métier afin de prononcer la mise en service.

Type de test basé sur l'évaluation des fonctions que le système doit réaliser (ce que le système fait).

Type de test mesurant les caractéristiques d'un système comme la performance, la sécurité, l'utilisabilité ou la robustesse (comment le système se comporte).

Test visant à vérifier qu'un défaut précédemment détecté et corrigé a réellement été résolu.

Test de non-régression destiné à vérifier que les modifications récentes n'ont pas introduit d'effets secondaires indésirables dans les parties inchangées.

Examen d'un produit d'activité (code, exigences, spécifications) sans exécution du logiciel (revues, analyse statique).

Test qui implique l'exécution physique du logiciel pour en évaluer le comportement.

Processus d'évaluation collaboratif par lequel un document ou un code est examiné par des pairs pour identifier des anomalies et partager la compréhension.

Technique boîte noire divisant les données d'entrée ou de sortie en groupes de valeurs traitées de manière identique par le système.

Technique boîte noire prolongeant les classes d'équivalence en se concentrant sur les frontières de ces classes (valeurs minimales et maximales).

Technique boîte noire modélisant des règles métier complexes sous forme de tableau combinant diverses conditions et actions.

Technique boîte noire testant la capacité d'un système à passer d'un état à un autre suite à un événement précis.

Technique de test basée sur l'analyse de la structure interne du logiciel (code, flux de contrôle, architecture).

Technique de test s'appuyant sur les connaissances, l'intuition et l'historique des pannes passées du•de la testeur•se (ex. test exploratoire).

Document décrivant les objectifs, l'approche, les ressources, le calendrier et les risques liés à une campagne de test.

Conditions requises pour qu'un niveau de test ou une phase puisse officiellement commencer.

Conditions requises pour qu'un niveau de test ou une phase puisse être déclaré terminé.

Risque qu'un produit logiciel ne réponde pas aux besoins ou échoue en production (ex. lenteur, calculs faux).

Risque lié à la gestion et à la réalisation du projet de test lui-même (ex. manque de ressources, retard).

Environnement de test comprenant des stubs (bouchons) et drivers (pilotes) nécessaires pour exécuter des tests unitaires ou d'intégration.