Accélérer vos processus de test grâce à l’IA générative

Techniques de test 
1.	Aperçu des techniques de test
Les techniques de test aident le testeur dans l'analyse de test (ce qu'il faut tester) et dans la conception des tests (comment tester). Les techniques de test aident à développer de manière systématique un ensemble relativement restreint, mais suffisant, de cas de test. Les techniques de test aident également le testeur à définir les conditions de test, à identifier les éléments de couverture et à identifier les données de test au cours de l'analyse et de la conception des tests. De plus amples informations sur les techniques de test et les mesures correspondantes peuvent être trouvées dans le standard ISO/IEC/IEEE 29119-4, et dans (Beizer 1990, Craig 2002, Copeland 2004, Koomen 2006, Jorgensen 2014, Ammann 2016, Forgács 2019).
Dans ce syllabus, les techniques de test sont classées en boîte noire, boîte blanche et basée sur l'expérience
Les techniques de test boîte noire (également connues sous le nom de techniques basées sur les spécifications) sont basées sur une analyse du comportement spécifié de l'objet de test sans référence à sa structure interne. Les cas de test sont donc indépendants de l'implémentation du logiciel. Par conséquent, si l'implémentation change, mais que le comportement requis reste le même, les cas de test restent utiles. 
Les techniques de test boîte blanche (également connues sous le nom de techniques basées sur la structure) sont basées sur une analyse de la structure interne et du traitement de l'objet de test. Comme les cas de test dépendent de la conception du logiciel, ils ne peuvent être créés qu'après la conception ou l'implémentation de l'objet de test. 
Les techniques de test basées sur l'expérience utilisent efficacement les connaissances et l'expérience des testeurs pour la conception et l'implémentation des cas de test. L'efficacité de ces techniques dépend fortement des compétences du testeur. Les techniques de test basées sur l'expérience peuvent détecter des défauts qui pourraient échapper aux techniques de test boîte noire et boîte blanche. Les techniques de test basés sur l'expérience sont donc complémentaires des techniques de test boîte noire et boîte blanche.

