Tests d'Acceptation: Ce que C'est, Qui les Fait et Comment

L'acceptance testing vérifie que le logiciel respecte les exigences métier avant la mise en production. Il couvre trois formes distinctes : l'UAT réalisée par les parties prenantes, l'ATDD où des tests exécutables définissent les fonctionnalités en amont, et les tests d'acceptation fonctionnels. Dans ce dernier cas, le QA vérifie que chaque exigence du cahier des charges est correctement implémentée.

Ce que recouvre vraiment l'acceptance testing

Le terme englobe plusieurs concepts liés :

User Acceptance Testing (UAT) : les utilisateurs réels (ou les parties prenantes métier) testent le logiciel dans un environnement de staging. Ils confirment qu'il répond à leurs exigences avant la validation finale. Acceptance Test-Driven Development (ATDD) : les exigences sont rédigées sous forme de tests exécutables avant le démarrage du développement. Les tests passent quand la fonctionnalité est terminée. Tests d'acceptation fonctionnels : le QA vérifie que toutes les exigences du cahier des charges sont implémentées et fonctionnent correctement.

En pratique, "acceptance testing" désigne généralement l'une de deux choses. L'UAT réalisée par des équipes métier, ou les tests d'acceptation fonctionnels réalisés par le QA sur la base des exigences formelles.

Les critères d'acceptation : la base de tout

L'acceptance testing commence par les critères d'acceptation, c'est-à-dire les conditions spécifiques qu'une fonctionnalité doit remplir pour être considérée comme terminée.

Mauvais critères d'acceptation :

La page de connexion doit fonctionner correctement.

Bons critères d'acceptation :

- Les utilisateurs peuvent se connecter avec un email et un mot de passe valides et sont redirigés vers le tableau de bord

- Si l'email ou le mot de passe est incorrect, un message d'erreur "Email ou mot de passe invalide" apparaît

- Après 5 tentatives échouées en 10 minutes, le compte est verrouillé et un message "trop de tentatives" apparaît

- Une connexion réussie crée une session qui expire après 24 heures d'inactivité

- Le lien "Mot de passe oublié" envoie un email de réinitialisation en moins de 2 minutes

Des bons critères sont spécifiques, testables et non ambigus.

Rédiger les critères d'acceptation en Gherkin

Gherkin est un langage structuré pour rédiger des critères d'acceptation au format Given/When/Then. Il est lisible par des parties prenantes non techniques et exécutable par des outils comme Cucumber :

Feature: Connexion utilisateur

  Scenario: Connexion réussie avec des identifiants valides
    Given je suis sur la page de connexion
    When je saisis "user@example.com" comme email
    And je saisis "ValidPass1" comme mot de passe
    And je clique sur le bouton "Se connecter"
    Then je dois être redirigé vers le tableau de bord
    And je dois voir "Bienvenue, Utilisateur Test" dans l'en-tête

  Scenario: Connexion avec des identifiants invalides
    Given je suis sur la page de connexion
    When je saisis "user@example.com" comme email
    And je saisis "MauvaisMotDePasse" comme mot de passe
    And je clique sur le bouton "Se connecter"
    Then je dois voir "Email ou mot de passe invalide"
    And je dois rester sur la page de connexion

  Scenario: Verrouillage du compte après des tentatives échouées
    Given je suis sur la page de connexion
    When je saisis "user@example.com" avec un mauvais mot de passe 5 fois
    Then je dois voir "Trop de tentatives échouées. Réessayez dans 10 minutes."
    And le bouton Se connecter doit être désactivé

Processus UAT : étape par étape

1. Définir le périmètre des tests

Quelles fonctionnalités sont incluses dans ce cycle UAT ? C'est généralement lié à une release ou un sprint.

2. Rédiger les scénarios avec les utilisateurs métier

Impliquez les vrais utilisateurs ou les product owners dans la rédaction des scénarios. Ce sont eux qui savent ce que "correct" signifie du point de vue métier.

3. Préparer l'environnement

L'UAT doit tourner dans un environnement proche de la production : mêmes données, mêmes intégrations, même configuration. Le laptop d'un développeur n'est pas un environnement UAT.

4. Créer les données de test

Les utilisateurs ont besoin de données de test réalistes qui représentent leurs cas d'usage réels. Pas juste "test@test.com" avec "test123" comme mot de passe.

5. Exécuter les tests

Idéalement, ce sont de vrais utilisateurs qui exécutent les tests. Si ce n'est pas possible, le QA les exécute, mais les critères d'acceptation doivent être définis par les parties prenantes métier, pas par le QA.

6. Documenter les résultats

Chaque test reçoit un statut passé/échoué. Les échecs donnent lieu à des rapports de bugs avec les étapes de reproduction.

7. Corriger et re-tester

Les bugs trouvés en UAT retournent aux développeurs. Le QA re-teste une fois les corrections appliquées.

8. Validation formelle

