« LeSS - Tests d'Acceptation » : différence entre les versions

De Wiki Agile
Aller à la navigation Aller à la recherche
← Modification précédente
VisuelWikicode
Aucun résumé des modifications
 
(8 versions intermédiaires par le même utilisateur non affichées)
Ligne 1 : Ligne 1 :
Auteur : The LeSS Company B.V.
[[Category: Nicolas Mereaux]]
 
[[Catégorie:Tests]]
Source : [https://less.works/less/technical-excellence/acceptance-testing.html Acceptance Testing]
[[Catégorie:TDD]]
 
Auteur : The LeSS Company B.V.<br/>
Source : [https://less.works/less/technical-excellence/acceptance-testing.html Acceptance Testing]<br/>
<hr/>
<hr/>
 
Traducteur : Nicolas Mereaux<br/>
Traducteur : Nicolas Mereaux
Relecture : Fabrice Aimetti<br/>
 
Date : 09/01/2019<br/>
Relecture : Fabrice Aimetti
 
Date : /01/2018
 
<hr/>
<hr/>
Traduction :
Traduction :<br/>
 
<br/>
 
[[LeSS - Portail Excellence technique]]<br/>
== Don’t confusing acceptance and user-acceptance test ==
 
== Ne confondez pas tests d'acceptation et tests d'acceptation utilisateur ==
== Ne confondez pas tests d'acceptation et tests d'acceptation utilisateur ==
 
Dans l'idéal, les tests d'acceptation et les tests d'acceptation utilisateur sont identiques, mais … la littérature du développement Agile utilise le terme de « tests d'acceptation » là où nous utilisons le terme de « tests avec les utilisateurs ». Toutefois, en développement traditionnel, les « tests d'acceptation » veulent souvent dire « tests d'acceptation utilisateur » ce qui pourrait s'avérer différents. Évitons donc les malentendus.<br/>
In the ideal situation, acceptance test and user-acceptance test are the same, but… Agile development literature uses the term “acceptance tests,” where we use the term “customer-facing tests.” However, in traditional development, “acceptance test” often means “user-acceptance test,” which might be different. Avoid misunderstandings.
<br/>
 
[[Fichier:Less-xacceptance vs uat-fr.png|border|400px|link=]]<br/>
Dans l'idéal, les tests d'acceptation et les tests d'acceptation utilisateur sont identiques, mais … la littérature du développement Agile utilise le terme de « tests d'acceptation » là où nous utilisons le terme de « tests orientés utilisateur ». Toutefois, en développement traditionnel, les « tests d'acceptation » veulent souvent dire « tests d'acceptation utilisateur » ce qui pourrait s'avérer différents. Évitons donc les malentendus.
Illustration 1 : Les tests d'acceptation utilisateur sont un sous-ensemble des tests d'acceptation<br/>
 
<br/>
[[Fichier:Less-xacceptance vs uat-en.png|vignette|UAT is a subset of acceptance tests]]
L'illustration ci-dessus montre ce qui relie ces 2 types de tests. Les tests d'acceptation utilisateur (TAU) ne sont qu'une partie des tests d'acceptation en développement agile. Mais les tests d'acceptation peuvent aussi inclure des tests qui ne soient pas des tests d'acceptations utilisateur tel que les traditionnels tests fonctionnels ou les tests systèmes faits par l'équipe.<br/>
 
<br/>
[[Fichier:Less-xacceptance vs uat-fr.png|vignette|Les tests d'acceptation utilisateur sont un sous-ensemble des tests d'acceptation]]
Idéalement, tous les tests d'acceptation - y compris les tests d'acceptation utilisateurs - sont faits dans l'itération. Toutefois, faire les tests d'acceptation utilisateur dans l'itération peut s'avérer difficile parce que cela demande une implication active de l'utilisateur final et tous les utilisateurs finaux ne sont pas prêts à ça. Dans ce cas, les tests d'acceptation utilisateur sont exclus de la Définition du Fini jusqu'à ce que le groupe produit améliore sa relation avec l'utilisateur final afin qu'il puisse étendre sa Définition du Fini.<br/>
 
Diagram 1: UAT is a subset of acceptance tests
 
Illustration 1 : Les tests d'acceptation utilisateur sont un sous-ensemble des tests d'acceptation
 
The above figure expresses the relationship in a diagram. User-acceptance test (UAT) is a part of acceptance testing in agile development. But acceptance test might also include non-UAT tests such as traditional functional or system test created by the team.
 
L'illustration ci-dessus montre ce qui relie ces 2 types de tests. Les tests d'acceptation utilisateur (TAU) ne sont qu'une partie des tests d'acceptation en développement agile. Mais les tests d'acceptation peuvent aussi inclure des tests qui ne soient pas des tests d'acceptations utilisateur tel que les traditionnels tests fonctionnels ou les tests systèmes faits par l'équipe.
 
Ideally, all the acceptance testing—including UAT—is done within the iteration. However, getting the UAT in the iteration may be difficult because it requires active end-user involvement and not all customers are ready for that. In that case, UAT is excluded from the Definition of Done until the product group improves their relationship with the customer so that they can expand their Definition of Done.
 
Idéalement, tous les tests d'acceptation - y compris les tests d'acceptation utilisateurs - sont faits dans l'itération. Toutefois, faire les tests d'acceptation utilisateur dans l'itération peut s'avérer difficile parce que cela demande une implication active de l'utilisateur final et tous les utilisateurs finaux ne sont pas prêts à ça. Dans ce cas, les tests d'acceptation utilisateur sont exclus de la Définition du Fini jusqu'à ce que le groupe produit améliore sa relation avec l'utilisateur final afin qu'il puisse étendre sa Définition du Fini.
 
== Show tests in Sprint Review ==


== Montrer les tests en Revue de Sprint ==
== Montrer les tests en Revue de Sprint ==
 
Lors d'une [[LeSS - La Revue de Sprint|Revue de Sprint (fr)]], l'équipe montre des avancées visibles au Product Owner en montrant ce qui a été produit pendant l'itération.<br/>
In a [https://less.works/less/framework/sprint-review.html Sprint Review], the team demonstrates visible progress to the Product Owner by showing the output of the iteration.
<br/>
 
Certains des groupes avec lesquels nous avons travaillé préparaient à l'avance les différentes étapes  de la démo pendant la Planification de Sprint. Dans ces cas-là, l'équipe passe un temps démesuré en préparation de démo. Un véritable gâchis.<br/>
Lors d'une [[LeSS - La Revue de Sprint|Revue de Sprint]], l'équipe montre des avancées visibles au Product Owner en montrant ce qui a été produit pendant l'itération.
<br/>
 
Lors de la [[LeSS - La Planification du Sprint (1ère partie)|Planification du Sprint (fr)]], une alternative possible est de définir les exemples passants et montrer l'avancement des travaux en utilisant ces tests lors de la Revue du Sprint.<br/>
We worked with some groups that defined the demo steps during the Sprint planning. The team would spend an inordinate amount of time in demo preparation. A complete waste.
 
Certains des groupes avec lesquels nous avons travaillé préparaient à l'avance les différentes étapes  de la démo pendant la Planification de Sprint. Dans ces cas-là, l'équipe passe un temps démesuré en préparation de démo. Un véritable gâchis.
 
During [https://less.works/less/framework/sprint-planning-one.html Sprint Planning], an alternative is to define the examples that need to pass and show the progress by using these tests in the Sprint Review.
 
Lors de la [[LeSS - La Planification du Sprint (1ère partie)|Planification du Sprint]], une alternative possible est de définir les exemples passants et montrer l'avancement des travaux en utilisant ces tests lors de la Revue du Sprint.
 
== Use acceptance test-driven development ==


== Utiliser le développement piloté par les tests d'acceptation ==
== Utiliser le développement piloté par les tests d'acceptation ==
 
[[LeSS - Spécifications par l'exemple|Le développement piloté par les tests d'acceptation (A-TDD) ou Spécifications par l'exemple (fr)]] est une approche collaborative de découverte des exigences dans laquelle des exemples et des tests automatisés sont utilisés pour spécifier les exigences, créant ainsi des spécifications exécutables. Elles sont créées conjointement par l'équipe, le Product Owner, et les autres parties prenantes lors d'ateliers d'exigences.
[https://less.works/less/technical-excellence/specification-by-example.html Acceptance test-driven development (A-TDD) or Specification by Example] is a collaborative requirements discovery approach where examples and automatable tests are used for specifying requirements—creating executable specifications. These are created with the team, Product Owner, and other stakeholders in requirements workshops.
 
[[LeSS - Spécifications par l'exemple|Le développment piloté par les tests d'acceptation (A-TDD) ou Spécifications par l'exemple]] est une approche collaborative de découverte des exigences dans laquelle des exemples et des tests automatisés sont utilisés pour spécifier les exigences, créant ainsi des spécifications exécutables. Elles sont créées conjointement par l'équipe, le Product Owner, et les autres parties prenantes lors d'ateliers d'exigences.

Dernière version du 13 mai 2020 à 15:49

Auteur : The LeSS Company B.V.
Source : Acceptance Testing

Traducteur : Nicolas Mereaux
Relecture : Fabrice Aimetti
Date : 09/01/2019

Traduction :

LeSS - Portail Excellence technique

Ne confondez pas tests d'acceptation et tests d'acceptation utilisateur

Dans l'idéal, les tests d'acceptation et les tests d'acceptation utilisateur sont identiques, mais … la littérature du développement Agile utilise le terme de « tests d'acceptation » là où nous utilisons le terme de « tests avec les utilisateurs ». Toutefois, en développement traditionnel, les « tests d'acceptation » veulent souvent dire « tests d'acceptation utilisateur » ce qui pourrait s'avérer différents. Évitons donc les malentendus.


Illustration 1 : Les tests d'acceptation utilisateur sont un sous-ensemble des tests d'acceptation

L'illustration ci-dessus montre ce qui relie ces 2 types de tests. Les tests d'acceptation utilisateur (TAU) ne sont qu'une partie des tests d'acceptation en développement agile. Mais les tests d'acceptation peuvent aussi inclure des tests qui ne soient pas des tests d'acceptations utilisateur tel que les traditionnels tests fonctionnels ou les tests systèmes faits par l'équipe.

Idéalement, tous les tests d'acceptation - y compris les tests d'acceptation utilisateurs - sont faits dans l'itération. Toutefois, faire les tests d'acceptation utilisateur dans l'itération peut s'avérer difficile parce que cela demande une implication active de l'utilisateur final et tous les utilisateurs finaux ne sont pas prêts à ça. Dans ce cas, les tests d'acceptation utilisateur sont exclus de la Définition du Fini jusqu'à ce que le groupe produit améliore sa relation avec l'utilisateur final afin qu'il puisse étendre sa Définition du Fini.

Montrer les tests en Revue de Sprint

Lors d'une Revue de Sprint (fr), l'équipe montre des avancées visibles au Product Owner en montrant ce qui a été produit pendant l'itération.

Certains des groupes avec lesquels nous avons travaillé préparaient à l'avance les différentes étapes de la démo pendant la Planification de Sprint. Dans ces cas-là, l'équipe passe un temps démesuré en préparation de démo. Un véritable gâchis.

Lors de la Planification du Sprint (fr), une alternative possible est de définir les exemples passants et montrer l'avancement des travaux en utilisant ces tests lors de la Revue du Sprint.

Utiliser le développement piloté par les tests d'acceptation

Le développement piloté par les tests d'acceptation (A-TDD) ou Spécifications par l'exemple (fr) est une approche collaborative de découverte des exigences dans laquelle des exemples et des tests automatisés sont utilisés pour spécifier les exigences, créant ainsi des spécifications exécutables. Elles sont créées conjointement par l'équipe, le Product Owner, et les autres parties prenantes lors d'ateliers d'exigences.

Récupérée de "https://wikiagile.coach/index.php?title=LeSS_-_Tests_d%27Acceptation&oldid=13547"