2.	Techniques de test boîte noire
Les techniques de test boîte noire couramment utilisées et présentées dans les sections suivantes sont les suivantes :
•	Partitions d'équivalence.
•	Analyse des valeurs limites.
•	Test par tables de décisions.
•	Test de transition d'état.
2.1.	Partitions d'équivalence
Les partitions d'équivalence divisent les données en partitions (appelées partitions d'équivalence) en partant du principe que tous les éléments d'une partition donnée doivent être traités de la même manière par l'objet de test. La théorie qui sous-tend cette technique est que si un cas de test, qui teste une valeur d'une partition d'équivalence, détecte un défaut, ce défaut devrait également être détecté par les cas de test qui testent n'importe quelle autre valeur de la même partition. Par conséquent, un test pour chaque partition est suffisant. 
Les partitions d'équivalence peuvent être identifiées pour tout élément de données lié à l'objet de test, y compris les entrées, les sorties, les éléments de configuration, les valeurs internes, les valeurs liées au temps et les paramètres d'interface. Les partitions peuvent être continues ou discrètes, ordonnées ou non, finies ou infinies. Les partitions ne doivent pas se chevaucher et doivent être des ensembles non vides.
Pour les objets de test simples, la technique des partitions d'équivalence peut être simple, mais dans la pratique, il est souvent compliqué de comprendre comment l'objet de test traitera les différentes valeurs. C'est pourquoi le partitionnement doit être effectué avec soin.
Une partition contenant des valeurs valides est appelée partition valide. Une partition contenant des valeurs invalides est appelée partition invalide. Les définitions des valeurs valides et invalides peuvent varier selon les équipes et les organisations. Par exemple, les valeurs valides peuvent être interprétées comme celles qui doivent être traitées par l'objet de test ou comme celles pour lesquelles la spécification définit le traitement. Les valeurs invalides peuvent être interprétées comme celles qui doivent être ignorées ou rejetées par l'objet de test ou comme celles pour lesquelles aucun traitement n'est défini dans la spécification de l'objet de test.
Dans la technique des partitions d'équivalence, les éléments de couverture sont les partitions d'équivalence. Pour atteindre une couverture de 100 % avec cette technique, les cas de test doivent exercer toutes les partitions identifiées (y compris les partitions invalides) en couvrant chaque partition au moins une fois. La couverture est mesurée comme le nombre de partitions exercées par au moins un cas de test, divisé par le nombre total de partitions identifiées, et est exprimée en pourcentage.
De nombreux objets de test comprennent plusieurs ensembles de partitions (par exemple, les objets de test avec plus d'un paramètre d'entrée), ce qui signifie qu'un cas de test couvrira des partitions provenant de différents ensembles de partitions. Le critère de couverture le plus simple dans le cas d'ensembles multiples de partitions est appelé couverture Each Choice (Ammann 2016). La couverture Each Choice exige que les cas de test exercent chaque partition de chaque ensemble de partitions au moins une fois. La couverture Each Choice ne prend pas en compte les combinaisons de partitions.
2.2.	Analyse des valeurs limites
L'analyse des valeurs limites est une technique basée sur l'exercice des limites des partitions d'équivalence. Par conséquent, la technique de l'analyse des valeurs limites ne peut être utilisée que pour des partitions ordonnées. Les valeurs minimales et maximales d'une partition sont ses valeurs limites. Dans le cas de la technique de l'analyse des valeurs limites, si deux éléments appartiennent à la même partition, tous les éléments qui se trouvent entre eux doivent également appartenir à cette partition.
La technique de l'analyse des valeurs limites se concentre sur les valeurs limites des partitions, car les développeurs sont plus susceptibles de commettre des erreurs au niveau de ces valeurs limites. Les défauts typiques trouvés par cette technique se situent là où les limites implémentées sont mal placées, à des positions supérieures ou inférieures à celles prévues, ou sont complètement omises. 
Ce syllabus couvre deux versions de la technique de l'analyse des valeurs limites : la technique à 2 valeurs et la technique à 3 valeurs. Elles diffèrent en termes d'éléments de couverture par limite qui doivent être exercés pour atteindre une couverture de 100 %.
Dans la technique à 2 valeurs (Craig 2002, Myers 2011), pour chaque valeur limite, il y a deux éléments de couverture : la valeur limite en question et sa voisine la plus proche appartenant à la partition adjacente. Pour atteindre une couverture de 100 % avec la technique à 2 valeurs, les cas de test doivent exercer tous les éléments de couverture, c'est-à-dire toutes les valeurs limites identifiées. La couverture est mesurée comme le nombre de valeurs limites exercées, divisé par le nombre total de valeurs limites identifiées, et est exprimée en pourcentage.
Dans la technique à 3 valeurs (Koomen 2006, O'Regan 2019), pour chaque valeur limite, il y a trois éléments de couverture : la valeur limite en question et ses deux voisines. Par conséquent, dans la technique à 3 valeurs, certains des éléments de couverture peuvent ne pas être des valeurs limites. Pour atteindre une couverture de 100 % avec la technique à 3 valeurs, les cas de test doivent exercer tous les éléments de couverture, c'est-à-dire les valeurs limites identifiées et leurs voisines. La couverture est mesurée comme le nombre de valeurs limites et de leurs voisines exercées, divisé par le nombre total de valeurs limites identifiées et de leurs voisines, et est exprimée en pourcentage.
La technique à 3 valeurs est plus rigoureuse que la technique à 2 valeurs, car elle permet de détecter des défauts qui n'ont pas été pris en compte par la technique à 2 valeurs. Par exemple, si la décision "si (x ≤ 10) ..." est incorrectement implémentée comme "si (x = 10) ...", aucune donnée de test dérivée de la technique à 2 valeurs (x = 10, x = 11) ne peut détecter le défaut. Cependant, x = 9, dérivé de la technique à 3 valeurs, est susceptible de le détecter.
2.3.	Test par tables de décisions 
Les tables de décision sont utilisées pour tester l'implémentation des exigences du système qui spécifient comment différentes combinaisons de conditions aboutissent à des résultats différents. Les tables de décision constituent un moyen efficace d'enregistrer une logique complexe, telle que les règles de gestion.
Lors de la création de tables de décision, les conditions et les actions résultantes du système sont définies. Elles constituent les lignes de la table. Chaque colonne correspond à une règle de décision qui définit une combinaison unique de conditions, ainsi que les actions associées. Dans les tables de décision à entrée limitée, toutes les valeurs des conditions et des actions (à l'exception des valeurs non pertinentes ou irréalisables ; voir ci-dessous) sont présentées sous forme de valeurs booléennes (vrai ou faux). Dans les tables de décision à entrée étendue, tout ou partie des conditions et des actions peuvent également prendre des valeurs multiples (plages de nombres, partitions d'équivalence, valeurs discrètes, etc.)
La notation des conditions est la suivante : " V " (vrai) signifie que la condition est remplie. "F" (faux) signifie que la condition n'est pas remplie. "-" signifie que la valeur de la condition n'est pas pertinente pour le résultat de l'action. "N/A" signifie que la condition est irréalisable pour une règle donnée. Pour les actions : "X" signifie que l'action doit avoir lieu. Blanc signifie que l'action ne doit pas se produire. D'autres notations peuvent également être utilisées.
Une table de décision complète comporte suffisamment de colonnes pour couvrir toutes les combinaisons de conditions. La table peut être simplifiée en supprimant les colonnes contenant des combinaisons de conditions irréalisables. La table peut également être minimisée en fusionnant les colonnes dans lesquelles certaines conditions n'affectent pas le résultat en une seule colonne. Les algorithmes de minimisation des tables de décision sont hors du périmètre de ce syllabus.
Dans les tests par tables de décisions, les éléments de couverture sont les colonnes contenant les combinaisons de conditions réalisables. Pour atteindre une couverture de 100 % avec cette technique, les cas de test doivent exercer toutes ces colonnes.
La couverture est mesurée comme le nombre de colonnes exercées, divisé par le nombre total de colonnes réalisables, et est exprimée en pourcentage.
La force du test par tables de décisions réside dans le fait qu'il fournit une approche systématique permettant d'identifier toutes les combinaisons de conditions, dont certaines pourraient autrement être négligées. Il permet également de trouver des lacunes ou des contradictions dans les exigences. Si les conditions sont nombreuses, l'exercice de toutes les règles de décision peut prendre beaucoup de temps, car le nombre de règles croît de manière exponentielle avec le nombre de conditions. Dans ce cas, pour réduire le nombre de règles à appliquer, on peut utiliser une table de décision réduite ou une approche basée sur les risques.
2.4.	Test de transition d'état
Un diagramme de transition d'états modélise le comportement d'un système en montrant ses états possibles et les transitions d'états valides. Une transition est initiée par un événement, qui peut être qualifié par une condition de garde. Les transitions sont supposées être instantanées et peuvent parfois entraîner une action du logiciel. La syntaxe courante utilisée pour désigner les transitions est la suivante : "événement [condition de garde] / action". Les conditions de garde et les actions peuvent être omises si elles n'existent pas ou si elles ne sont pas pertinentes pour le testeur. 
Une table d'états est un modèle équivalent à un diagramme de transition d'états. Ses lignes représentent les états et ses colonnes les événements (ainsi que les conditions de garde si elles existent). Les entrées de la table (cellules) représentent les transitions et contiennent l'état cible, ainsi que les conditions de garde et les actions résultantes, si elles sont définies. Contrairement au diagramme de transition d'états, la table d'états montre explicitement les transitions non valides, qui sont représentées par des cellules vides.
Un cas de test basé sur un diagramme de transition d'état ou une table d'états est généralement représenté comme une séquence d'événements, qui résulte en une séquence de changements d'état (et d'actions, si nécessaire). Un cas de test peut, et c'est généralement le cas, couvrir plusieurs transitions d'états. 
Il existe de nombreux critères de couverture pour les tests de transition d'état. Ce syllabus discute de trois d'entre eux.
Dans la couverture de tous les états, les éléments de couverture sont les états. Pour obtenir une couverture de 100 %, les cas de test doivent garantir que tous les états sont visités. La couverture est mesurée comme le nombre d'états visités divisé par le nombre total d'états, et est exprimée en pourcentage.
Dans la couverture des transitions valides (également appelée couverture 0-switch), les éléments de couverture sont les transitions valides uniques. Pour obtenir une couverture de 100% des transitions valides, les cas de test doivent exercer toutes les transitions valides. La couverture est mesurée comme le nombre de transitions valides exercées divisé par le nombre total de transitions valides, et est exprimée en pourcentage. 
Dans la couverture de toutes les transitions, les éléments de couverture sont toutes les transitions figurant dans une table d'état. Pour obtenir une couverture de 100 % de toutes les transitions, les cas de test doivent exercer toutes les transitions valides et tenter d'exécuter des transitions non valides. Le fait de ne tester qu'une seule transition non valide dans un seul cas de test permet d'éviter le masquage des défauts, c'est-à-dire une situation dans laquelle un défaut empêche la détection d'un autre. La couverture est mesurée comme le nombre de transitions valides et non valides exercées ou tentées d'être exercées par les cas de test exécutés, divisé par le nombre total de transitions valides et non valides, et est exprimée en pourcentage.
La couverture de tous les états est plus faible que la couverture des transitions valides, car elle peut généralement être obtenue sans exercer toutes les transitions. La couverture des transitions valides est le critère de couverture le plus largement utilisé. L'obtention d'une couverture complète des transitions valides garantit une couverture complète de tous les états. L'obtention d'une couverture complète de toutes les transitions garantit à la fois une couverture complète de tous les états et une couverture complète des transitions valides et devrait constituer une exigence minimale pour les logiciels critiques en termes de mission et de sécurité. 
3.	Techniques de test boîte blanche
En raison de leur popularité et de leur simplicité, cette section se concentre sur deux techniques de test boîte blanche liées au code :
•	Le test des instructions.
•	Le test des branches.
Il existe des techniques plus rigoureuses qui sont utilisées dans certains environnements critiques en termes de sécurité, de mission ou d'intégrité élevée afin d'obtenir une couverture plus complète du code. Il existe également des techniques de tests boîte blanche utilisées à des niveaux de test plus élevés (par exemple, tests API), ou utilisant une couverture non liée au code (par exemple, la couverture des neurones dans les tests de réseaux neuronaux). Ces techniques ne sont pas abordées dans ce syllabus.
3.1.	Test des instructions et couverture des instructions 
Dans le test des instructions, les éléments de couverture sont des instructions exécutables. L'objectif est de concevoir des cas de test qui exercent les instructions du code jusqu'à ce qu'un niveau de couverture acceptable soit atteint. La couverture est mesurée comme le nombre d'instructions exercées par les cas de test divisé par le nombre total d'instructions exécutables dans le code, et est exprimée en pourcentage.
Lorsque la couverture des instructions est de 100 %, cela signifie que toutes les instructions exécutables du code ont été testées au moins une fois. En particulier, cela signifie que chaque instruction comportant un défaut sera exécutée, ce qui peut provoquer une défaillance démontrant la présence du défaut. Cependant, exécuter une instruction avec un cas de test ne permet pas de détecter les défauts dans tous les cas. Par exemple, il se peut qu'il ne détecte pas les défauts qui dépendent des données (par exemple, une division par zéro qui n'échoue que lorsque le dénominateur est fixé à zéro). De même, une couverture des instructions à 100 % ne garantit pas que toute la logique de décision a été testée, car, par exemple, toutes les branches (voir le chapitre 4.3.2) du code n'ont pas été testées. 
3.2.	Test des branches et couverture des branches 
Une branche est un transfert de contrôle entre deux nœuds dans le graphe de flux de contrôle, qui montre les séquences possibles dans lesquelles les instructions du code source sont exécutées dans l'objet de test. Chaque transfert de contrôle peut être inconditionnel (c'est-à-dire un code en ligne droite) ou conditionnel (c'est-à-dire un résultat de décision).
Dans les tests de branches, les éléments de couverture sont les branches et l'objectif est de concevoir des tests pour exercer les branches du code jusqu'à ce qu'un niveau de couverture acceptable soit atteint. La couverture est mesurée comme le nombre de branches exercées par les cas de test divisé par le nombre total de branches, et est exprimée en pourcentage.
Lorsque la couverture des branches est de 100 %, toutes les branches du code, qu'elles soient inconditionnelles ou conditionnelles, sont exercées par les cas de test. Les branches conditionnelles correspondent généralement à un résultat vrai ou faux d'une décision "if...then", à un résultat d'une instruction "switch/case", ou à une décision de quitter ou de continuer dans une boucle. Cependant, l'exercice d'une branche avec un cas de test ne permet pas de détecter les défauts dans tous les cas. Par exemple, il peut ne pas détecter les défauts nécessitant l'exécution d'un chemin spécifique dans le code.
La couverture des branches englobe la couverture des instructions. Cela signifie que tout ensemble de cas de test atteignant une couverture des branches de 100 % atteint également une couverture des instructions de 100 % (mais pas l'inverse).
3.3.	La valeur des tests boîte blanche 
Une force fondamentale que toutes les techniques boîte blanche partagent est que l'implémentation entière du logiciel est prise en compte pendant le test, ce qui facilite la détection des défauts même lorsque la spécification du logiciel est vague, obsolète ou incomplète. Une faiblesse associée est que si le logiciel n'implémente pas une ou plusieurs exigences, les tests boîte blanche peuvent ne pas détecter les défauts résultant de ces omissions (Watson 1996).
Les techniques de test boîte blanche peuvent être utilisées dans le cadre de tests statiques (par exemple, lors d'exécution à blanc du code). Elles sont bien adaptées pour revoir le code qui n'est pas encore prêt à être exécuté (Hetzel 1988), ainsi que le pseudocode et d'autres logiques de haut niveau ou des logiques descendantes qui peuvent être modélisées à l'aide d'un graphe de flux de contrôle.
Le fait de n'effectuer que des tests boîte noire ne permet pas de mesurer la couverture réelle du code. Les mesures de couverture boîte blanche fournissent une mesure objective de la couverture et fournissent les informations nécessaires pour permettre la génération de tests supplémentaires afin d'augmenter cette couverture et, par conséquent, d'accroître la confiance dans le code.
4.	Techniques de tests basés sur l'expérience 
Les techniques de test basées sur l'expérience, couramment utilisées et abordées dans les sections suivantes, sont:
•	Estimation d'erreurs.
•	Test exploratoire.
•	Test basé sur des checklists.
4.1.	Estimation d'erreurs
 L'estimation d'erreurs est une technique utilisée pour anticiper l'apparition d'erreurs, de défauts et de défaillances, sur la base des connaissances du testeur, notamment :
•	La façon dont l'application a fonctionné dans le passé.
•	Les types d'erreurs que les développeurs ont tendance à commettre et les types de défauts qui en résultent.
•	Les types de défaillances qui se sont produites dans d'autres applications similaires.
En général, les erreurs, les défauts et les défaillances peuvent être liés à : l'entrée (par exemple, entrée correcte non acceptée, paramètres erronés ou manquants), la sortie (par exemple, format incorrect, résultat erroné), la logique (par exemple, cas manquants, opérateur incorrect), le calcul (par exemple, opérande incorrect, calcul erroné), les interfaces (par exemple, non-concordance des paramètres, types incompatibles) ou encore les données (par exemple, initialisation incorrecte, type incorrect).
Les attaques de fautes constituent une approche méthodique de la mise en œuvre de l'estimation d'erreurs. Cette technique exige du testeur qu'il crée ou acquière une liste d'erreurs, de défauts et de défaillances possibles, et qu'il conçoive des tests qui identifieront les défauts associés aux erreurs, exposeront les défauts ou provoqueront les défaillances. Ces listes peuvent être construites sur la base de l'expérience, des données relatives aux défauts et aux défaillances, ou des connaissances communes sur les raisons des défaillances des logiciels.
Voir (Whittaker 2002, Whittaker 2003, Andrews 2006) pour plus d'informations sur l'estimation d'erreurs et les attaques de faute.
4.2.	Test exploratoire
Dans le test exploratoire, les tests sont simultanément conçus, exécutés et évalués pendant que le testeur découvre l'objet de test. Les tests sont utilisés pour en apprendre davantage sur l'objet de test, pour l'explorer plus en profondeur avec des tests ciblés et pour créer des tests pour les domaines non testés.
Le test exploratoire est parfois structuré au moyen de test basé sur des sessions. Dans une approche basée sur des sessions, les tests exploratoires sont menés dans un laps de temps défini. Le testeur utilise une charte de test contenant des objectifs de test pour guider le test. La session de test est généralement suivie d'un débriefing qui implique une discussion entre le testeur et les parties prenantes intéressées par les résultats de la session de test. Dans cette approche, les objectifs de test peuvent être traités comme des conditions de test de haut niveau. Les éléments de couverture sont identifiés et exercés pendant la session de test. Le testeur peut utiliser des formulaires de session de test pour documenter les étapes suivies et les découvertes faites.
Les tests exploratoires sont utiles lorsque les spécifications sont peu nombreuses ou inadéquates, ou lorsque les tests sont soumis à une forte pression du temps. Le test exploratoire est également utile pour compléter d'autres techniques de test plus formelles. Les tests exploratoires seront plus efficaces si le testeur est expérimenté, s'il a des connaissances dans le domaine et s'il possède un niveau élevé de compétences essentielles, telles que l'esprit d'analyse, la curiosité et la créativité.
Les tests exploratoires peuvent intégrer l'utilisation d'autres techniques de test (par exemple, les partitions d'équivalence). De plus amples informations sur les tests exploratoires peuvent être trouvées dans (Kaner 1999, Whittaker 2009, Hendrickson 2013).
4.3.	Test basé sur des checklists
Dans le test basé sur des checklists, un testeur conçoit, implémente et exécute des tests pour couvrir les conditions de test à partir d'une checklist. Les checklists peuvent être construites sur la base de l'expérience, de la connaissance de ce qui est important pour l'utilisateur, ou de la compréhension du pourquoi et du comment des échecs logiciels. Les checklists ne doivent pas contenir d'éléments qui peuvent être vérifiés automatiquement, d'éléments correspondant davantage à des critères d'entrée ou de sortie, ou d'éléments trop généraux (Brykczynski 1999).
Les éléments de la checklist sont souvent formulés sous la forme d'une question. Il doit être possible de vérifier chaque élément séparément et directement. Ces éléments peuvent se référer à des exigences, à des propriétés d'interface graphique, à des caractéristiques-qualité ou à d'autres formes de conditions de test. Des checklists peuvent être créées pour soutenir différents types de tests, y compris les tests fonctionnels et non fonctionnels (par exemple, 10 heuristiques pour les tests d'utilisabilité (Nielsen 1994)).
Certaines entrées de la checklist peuvent devenir progressivement moins efficaces au fil du temps parce que les développeurs apprendront à éviter de commettre les mêmes erreurs. Il peut également s'avérer nécessaire d'ajouter de nouvelles entrées pour tenir compte des défauts de sévérité élevée nouvellement trouvés. Par conséquent, les checklists doivent être régulièrement mises à jour sur la base de l'analyse des défauts. Il convient toutefois de veiller à ce que la checklist ne devienne pas trop longue (Gawande 2009). 
En l'absence de cas de test détaillés, le test basés sur des checklists peut fournir des lignes directrices et un certain degré de cohérence pour les tests. Si les checklists sont de haut niveau, une certaine variation dans les tests réels est probable, résultant d'une couverture potentiellement plus grande mais d'une répétabilité moindre.
5.	Approches de test basées sur la collaboration
Chacune des techniques susmentionnées (voir les sections 2, 3, 4) a un objectif particulier en ce qui concerne la détection des défauts. Les approches basées sur la collaboration, en revanche, se concentrent également sur l'évitement des défauts par la collaboration et la communication.
5.1.	Rédaction collaborative de User Stories
Une User Story représente une caractéristique qui sera utile à l'utilisateur ou à l'acheteur d'un système ou d'un logiciel. Les User Stories présentent trois aspects essentiels (Jeffries 2000), appelés ensemble les "3 C" :
•	Carte - le support décrivant une User Story (par exemple, une carte d'index, une entrée dans un tableau électronique). 
•	Conversation - explique comment le logiciel sera utilisé (peut être documentée ou verbale) 
•	Confirmation - les critères d'acceptation (voir section 4.5.2)
Le format le plus courant d'une User Story est le suivant : "En tant que [rôle], je veux que [objectif à atteindre], afin de pouvoir [valeur métier résultante pour le rôle]", suivi des critères d'acceptation.
La rédaction collaborative de la User Story peut faire appel à des techniques telles que le brainstorming et la cartographie mentale. La collaboration permet à l'équipe d'obtenir une vision commune de ce qui devrait être livré, en prenant en compte trois perspectives : celle du métier, celle du développement et celle du test.
Les bonnes User Story doivent être : Indépendantes, Négociables, apportant de la Valeur, Estimables, Petites et Testables (INVEST). Si une partie prenante ne sait pas comment tester une User Story, cela peut indiquer que la User Story n'est pas assez claire, qu'elle ne reflète pas quelque chose de valable pour elle, ou que la partie prenante a simplement besoin d'aide pour le test (Wake 2003).
5.2.	Critères d'acceptation
Les critères d'acceptation d'une User Story sont les conditions que doit remplir une implémentation de cette User Story pour être acceptée par les parties prenantes. De ce point de vue, les critères d'acceptation peuvent être considérés comme les conditions de test qui devraient être vérifiées par les tests. Les critères d'acceptation sont généralement le résultat de la conversation (voir section 1). 
Les critères d'acceptation sont utilisés pour :
·	Définir le périmètre de la User Story. 
·	Obtenir un consensus parmi les parties prenantes.
·	Décrire les scénarios positifs et négatifs. 
·	Servir de base aux tests d'acceptation des utilisateurs (voir section 5.3). 
·	Permettre une planification et une estimation précises. 
Il existe plusieurs façons de rédiger des critères d'acceptation pour une User Story. Les deux formats les plus courants sont:
·	Orienté-scénario (par exemple, le format Given/When/Then (Etant donné/Lorsque/Alors) utilisé par le BDD) 
·	Orienté vers les règles (par exemple, liste de vérification à puces, ou tableau de correspondance entrée-sortie). 
La plupart des critères d'acceptation peuvent être documentés dans l'un de ces deux formats. Cependant, l'équipe peut utiliser un autre format, personnalisé, tant que les critères d'acceptation sont bien définis et sans ambiguïté.
5.3.	Développement piloté par les tests d'acceptation (ATDD) 
L'ATDD est une approche pilotée par les tests. Les cas de test sont créés avant d'implémenter la User Story. Les cas de test sont créés par des membres de l'équipe ayant des perspectives différentes, par exemple des clients, des développeurs et des testeurs (Adzic 2009). Les cas de tests peuvent être exécutés manuellement ou de manière automatisée. 
La première étape est un atelier de spécification au cours duquel la User Story et (s'ils n'ont pas encore été définis) ses critères d'acceptation sont analysés, discutés et rédigés par les membres de l'équipe. Les lacunes, les ambiguïtés ou les défauts de la User Story sont résolus au cours de ce processus. L'étape suivante consiste à créer les cas de test. Cela peut être fait par l'équipe dans son ensemble ou par le testeur individuellement. Les cas de test sont basés sur les critères d'acceptation et peuvent être considérés comme des exemples du fonctionnement du logiciel. Ils aideront l'équipe à mettre en œuvre correctement la User Story.
Comme les exemples et les tests sont les mêmes, ces termes sont souvent utilisés de manière interchangeable. Lors de la conception des tests, les techniques de test décrites dans les sections 2, 3 et 4 peuvent être appliquées.
En général, les premiers cas de test sont positifs, confirmant le comportement correct sans exceptions ou conditions d'erreur, et comprennent la séquence d'activités exécutées si tout se passe comme prévu. Une fois les cas de test positifs réalisés, l'équipe doit effectuer des tests négatifs. Enfin, l'équipe doit également couvrir les caractéristiques non fonctionnelles de la qualité (par exemple, efficacité de la performance, utilisabilité). Les cas de test doivent être exprimés d'une manière compréhensible pour les parties prenantes. En règle générale, les cas de test contiennent des phrases en langage naturel comprenant les préconditions nécessaires (le cas échéant), les données d'entrée et les postconditions. 
Les cas de test doivent couvrir toutes les caractéristiques de la User Story et ne doivent pas aller au-delà. Cependant, les critères d'acceptation peuvent détailler certains des problèmes décrits dans la User Story. En outre, aucun cas de test ne doit décrire les mêmes caractéristiques de la User Story. 
Lorsqu'ils sont définis dans un format pris en charge par un framework d'automatisation des tests, les développeurs peuvent automatiser les cas de test en écrivant le code correspondant au fur et à mesure qu'ils implémentent la caractéristique décrite dans une User Story. Les tests d'acceptation deviennent alors des exigences exécutables.