Les parties prenantes métier approuvent formellement la release. Sans validation, on ne livre pas.

UAT vs tests QA

| Aspect | Tests QA | UAT |

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

| Qui | Ingénieurs QA | Utilisateurs métier / product owners |

| Objectif | Trouver des bugs | Confirmer que les exigences sont respectées |

| Focus | Correction technique | Valeur métier |

| Quand | Pendant le développement | Avant la release |

| Critères | Cas de test | Critères d'acceptation |

| Validation | Lead QA | Partie prenante métier |

Les deux sont nécessaires. Le QA détecte les bugs avant l'UAT pour que les utilisateurs métier ne fassent pas de la chasse aux bugs basique.

Erreurs courantes en acceptance testing

Tester trop tard. L'UAT planifiée 2 jours avant la release sans marge pour les corrections. Chaque bug trouvé devient une crise. Mauvais participants. Faire faire l'UAT par les développeurs annule l'intérêt. Ils savent comment le code fonctionne et ne le testeront pas comme un utilisateur. Critères d'acceptation vagues. "Le checkout doit être fluide" mène à des désaccords sur ce que "fluide" signifie quand des bugs sont trouvés. Mauvais environnement de test. Une UAT sur un serveur de développement avec des données qui ne reflètent pas les volumes ou les intégrations réels laissera passer de vrais bugs. Pas de régression après les corrections. Bug trouvé en UAT, corrigé, déployé, mais personne ne vérifie si la correction a cassé autre chose.

Automatiser les tests d'acceptation

On peut automatiser les tests d'acceptation avec Playwright :

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

test.describe("Connexion — Critères d'acceptation", () => {
  test("CA1 : Les identifiants valides redirigent vers le tableau de bord", async ({ page }) => {
    await page.goto('/login');
    await page.fill('[data-testid="email"]', 'user@test.com');
    await page.fill('[data-testid="password"]', 'ValidPass1');
    await page.click('[data-testid="submit"]');
    
    await expect(page).toHaveURL('/dashboard');
    await expect(page.getByTestId('welcome')).toContainText('Bienvenue');
  });

  test("CA2 : Les identifiants invalides affichent un message d'erreur", async ({ page }) => {
    await page.goto('/login');
    await page.fill('[data-testid="email"]', 'user@test.com');
    await page.fill('[data-testid="password"]', 'MauvaisMotDePasse');
    await page.click('[data-testid="submit"]');
    
    await expect(page.getByTestId('error-message')).toHaveText('Email ou mot de passe invalide');
    await expect(page).toHaveURL('/login');
  });

  test("CA3 : La session expire après 24h d'inactivité", async ({ page }) => {
    // Généralement testé avec un mock temporel ou une manipulation d'API
    await page.goto('/login');
    await page.fill('[data-testid="email"]', 'user@test.com');
    await page.fill('[data-testid="password"]', 'ValidPass1');
    await page.click('[data-testid="submit"]');
    
    // Simuler l'expiration de session via l'API
    await page.request.post('/api/auth/expire-session');
    await page.reload();
    
    await expect(page).toHaveURL('/login');
  });
});

Checklist de l'acceptance testing

Avant de démarrer l'UAT :

[ ] Critères d'acceptation rédigés et validés par le métier
[ ] Fonctionnalité déployée sur l'environnement UAT (pas dev ni staging)
[ ] Données de test préparées (réalistes, pas triviales)
[ ] Utilisateurs métier briefés sur ce qu'ils doivent tester
[ ] Processus de suivi des bugs établi
[ ] Planning incluant du temps pour les corrections et le re-test
[ ] Autorité de validation identifiée

Pendant l'UAT :

[ ] Tests exécutés sur la base des critères d'acceptation
[ ] Tous les échecs documentés avec les étapes de reproduction
[ ] Captures d'écran ou enregistrements pour les problèmes complexes
[ ] Sévérité attribuée à chaque constat

Après l'UAT :

[ ] Tous les bugs P1/P2 corrigés et re-testés
[ ] Validation formelle reçue par écrit
[ ] Notes de release mises à jour avec les problèmes P3/P4 connus

Récapitulatif

L'acceptance testing confirme que le logiciel délivre la valeur métier pour laquelle il a été construit. Points clés :

Basé sur des critères d'acceptation rédigés par les parties prenantes métier, pas le QA
L'UAT implique de vrais utilisateurs ; les tests d'acceptation fonctionnels sont réalisés par le QA sur la base des exigences
Gherkin (Given/When/Then) rend les critères lisibles par les parties prenantes techniques et non techniques
Exécuté dans un environnement proche de la production avec des données réalistes
Nécessite une validation formelle avant la release
Automatisable avec Playwright, surtout utile pour la régression sur les changements futurs

La différence entre une validation QA et une validation métier est importante : le QA dit que le code fonctionne ; le métier dit que la fonctionnalité résout leur problème.