Les critères d’acceptation sont une description de ce qui serait vérifié par un test. Étant donné une exigence telle que « En tant qu’utilisateur, je veux emprunter un livre à la bibliothèque », un critère d’acceptation pourrait être, « vérifier que le livre est marqué comme emprunté ». Un test d’acceptation pour cette exigence donne les détails afin que le test puisse être exécuté avec le même effet à chaque fois.
Format du testEdit
Les tests d’acceptation suivent généralement cette forme :
Given (setup)
Un état spécifié d’un système
When (trigger)
Une action ou un événement se produit
Then (verification)
L’état du système a changé ou une sortie a été produite
Alors, il est possible d’ajouter des déclarations qui commencent par AND dans n’importe laquelle des sections ci-dessous (Given, When, Then).
Pour l’exemple d’exigence, les étapes pourraient être énumérées comme suit :
Given Book that has not been checked outAnd User who is registered on the systemWhen User checks out a bookThen Book is marked as checked out
Compléter le testModifier
Les étapes précédentes ne comprennent pas de données d’exemple spécifiques, qui sont donc ajoutées pour compléter le test :
Donné :
Livre qui n’a pas été emprunté
Livres | |
---|---|
Titre | Arrêté |
Grand livre | Non |
Utilisateur qui est enregistré sur le système
Users | |
---|---|
Nom | Sam |
Quand :
L’utilisateur emprunte un livre
Action d’emprunt | |||
---|---|---|---|
Utilisateur | Sam | Extrait | Grand livre |
Alors :
Le livre est marqué comme étant emprunté
Livres | |||
---|---|---|---|
Titre | Arrêté | Utilisateur | |
Grand livre | . livre | Oui | Sam |
Examen du testEdit
L’examen du test avec des données spécifiques conduit généralement à de nombreuses questions. Pour l’exemple, celles-ci peuvent être :
- Que se passe-t-il si le livre est déjà emprunté ?
- Que se passe-t-il si le livre n’existe pas ?
- Que se passe-t-il si l’utilisateur n’est pas enregistré dans le système ?
- Y a-t-il une date à laquelle le livre doit être enregistré ?
- Combien de livres un utilisateur peut-il enregistrer ?
Ces questions aident à éclairer les exigences manquantes ou ambiguës. Des détails supplémentaires tels qu’une date d’échéance peuvent être ajoutés au résultat attendu. D’autres tests d’acceptation peuvent vérifier que des conditions telles que la tentative d’emprunter un livre déjà emprunté produit l’erreur attendue.
Un autre exemple de testEdit
Supposons que le client commercial souhaite une règle de gestion selon laquelle un utilisateur ne peut emprunter qu’un seul livre à la fois. Le test suivant le démontrerait :
Scénario:Vérifier que la règle métier de sortie est appliquée
Donné :
Livre qui a été emprunté
Livres | ||
---|---|---|
Titre | Checked out | User |
Great book | Oui | Sam |
Encore un grand livre | Non |
Nom
Sam
Quand :
L’utilisateur vérifie un autre livre
Action de vérification | |||
---|---|---|---|
Utilisateur | Sam | Vérifie | Un autre grand livre |
Alors :
Une erreur se produit
Description
Violation de la règle métier de la caisse
Tests d’acceptation du projetModifier
En plus des tests d’acceptation pour les exigences, les tests d’acceptation peuvent être utilisés sur un projet dans son ensemble. Par exemple, si cette exigence faisait partie d’un projet de vérification des livres d’une bibliothèque, il pourrait y avoir des tests d’acceptation pour l’ensemble du projet. Ces tests sont souvent appelés objectifs SMART. Un exemple de test est le suivant : « Lorsque le nouveau système de bibliothèque sera en production, les utilisateurs pourront emprunter et retirer des livres trois fois plus vite qu’aujourd’hui ».