Développement Piloté par les Tests: Le Guide de l'Ingénieur QA

Le Test-Driven Development (TDD) suit un cycle Rouge-Vert-Refactoring : écrire un test qui échoue, écrire le minimum de code pour le faire passer, puis nettoyer. Pour les ingénieurs QA, le TDD compte de deux façons. La première est de collaborer avec des développeurs qui le pratiquent. La deuxième est d'appliquer le développement piloté par les tests d'acceptation (ATDD) pour définir les exigences sous forme de tests exécutables avant le début du développement.

Ce qu'est vraiment le TDD

Le cycle TDD se compose de trois étapes :

1. Rouge : écrire un test qui échoue pour le comportement souhaité

2. Vert : écrire le minimum de code pour faire passer le test

3. Refactoring : nettoyer le code sans casser le test

Répétez pour chaque comportement suivant.

Le mot clé est "minimum". Vous écrivez exactement assez de code pour passer le test, rien de plus. Cela force l'implémentation à être pilotée par sa spécification (le test), et non l'inverse.

Ce que le TDD change dans le code

Le TDD produit un code qui est :

Testable par conception. Un code difficile à tester est souvent un signe de mauvaise conception : couplage fort, dépendances cachées, trop de responsabilités. Le TDD force la testabilité au moment de l'écriture, pas en rattrapage. Couvert par définition. Chaque comportement a un test parce qu'il fallait écrire le test pour écrire le comportement. Incrémental. Les fonctionnalités sont construites par petites étapes vérifiées. Il n'y a pas de "tout écrire, puis tester". Documenté. La suite de tests est une spécification exécutable. Lire les tests dit ce que le code est censé faire.

Où les ingénieurs QA s'intègrent dans les équipes TDD

Les ingénieurs QA dans des équipes TDD font face à un paradoxe : les développeurs écrivent déjà des tests. Que reste-t-il ?

Plusieurs choses :

Tests de niveau supérieur : les développeurs écrivent des tests unitaires. Les ingénieurs QA écrivent des tests d'intégration et des tests E2E. Le TDD au niveau unitaire ne remplace pas la vérification E2E. Développement piloté par les tests d'acceptation (ATDD) : les ingénieurs QA rédigent des tests d'acceptation avant que les développeurs n'écrivent du code. Les développeurs font passer ces tests. C'est le TDD au niveau de la fonctionnalité. Cela exige que le QA soit impliqué au début du développement, pas à la fin. Tests exploratoires et cas limites : les tests TDD sont rédigés par des développeurs qui savent comment le système fonctionne. Les ingénieurs QA testent ce que les développeurs n'ont pas pensé à spécifier : les cas limites, les entrées inhabituelles, les points d'intégration, les performances sous charge. Revue de la qualité des tests : les tests du développeur testent-ils vraiment les bonnes choses ? Testent-ils le comportement ou l'implémentation ? Détecteront-ils les bugs qui comptent ? Les ingénieurs QA peuvent revoir le code de test, pas seulement le code produit.

Développement piloté par les tests d'acceptation (ATDD)

L'ATDD est la version QA du TDD. Le flux de travail :

1. Un stakeholder métier décrit une fonctionnalité en termes utilisateur

2. L'ingénieur QA traduit cela en critères d'acceptation et tests d'acceptation

3. Les développeurs implémentent jusqu'à ce que les tests d'acceptation passent

4. Le QA vérifie à la fois les tests et l'implémentation

Les tests d'acceptation deviennent la source de vérité pour ce que "terminé" signifie. Une fonctionnalité est terminée quand ses tests d'acceptation passent.

Avec Playwright :

// Rédigé avant que l'implémentation existe
test('user can reset password via email', async ({ page }) => {
  // Étant donné un utilisateur avec un e-mail enregistré
  const userEmail = 'testuser@example.com';

  // Quand il demande une réinitialisation de mot de passe
  await page.goto('/forgot-password');
  await page.getByLabel('Email address').fill(userEmail);
  await page.getByRole('button', { name: 'Send reset link' }).click();

  // Alors il voit un message de confirmation
  await expect(page.getByRole('alert')).toHaveText(
    'If that email is registered, a reset link is on its way.'
  );

  // Et il reçoit un e-mail de réinitialisation (vérifié via l'API d'e-mail de test)
  const inbox = await testEmailAPI.getInbox(userEmail);
  expect(inbox.some(m => m.subject.includes('Reset your password'))).toBe(true);
});

Ce test est rédigé avant que la fonctionnalité soit construite. Le travail du développeur est de le faire passer.

Behavior-Driven Development (BDD)

Le BDD est une évolution de l'ATDD qui ajoute un langage partagé (généralement Gherkin) pour rédiger des tests que les non-ingénieurs peuvent lire :

Feature: Password reset

  Scenario: User resets password via email
    Given a user with email "testuser@example.com" is registered
    When they submit the forgot password form with that email
    Then they see "If that email is registered, a reset link is on its way."
    And they receive a password reset email within 1 minute

Ces scénarios Gherkin correspondent à du code de test Playwright via une couche de définition d'étapes (avec des outils comme Cucumber.js ou les plugins BDD de Playwright).

Le BDD est plus utile quand les stakeholders non-techniques rédigent ou révisent les scénarios. Il ajoute de la charge pour les équipes où tous les stakeholders peuvent lire du code.

Les ingénieurs QA doivent-ils pratiquer le TDD eux-mêmes ?

Pour le code d'automatisation des tests : généralement non. Le TDD est conçu pour le code de production, là où vous concevez un système. Le code de test doit être simple à écrire et à vérifier. Écrire des tests pour votre code de test crée une complexité inutile.

L'exception : les ingénieurs QA qui construisent des frameworks de test ou des utilitaires (helpers de page objects, utilitaires de fixtures, intégrations de reporting). Ceux-ci peuvent bénéficier du TDD pour construire ces outils.

Ce que ça change concrètement pour le QA dans les équipes TDD

1. Impliquez-vous avant que le code soit écrit. Revoyez les user stories pour la testabilité. Rédigez les critères d'acceptation. Définissez les cas limites.

2. Rédigez les tests d'acceptation tôt. Même si les développeurs ne font pas de l'ATDD formel, avoir des tests d'acceptation rédigés avant le début du développement façonne l'implémentation.

3. Déplacez les tests exploratoires plus tôt. Dans les équipes TDD, les tests exploratoires deviennent plus importants parce que c'est ce qui trouve les choses que les tests n'ont pas spécifiées.

4. Revoyez les tests des développeurs. Pas pour les chiffres de couverture, mais pour vérifier si les tests valident réellement le comportement qui compte.

Le TDD n'élimine pas le besoin d'ingénieurs QA. Il change l'endroit où le travail QA se produit : de l'après-code à l'en-parallèle-du-code.