Réponse.

Historique de la question :

Le test smoke ("test de fumée") est apparu comme un moyen rapide de vérifier la fonctionnalité d'un système après une compilation. Son objectif est de s'assurer que les fonctions critiques fonctionnent et que l'application est essentiellement prête pour d'autres vérifications plus approfondies. Dans les tests manuels, les tests smoke sont généralement effectués immédiatement après le déploiement d'une nouvelle version du produit.

Problème :

La principale difficulté réside dans le temps limité et la nécessité de choisir des vérifications vraiment importantes. Souvent, les testeurs vérifient soit trop de choses (gaspillant des ressources inutilement), soit omettent des éléments critiques, ce qui peut entraîner des "trous" dans la version.

Solution :

Une organisation correcte des tests smoke consiste à choisir un nombre minimal de scénarios couvrant les flux utilisateurs les plus importants. Ces vérifications doivent être claires, rapides et reproductibles. Par exemple :

- Connexion réussie de l'utilisateur au système
- Possibilité d'effectuer la fonction principale (par exemple, effectuer un achat)
- Réalisation du paiement et réception d'une confirmation

Caractéristiques clés :

Les tests smoke couvrent uniquement les fonctions vitales
Exécution rapide, ce qui est crucial lors de déploiements fréquents
Tous les scénarios sont exécutés manuellement selon une liste de contrôle préalablement approuvée

Questions pièges.

Peut-on considérer le test smoke comme un remplacement complet des tests de régression ?

Non, le test smoke est uniquement orienté vers un "fonctionne - ne fonctionne pas" pour les fonctions clés. Pour identifier des bogues graves mais non évidents, un test de régression complet est toujours nécessaire.

Que faire si au moins un test smoke échoue ? Le test doit-il se poursuivre ?

Non, il n'est pas judicieux de continuer les tests — l'équipe signale le problème, le déploiement est bloqué jusqu'à ce que le bogue soit corrigé.

Les tests smoke doivent-ils inclure des vérifications des scénarios edge-case ?

Non, les tests smoke ne sont pas destinés à vérifier les cas extrêmes. Ils servent uniquement à confirmer la faisabilité de la fonctionnalité des fonctions principales du produit.

Erreurs courantes et anti-patterns

Exécution de tests excessifs qui ne sont pas critiques pour la fonctionnalité
Absence de documentation sur les tests smoke (le testeur "garde tout en tête")
Ignorer les problèmes évidents pour des raisons de "reporting"

Exemples de la vie réelle

Cas négatif

Un test smoke a été réalisé selon une liste de contrôle exhaustive, incluant des fonctions peu significatives. Cela a pris beaucoup de temps, ce qui a retardé le déploiement de plusieurs heures.

Avantages :

Identification de plusieurs bogues non évidents

Inconvénients :

Retard de déploiement
Ressources et temps gaspillés pour des vérifications peu significatives

Cas positif

Le test smoke s'est concentré uniquement sur les scénarios les plus critiques. Un bogue bloquant a été rapidement identifié et signalé à l'équipe — le déploiement a été suspendu jusqu'à correction.