Réponse.

Historique de la question :

Les tests smoke (smoke tests, tests de "fumée") sont à l'origine apparus comme un moyen rapide de s'assurer que la fonctionnalité de base d'un système fonctionne après le déploiement ou la modification du code. Leur idéologie est "si quelque chose de critique est cassé, il n'est pas utile de lancer des vérifications détaillées". Dans l'automatisation, les premiers tests smoke ont été réalisés sous forme de petits scripts manuels pour vérifier le lancement de l'application, l'accès à l'écran de connexion et les actions de base.

Problème :

Les principales difficultés de l'automatisation des tests smoke résident dans l'isolation correcte d'un ensemble minimal de scénarios, la rapidité d'exécution, la dépendance minimale à des composants instables (par exemple, des services tiers), ainsi que le soutien visuel et technique pour leur "légèreté et leur transparence". Si cela n'est pas réalisé, l'automatisation smoke devient soit trop lourde, soit génère souvent de faux positifs et nécessite un vaste entretien.

Solution :

Minimisez le nombre de tests smoke : ils ne doivent contenir que des vérifications des "points d'entrée" les plus critiques (par exemple, l'authentification, le lancement du module principal, la disponibilité de la base de données).
Éloignez les étapes instables et les dépendances externes des scénarios smoke, ou stabilisez les environnements avec des "moke".
Utilisez la balisage (@smoke, Suite('smoke'), etc.) et des sections séparées dans le pipeline CI/CD pour exécuter les tests smoke en premier.

Caractéristiques clés :

Les scénarios smoke doivent s'exécuter rapidement et utiliser uniquement le morceau d'infrastructure le plus stable.
Les tests automatisés de type smoke ne doivent pas couvrir les détails UX ou les workflows complexes.
L'automatisation smoke nécessite un contrôle strict des dépendances et un code de support minimum.

Questions pièges.

Peut-on ajouter des scénarios de vérification de la logique edge-case dans le jeu de tests smoke ?

Non, le jeu de tests smoke est uniquement destiné à vérifier la viabilité et la disponibilité du système principal, les edge-cases sont superflus ici, ils ralentiront l'exécution et compliqueront l'entretien.

Faut-il mettre en œuvre un traitement des erreurs multi-niveaux et un recovery dans les tests smoke ?

On considère souvent à tort que des mécanismes de recovery compliqués sont nécessaires dans les tests smoke. En réalité, si un test smoke échoue, cela signale un problème critique qui doit être corrigé, et non "contourné" dans le test automatisé.

Les tests smoke doivent-ils dépendre des données laissées par d'autres tests ?

Non, les tests smoke ne doivent dépendre d'aucune donnée de test externe et encore moins des artefacts d'autres tests. C'est l'un des principes clés de leur fiabilité.

Erreurs typiques et anti-patrons

Surcharge de tests smoke : trop de scénarios, les transformant en vérifications de régression.
Duplication de code entre les tests smoke et les tests automatisés classiques.
Dépendances implicites : le test utilise des données/artefacts "sales" d'autres scénarios.

Exemple de la vie

Cas négatif

Nous avons créé dans le jeu de scénarios smoke 30 vérifications différentes, dont certaines testent non seulement le lancement du système, mais aussi des algorithmes complexes, des conditions edge-case. L'exécution du lancement smoke a commencé à prendre 30 minutes, et périodiquement certaines vérifications échouaient en raison de l'instabilité du backend.

Avantages :

Il est facile de voir les goulets d'étranglement du système.
Couverture élevée par les tests immédiatement après le déploiement.

Inconvénients :

La véritable essence du smoke a été perdue : une version "verte" ne peut être obtenue qu'après une longue attente et la résolution de problèmes non significatifs pour mettre le système en production.
Difficile de maintenir les tests et de distinguer les vraies pannes critiques.

Cas positif

Nous avons réduit à un strict minimum le groupe smoke : connexion, ouverture de la page d'accueil, requête à la base, poignée de main API de base. Le cadre de test smoke fonctionne indépendamment de la matrice de test principale et est toujours le premier dans le pipeline CI/CD. Les résultats sont disponibles dans un chat séparé et toujours disponibles pour un diagnostic rapide.