Tests de Fumée vs Tests de Régression: Quelle est la Différence?

Le smoke testing est un petit sous-ensemble rapide de tests qui vérifie que les chemins les plus critiques sont opérationnels après un build. Le test de régression est une couverture plus large qui vérifie que les fonctionnalités existantes n'ont pas été cassées par les nouvelles modifications.

Smoke testing

Un smoke test répond à une seule question : le système fonctionne-t-il fondamentalement ?

Le nom vient des tests matériels : on allume un appareil, on regarde s'il fume. S'il passe ce contrôle, ça vaut la peine d'aller plus loin. S'il échoue, les tests approfondis sont inutiles.

Dans le logiciel, un smoke test est un petit sous-ensemble rapide de tests qui vérifie que les chemins les plus critiques sont opérationnels. Généralement 10 à 20 tests, exécutables en moins de 5 minutes.

• L'application démarre et se charge
• L'authentification fonctionne
• L'action utilisateur la plus critique se complète (passer une commande, soumettre un formulaire, réaliser un paiement)
• Les endpoints API principaux répondent

• Les cas limites
• Les états d'erreur
• Les fonctionnalités secondaires
• Les performances sous charge

Quand exécuter les smoke tests

• Après chaque déploiement (même en production)
• Après des changements d'infrastructure (redémarrages de serveur, changements de configuration)
• Comme première étape en CI, avant que la suite complète s'exécute
• Quand vous avez besoin d'une vérification rapide avant une démo

Exemple de smoke test avec Playwright

// smoke.spec.ts
import { test, expect } from '@playwright/test';

test.describe('@smoke', () => {
  test('app loads', async ({ page }) => {
    await page.goto('/');
    await expect(page).toHaveTitle(/MyApp/);
    await expect(page.getByRole('navigation')).toBeVisible();
  });

  test('login works', async ({ page }) => {
    await page.goto('/login');
    await page.getByLabel('Email').fill(process.env.TEST_USER_EMAIL!);
    await page.getByLabel('Password').fill(process.env.TEST_USER_PASSWORD!);
    await page.getByRole('button', { name: 'Log in' }).click();
    await expect(page).toHaveURL('/dashboard');
  });

  test('core API is responding', async ({ request }) => {
    const response = await request.get('/api/health');
    expect(response.status()).toBe(200);
    const body = await response.json();
    expect(body.status).toBe('ok');
  });

  test('order placement works end to end', async ({ page }) => {
    // chemin critique minimal
    await page.goto('/products');
    await page.getByRole('link', { name: 'Laptop Pro' }).click();
    await page.getByRole('button', { name: 'Add to cart' }).click();
    await page.goto('/checkout');
    // ... étapes minimales du checkout
    await expect(page.getByText('Order confirmed')).toBeVisible();
  });
});

Exécuter uniquement les smoke tests :

npx playwright test --grep @smoke

Test de régression

Une suite de tests de régression vérifie que les fonctionnalités existantes fonctionnent encore après une modification. La question n'est pas "le système fonctionne-t-il du tout" mais "avons-nous cassé quelque chose qui marchait avant ?"

Les tests de régression sont plus larges et plus lents que les smoke tests. Une suite de régression complète peut couvrir des centaines de scénarios et prendre 20 à 60 minutes.

• Toutes les fonctionnalités, y compris les scénarios secondaires et les cas limites
• La gestion des erreurs
• Les conditions aux limites
• Le comportement cross-browser
• Les points d'intégration entre services

Quand exécuter les tests de régression

• Avant chaque release
• Après des changements de code significatifs (nouvelles fonctionnalités, refactoring)
• Sur la branche principale après les merges de PR
• La nuit pour les grandes suites

Types de tests de régression

Différences clés

| | Smoke Testing | Test de régression |

|---|---|---|

| Objectif | Le système est-il en vie ? | Avons-nous cassé quelque chose ? |

| Périmètre | Chemins critiques uniquement | Toutes les fonctionnalités |

| Vitesse | Rapide (2 à 5 min) | Lent (20 à 60+ min) |

| Fréquence | Chaque déploiement | Avant les releases, après les changements |

| Nombre de tests | 10 à 30 | Des centaines à des milliers |

| Action en cas d'échec | Rollback ou arrêt | Corriger avant la release |

Construire la bonne répartition

La plupart des équipes exécutent leur suite entière comme régression et n'ont pas de couche smoke dédiée. Ce schéma crée un problème. Quand vous déployez en production et que quelque chose ne va pas, vous ne pouvez pas vérifier rapidement les chemins critiques. Votre suite de régression complète de 45 minutes n'est pas le bon outil.

Une meilleure structure :

@smoke (exécuté à chaque déploiement, 5 min max)
├── L'app se charge
├── L'auth fonctionne
├── La fonctionnalité principale se complète

@regression (exécuté avant la release, 30-60 min)
├── Tests @smoke (inclus)
├── Tous les autres tests de fonctionnalités
├── Cas limites
└── Cross-browser

Taguez vos tests les plus critiques avec @smoke. Exécutez-les après chaque déploiement. Exécutez la suite complète avant chaque release.

Ce qui n'est pas un test de régression

La confusion vient de la surcharge du mot "régression" : dans l'usage courant, tout test automatisé qui s'exécute après un changement est appelé test de régression. Dans l'usage formel, le test de régression désigne spécifiquement la vérification que des fonctionnalités précédemment fonctionnelles fonctionnent encore.

Les deux usages sont acceptables en pratique. Ce qui compte, c'est d'être clair sur ce que vous vérifiez et pourquoi.