Ces quatre termes sont souvent mélangés, créant des attentes différentes quant à la portée et des différends sur la formulation. Se mettre d’accord sur une signification partagée en équipe compte plus dans la pratique que débattre de la définition correcte d’un manuel.
Tests smoke
Les tests smoke vérifient rapidement que le système fonctionne globalement et permet de poursuivre les tests ou l’utilisation. Ils couvrent généralement les parcours nominaux les plus critiques : démarrage, connexion, navigation de base, création d’une entité principale et disponibilité essentielle des API.
Tests sanity
Les tests sanity vérifient de façon ciblée une modification ou un problème précis. Après une petite modification du calcul d’une remise, par exemple, l’équipe contrôle les scénarios associés et les fonctions voisines plutôt que tout le produit.
Tests de régression
Les tests de régression revérifient les fonctions existantes pour confirmer que les modifications n’ont pas dégradé leur comportement. Leur périmètre est généralement plus large que celui des tests smoke ou sanity et dépend des risques connus du produit.
Tests de confirmation (retest)
Le retest, ou test de confirmation, vérifie un défaut précis après correction : le bug est-il résolu dans son scénario d’origine ? Il ne remplace pas la régression, car il ne vérifie pas les autres fonctions potentiellement affectées.
Distinctions pratiques
- →Smoke : ce build permet-il de poursuivre les tests ?
- →Sanity : la zone concernée se comporte-t-elle toujours comme prévu après une modification locale ?
- →Retest : ce défaut précis a-t-il été corrigé ?
- →Régression : les modifications ont-elles affecté d'autres fonctionnalités ?
Conseils pratiques
- →Documentez un vocabulaire d'équipe partagé afin que tout le monde comprenne la portée de manière cohérente.
- →Construisez des tests de régression autour du risque plutôt que d’une sélection arbitraire d’anciens cas.
- →Ne considérez pas le retest seul comme une preuve suffisante pour livrer lorsque la modification affecte des fonctions dépendantes.
Choisir selon l’objectif : une livraison corrigeant une remise
Exigence fictive DISC-1 : appliquer une remise 10 % lorsque le sous-total des marchandises est d'au moins 10000 cents. Un défaut signalé utilisait > au lieu de >=, donc un panier d'un montant de 10000 ne bénéficiait d'aucune réduction. Tous les montants ci-dessous donnent des résultats en centimes entiers ; d'autres montants nécessitent une règle d'arrondi explicite. La version modifie ce comparateur dans une fonction de calcul de total partagée.
Vérification Objectif Déclencheur Périmètre Exemple
Smoke Le build permet-il de poursuivre les tests ? Nouveau déploiement Petit ensemble couvrant les fonctions critiques L’application s’ouvre, la connexion fonctionne, le catalogue charge, le paiement s’ouvre
Sanity (convention de cette équipe) La zone modifiée se comporte-t-elle de façon cohérente ? Petit correctif ciblé Zone concernée et fonctions voisines Les sous-totaux 9900 / 10000 / 10100 donnent 9900 / 9000 / 9090
Retest / confirmation Le défaut signalé a-t-il été corrigé ? Correctif d’un problème connu Reproduction initiale et résultat attendu Le même panier de 10000 centimes donne maintenant 9000
Régression La modification a-t-elle dégradé le comportement existant ? Modification ayant un impact potentiel Fonctions liées et dépendantes choisies selon les risques Commandes enregistrées, factures et calculs de remboursement correspondent toujours aux résultats approuvésUne livraison, quatre questions distinctes
Exécutez d’abord les tests smoke de l’environnement. Si le paiement ne s’ouvre pas, signalez un blocage : un déploiement défaillant ne prouve pas que la correction du comparateur est erronée. Reproduisez ensuite exactement le défaut sur le nouveau build, avec le même compte, la même devise et la même entrée : 10000 doit donner 9000. C’est le test de confirmation. Vérifiez ensuite les valeurs voisines 9900 et 10100 avec l’ensemble ciblé ; l’équipe peut appeler cela des tests sanity.
Pour la régression, inspectez les appels au calcul partagé avant de choisir les tests. Incluez les totaux des commandes enregistrées, des factures et tout parcours de remboursement qui appelle réellement la fonction. Comparez chaque résultat à une valeur attendue convenue et enregistrée selon ses propres règles ; ne supposez pas qu’un remboursement vaut automatiquement 90% ni que tous les appelants suivent DISC-1. Ajoutez comme témoin un panier sans remise auparavant valide. L’étendue des tests dépend des dépendances et des risques métier constatés, pas d’un nombre fixe de tests.
Une petite démonstration exécutable
Enregistrez le code dans release_check_selection.py et exécutez python3 release_check_selection.py. Sortie attendue : Known defect reproduced; confirmation and three focused checks passed. Ce script démontre uniquement le calcul et la logique de sélection : il n’exécute ni les tests smoke de l’application ni la suite de régression des fonctions dépendantes.
def old_total(cents):
return cents * 9 // 10 if cents > 10000 else cents
def fixed_total(cents):
return cents * 9 // 10 if cents >= 10000 else cents
# Values below produce whole-cent results; no rounding rule is inferred.
assert old_total(10000) == 10000
assert fixed_total(10000) == 9000
for cents, expected in [(9900, 9900), (10000, 9000), (10100, 9090)]:
assert fixed_total(cents) == expected
print("Known defect reproduced; confirmation and three focused checks passed")Préciser les limites des preuves
Un cas peut appartenir à plusieurs suites : la vérification à 10000 centimes confirme la correction du défaut et peut devenir un futur test de régression. Une exécution répétée n’ajoute pas de couverture comportementale. Consignez le build, l’objectif, le résultat réel et les risques non couverts afin d’expliciter le sens de « réussi ».
Sanity a des sens différents selon les équipes et est parfois synonyme de smoke. Définissez localement son périmètre ; ce tableau n’est pas une classification obligatoire. Confirmation et régression répondent à des questions distinctes : corriger la reproduction initiale ne prouve pas que les comportements voisins restent inchangés.
Exercice : le retest exact à 10000 centimes passe, mais les factures affichent encore 10000 alors que le paiement a enregistré 9000. Peut-on déclarer la livraison sans défaut ? Non. Le défaut initial peut être corrigé alors qu’un test de régression d’une fonction dépendante échoue. Consignez les deux résultats et analysez l’incohérence au lieu de transformer un retest réussi en décision de livraison.
Pour aller plus loin
Construire une stratégie de régression selon les risques
Recueillir les preuves de livraison
Conserver des checklists opérationnelles courtes
ISTQB CTFL 4.0.1 : section 2.2.3, confirmation et régression