Test dacceptation.pdf

Définition

Un test d’acceptation est un test métier permettant de valider tout ou partie d’une fonctionnalité

Lest tests d’acceptation permettent au client de vérifier qu’une fonctionnalité a été implémentée. Si l’ensemble des tests d’acceptation d’une fonctionnalité sont verts, le client peut accepter la fonctionnalité.

<aside> 💡

Par nature, ce sont des test fonctionnels

</aside>

Test d’acceptation et Application

Le lien entre les besoins métier et le code de l'application est au cœur des tests d'acceptation automatisés.

• Tests d’acceptation en langage métier (HTML, Wiki, Gherkin) Ce sont les spécifications du comportement attendu du système. Rédigés dans un langage structuré mais naturel (comme le Gherkin avec sa syntaxe Étant donné / Quand / Alors), ils sont compréhensibles par tous les membres de l'équipe, y compris les non-techniciens (analystes métier, chefs de produit). Ils décrivent ce que le système doit faire du point de vue de l'utilisateur.
• Code de l’application (Java, C++, Python, etc.) C'est l'implémentation technique qui réalise les fonctionnalités décrites dans les stories. C'est le comment le système accomplit ce qui est demandé.
• La jonction est faite par un fixture Le fixture (souvent appelé "glue code" ou "code de liaison") est le pont technique entre la spécification en langage métier et le code de l'application. Pour chaque étape d'un scénario de test (par exemple, "Quand je clique sur le bouton 'Connexion'"), le fixture contient une fonction ou une méthode qui :
  1. Interprète l'instruction en langage naturel.
  2. Exécute l'action correspondante sur l'application (simuler un clic, appeler une API, etc.).
  3. Vérifie que le résultat obtenu est conforme à celui attendu dans la spécification.

Agilité et Tests d’Acceptation

L'intégration des tests d'acceptation est un pilier des méthodologies agiles pour garantir la qualité et la pertinence du produit développé.

• Les méthodes agiles utilisent des cycles de développement courts pendant lesquels sont prises en charge la réalisation de "stories" (récits utilisateurs). Chaque story représente une petite fonctionnalité apportant de la valeur à l'utilisateur final.
• La définition et la “mise en page” des tests d’acceptation prennent naturellement place avant de débuter l’implémentation relative à une story. Ce principe fondamental est la clé de voûte de plusieurs approches. En écrivant les tests en premier, l'équipe s'assure d'une compréhension commune et sans ambiguïté de ce qui doit être construit. Le test d'acceptation devient le critère objectif qui définit quand la story est "terminée" (Definition of Done). Cela évite les malentendus, réduit le gaspillage et garantit que le développement est toujours focalisé sur la satisfaction du besoin initial.

<aside> ☝

ATDD : Acceptance Test Driven Development

</aside>

L'ATDD est une pratique de développement collaborative où les membres de l'équipe (représentants métier, développeurs, testeurs) discutent et définissent les critères d'acceptation d'une story avant de commencer le codage. Ces critères sont ensuite formalisés en tests d'acceptation automatisés. Le cycle de l'ATDD est souvent résumé par :

1. Discuter : L'équipe collabore pour définir le comportement attendu.
2. Formaliser : Les critères sont écrits sous forme de tests qui échouent initialement.
3. Développer : L'équipe écrit le code applicatif nécessaire pour que les tests passent.
4. Démontrer : Le passage des tests démontre que la fonctionnalité est complète et correcte.