Glossaire de la recette logicielle

Termes de A à Z

Anomalie

Écart constaté entre le comportement observé d'un logiciel et le comportement attendu. Une anomalie est décrite par ses étapes de reproduction, sa gravité et son statut (ouverte, corrigée, à retester, fermée). On parle aussi de bug ou de défaut.

Cahier de recette

Document qui liste les cas de test à exécuter pour accepter un logiciel, avec les étapes, les données et le résultat attendu de chacun. Voir le guide du cahier de recette.

Campagne de tests

Exécution planifiée d'un ensemble de cas de test sur une version donnée du logiciel, par une ou plusieurs personnes, sur une période définie. Chaque cas reçoit un statut à l'issue de la campagne.

Cas de test

Vérification unitaire décrite par des préconditions, des étapes et un résultat attendu. Un cas de test vérifie une intention précise, par exemple le refus d'un mot de passe erroné.

Critère d'acceptation

Condition mesurable qu'une fonctionnalité doit remplir pour être acceptée par le client. Les critères d'acceptation sont la source naturelle des cas de test.

Environnement de recette

Instance du logiciel, distincte de la production, dans laquelle la recette est réalisée. Elle doit ressembler à la production pour que les résultats soient représentatifs.

Exigence

Besoin qu'une spécification impose au logiciel, par exemple « un mot de passe erroné est refusé ». Une exigence testable se vérifie par un résultat observable.

Gravité d'une anomalie

Niveau d'impact d'une anomalie sur l'usage du logiciel : bloquante (usage impossible), majeure, mineure. À ne pas confondre avec la priorité de correction, qui dépend aussi du calendrier et du contexte.

Jeu de données

Ensemble de valeurs et d'états initiaux (comptes, produits, droits) nécessaires pour exécuter un cas de test de manière reproductible.

MOA (maîtrise d'ouvrage)

Le client, qui porte le besoin et valide la livraison. En recette, la MOA exécute ou fait exécuter les tests métier et signe le PV.

MOE (maîtrise d'œuvre)

Le prestataire qui conçoit et réalise le logiciel. En recette, la MOE livre la version, corrige les anomalies et suit l'avancement.

Matrice de couverture

Tableau qui relie chaque exigence aux cas de test qui la vérifient. Elle fait apparaître les exigences non couvertes. On parle aussi de matrice de traçabilité.

Test de non-régression

Test rejoué après une modification pour vérifier que les fonctions existantes n'ont pas été dégradées.

Plan de test

Document de stratégie : périmètre, types de tests, environnements, ressources et planning. Le cahier de recette en détaille l'exécution.

PV de recette

Procès-verbal signé par le client et le prestataire qui constate le résultat de la recette et prononce l'acceptation, l'acceptation avec réserves ou le refus. Voir le guide du PV de recette.

Recette

Phase de vérification d'un logiciel livré par rapport à la spécification, qui aboutit à son acceptation ou à son refus.

Recette fonctionnelle

Recette qui vérifie que les fonctions du logiciel se comportent comme la spécification le décrit, du point de vue de l'utilisateur. Elle se distingue des tests de performance ou de sécurité.

Recette utilisateur (UAT)

Recette réalisée par les utilisateurs métier du client, en situation réaliste. UAT signifie « User Acceptance Testing ».

Réserve

Anomalie ou écart que le client accepte de voir corrigé après l'acceptation. Elle figure au PV avec son délai de correction, puis est levée une fois corrigée et retestée.

Résultat attendu

Comportement observable qui valide un cas de test. Il doit être assez précis pour que deux testeurs concluent de la même façon.

Test de fumée

Série courte de tests qui vérifie que les fonctions essentielles marchent avant de lancer une recette complète sur une version.

Statuts d'exécution (OK, KO, Bloqué, N/A)

OK : résultat conforme. KO : écart constaté, une anomalie est ouverte. Bloqué : le cas ne peut pas être exécuté. N/A : le cas ne s'applique pas à ce périmètre.

VABF (vérification d'aptitude au bon fonctionnement)

Étape de vérification, prévue dans certains contrats (notamment des marchés publics informatiques), qui contrôle que le système livré fonctionne conformément à ce qui était attendu.

VSR (vérification de service régulier)

Étape qui suit la VABF dans certains contrats : le système est observé dans la durée, en conditions réelles d'exploitation, avant l'acceptation définitive.

Version livrée

Version précise du logiciel remise pour la recette. Le cahier de recette et le PV doivent l'indiquer pour savoir ce qui a été vérifié.