« LeSS - Spécifications par l'exemple » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
|||
| (8 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 1 : | Ligne 1 : | ||
[[Category: Nicolas Mereaux]] | |||
[[Category: Portail LeSS]] | [[Category: Portail LeSS]] | ||
[[Catégorie:Tests]] | |||
[[Catégorie:TDD]] | |||
Auteur : The LeSS Company B.V.<br /> | |||
Source : [https://less.works/less/technical-excellence/specification-by-example.html Specification by Example - Large Scale Scrum (LeSS)]<br /> | |||
---- | ---- | ||
<span style="background-color: #ffffff">Traducteur : Nicolas Mereaux</span><br /> <span style="background-color: #ffffff">Date : 10/02/2018</span><br /> | <span style="background-color: #ffffff">Traducteur : Nicolas Mereaux</span><br /> <span style="background-color: #ffffff">Date : 10/02/2018</span><br /> | ||
| Ligne 14 : | Ligne 18 : | ||
* l’ingénierie concurrente | * l’ingénierie concurrente | ||
* plutôt prévenir que détecter | * plutôt prévenir que détecter | ||
<br /> '''Les tests en tant qu'exigences, les exigences en tant que tests''' : Dans l'ouvrage [http://www.amazon.fr/Exploring-Requirements-Quality-Before-Design/dp/0932633137 Exploring Requirements: Quality before Design], les auteurs Gause et Weinberg creusent le lien entre exigences et tests, “l’une des manières les plus efficaces pour tester les exigences est d’avoir des cas de tests ressemblant à ceux servant à tester un système complet”. [http://gmelnik.com/papers/Melnik-Martin-Tests-and-Requirements-The-Moebius-Strip-IEEE-Software-2008.pdf Melnik et Martin] étendent cette théorie plus loin en proclamant : “Au fur et à mesure de la montée en puissance du formalisme, les tests et les exigences deviennent impossible à distinguer l’un de l’autre. À la limite, les tests et les exigences sont équivalents”. Les tests doivent être précis afin d’être automatisables. Le développement piloté par les tests d’acceptation exploite ce formalisme et reformule les exigences à travers l’écriture de tests automatisables.<br /> <br /> L'''es ateliers pour clarifier les exigences''' : Le sixième principe agile nous rappelle que “La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.” Les ateliers de clarifications des exigences en face-à-face sont utilisés depuis l’invention du [http://www.amazon.fr/Joint-Application-Development-Jane-Wood/dp/0471042994 Joint Application Design (JAD)]. Ils sont aussi utilisés en [http://www.amazon.fr/Rapid-Application-Development-James-Martin/dp/0023767758 Rapid Application Development (RAD)] ainsi que dans la méthode agile [http://www.amazon.fr/DSDM-Dynamic-Systems-Development-Practice/dp/0201178893 DSDM]. Le développement piloté par les tests d’acceptation exploite de manière similaire les conversations en face-à-face dans les ateliers pour formaliser les exigences sous la forme de tests.<br /> <br /> '''L’ingénierie concurrente''' : Les auteurs de [http://www.amazon.com/Concurrent-Engineering-Effectiveness-Integrating-Organizations/dp/1569902313 Concurrent Engineering Effectiveness] définissent l’ingénierie concurrente ainsi : “Il existe un tel lien étroit entre les participants lors du processus de développement d’un produit, qu’ils accomplissent leur travail à peu près en même temps.” Le moteur principal de l’ingénierie concurrente est le raccourcissement du temps de développement. Avoir des itérations de deux semaines c’est court, l’équipe doit trouver par conséquent une manière de travailler de façon concurrente - développer de façon séquentielle sur une itération aussi courte ne marche pas. Nous avons vu des équipes inventer des spécifications par l’exemple encore et encore, simplement parce qu’elles devaient répondre à la question “Comment pouvons-nous accomplir notre travail en même temps.”<br /> <br /> '''Plutôt prévenir que détecter''' : Dans l’une des toutes premières études sur Toyota, [http://www.amazon.fr/Study-Toyota-Production-System-Engineering/dp/0915299178 A Study of the Toyota Production System], Singeo Shingo écrit : “L’objectif de l’inspection doit être la prévention ; toutefois, pour que l’inspection puisse avoir ce rôle, nous devons changer notre manière de penser.” De manière similaire, dans [http://www.clearspecs.com/downloads/ClearSpecs16V01_GrowthOfSoftwareTest.pdf “The Growth of Software Testing,”], les auteurs identifient cinq périodes distinctes dans l’évolution du test logiciel. Ils nomment la dernière période “La période orientée prévention” et affirme “Poser des questions relatives aux tests … le plus tôt possible est souvent plus important pour la qualité logicielle et la réduction des coûts de développement que le passage des tests proprement dit.” C’est exactement ce que s’efforce de faire les spécifications par l’exemple. Lorsque des testeurs sont présents lors d’ateliers sur les exigences, ils peuvent poser des questions relatives aux tests, et de cette manière améliorer les exigences et prévenir les anomalies. Le mouvement Qualité Totale - influencé par Toyota et le développement du lean - promeut aussi la prévention plutôt que la détection.<br /> <br /> Comment fonctionne l’A-TDD ? L’illustration ci-dessous permet d’en avoir un aperçu :<br /> [[Image:a-tdd%20overview-fr.png|a-tdd overview-fr.png]]<br /> <br /> <br /> <br /> | <br /> '''Les tests en tant qu'exigences, les exigences en tant que tests''' : Dans l'ouvrage [http://www.amazon.fr/Exploring-Requirements-Quality-Before-Design/dp/0932633137 Exploring Requirements: Quality before Design], les auteurs Gause et Weinberg creusent le lien entre exigences et tests, “l’une des manières les plus efficaces pour tester les exigences est d’avoir des cas de tests ressemblant à ceux servant à tester un système complet”. [http://gmelnik.com/papers/Melnik-Martin-Tests-and-Requirements-The-Moebius-Strip-IEEE-Software-2008.pdf Melnik et Martin] étendent cette théorie plus loin en proclamant : “Au fur et à mesure de la montée en puissance du formalisme, les tests et les exigences deviennent impossible à distinguer l’un de l’autre. À la limite, les tests et les exigences sont équivalents”. Les tests doivent être précis afin d’être automatisables. Le développement piloté par les tests d’acceptation exploite ce formalisme et reformule les exigences à travers l’écriture de tests automatisables.<br /> <br /> L'''es ateliers pour clarifier les exigences''' : Le sixième principe agile nous rappelle que “La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.” Les ateliers de clarifications des exigences en face-à-face sont utilisés depuis l’invention du [http://www.amazon.fr/Joint-Application-Development-Jane-Wood/dp/0471042994 Joint Application Design (JAD)]. Ils sont aussi utilisés en [http://www.amazon.fr/Rapid-Application-Development-James-Martin/dp/0023767758 Rapid Application Development (RAD)] ainsi que dans la méthode agile [http://www.amazon.fr/DSDM-Dynamic-Systems-Development-Practice/dp/0201178893 DSDM]. Le développement piloté par les tests d’acceptation exploite de manière similaire les conversations en face-à-face dans les ateliers pour formaliser les exigences sous la forme de tests.<br /> <br /> '''L’ingénierie concurrente''' : Les auteurs de [http://www.amazon.com/Concurrent-Engineering-Effectiveness-Integrating-Organizations/dp/1569902313 Concurrent Engineering Effectiveness] définissent l’ingénierie concurrente ainsi : “Il existe un tel lien étroit entre les participants lors du processus de développement d’un produit, qu’ils accomplissent leur travail à peu près en même temps.” Le moteur principal de l’ingénierie concurrente est le raccourcissement du temps de développement. Avoir des itérations de deux semaines c’est court, l’équipe doit trouver par conséquent une manière de travailler de façon concurrente - développer de façon séquentielle sur une itération aussi courte ne marche pas. Nous avons vu des équipes inventer des spécifications par l’exemple encore et encore, simplement parce qu’elles devaient répondre à la question “Comment pouvons-nous accomplir notre travail en même temps.”<br /> <br /> '''Plutôt prévenir que détecter''' : Dans l’une des toutes premières études sur Toyota, [http://www.amazon.fr/Study-Toyota-Production-System-Engineering/dp/0915299178 A Study of the Toyota Production System], Singeo Shingo écrit : “L’objectif de l’inspection doit être la prévention ; toutefois, pour que l’inspection puisse avoir ce rôle, nous devons changer notre manière de penser.” De manière similaire, dans [http://www.clearspecs.com/downloads/ClearSpecs16V01_GrowthOfSoftwareTest.pdf “The Growth of Software Testing,”], les auteurs identifient cinq périodes distinctes dans l’évolution du test logiciel. Ils nomment la dernière période “La période orientée prévention” et affirme “Poser des questions relatives aux tests … le plus tôt possible est souvent plus important pour la qualité logicielle et la réduction des coûts de développement que le passage des tests proprement dit.” C’est exactement ce que s’efforce de faire les spécifications par l’exemple. Lorsque des testeurs sont présents lors d’ateliers sur les exigences, ils peuvent poser des questions relatives aux tests, et de cette manière améliorer les exigences et prévenir les anomalies. Le mouvement Qualité Totale - influencé par Toyota et le développement du lean - promeut aussi la prévention plutôt que la détection.<br /> <br /> Comment fonctionne l’A-TDD ? L’illustration ci-dessous permet d’en avoir un aperçu :<br /> [[Image:a-tdd%20overview-fr.png|a-tdd overview-fr.png|link=]]<br /> <br /> <br /> <br /> | ||
==Aperçu du développement piloté par les tests d’acceptation== | ==Aperçu du développement piloté par les tests d’acceptation== | ||
<br /> Le développement piloté par les tests d’acceptation se déroule en trois étapes :<br /> | <br /> Le développement piloté par les tests d’acceptation se déroule en trois étapes :<br /> | ||
| Ligne 28 : | Ligne 32 : | ||
* écrire la documentation client des exigences | * écrire la documentation client des exigences | ||
* faire des tests exploratoires complémentaires | * faire des tests exploratoires complémentaires | ||
<br /> La liste exacte dépend du produit, du contexte, des conventions de travail et de la [[LeSS%20-%20La%20D%C3%A9finition%20du%20Fini|Définition du Fini (fr)]].<br /> <br /> '''Livrer''' : Lors du passage des tests, les exigences sont revues avec le Product Owner et d’autres parties prenantes. De nouvelles exigences peuvent ainsi naître ou amener à des changements au niveau des tests existants.<br /> <br /> L’illustration ci-dessous décrit plus en détails le développement piloté par les tests d’acceptation<br /> <br /> [[Image:a-tdd%20in%20more%20details-fr.png|a-tdd in more details-fr.png]]<br /> <br /> <br /> Les étapes pour que les développements pilotés par les tests d’acceptation s’intègrent harmonieusement dans le cycle LeSS :<br /> <br /> [[Image:a-tdd%20steps-fr.png|a-tdd steps-fr.png]]<br /> <br /> Intégration des étapes du développement piloté par les tests d’acceptation dans le cycle itératif Scrum.<br /> <br /> ''Discuter en atelier'' : Avant de faire une Planification du Sprint détaillée, l’équipe, le Product Owner, et les autres parties prenantes clarifient les exigences de manière collaborative lors d’un atelier.<br /> <br /> ''Développer de manière concurrente'' : Les tâches permettant d’implémenter les tests/exigences sont créées lors de la Planification du Sprint détaillée et implémentées lors de l’itération. Toutes les activités se déroulent “à peu près en même temps”.<br /> <br /> ''Livrer pour acceptation'' : L’incrément opérationnel du produit — les tests d’acceptation passants — sont livrés pour acceptation aux parties prenantes et discutés avec tous lors de la Revue de Sprint.<br /> <br /> | <br /> La liste exacte dépend du produit, du contexte, des conventions de travail et de la [[LeSS%20-%20La%20D%C3%A9finition%20du%20Fini|Définition du Fini (fr)]].<br /> <br /> '''Livrer''' : Lors du passage des tests, les exigences sont revues avec le Product Owner et d’autres parties prenantes. De nouvelles exigences peuvent ainsi naître ou amener à des changements au niveau des tests existants.<br /> <br /> L’illustration ci-dessous décrit plus en détails le développement piloté par les tests d’acceptation<br /> <br /> [[Image:a-tdd%20in%20more%20details-fr.png|a-tdd in more details-fr.png|link=]]<br /> <br /> <br /> Les étapes pour que les développements pilotés par les tests d’acceptation s’intègrent harmonieusement dans le cycle LeSS :<br /> <br /> [[Image:a-tdd%20steps-fr.png|a-tdd steps-fr.png|link=]]<br /> <br /> Intégration des étapes du développement piloté par les tests d’acceptation dans le cycle itératif Scrum.<br /> <br /> ''Discuter en atelier'' : Avant de faire une Planification du Sprint détaillée, l’équipe, le Product Owner, et les autres parties prenantes clarifient les exigences de manière collaborative lors d’un atelier.<br /> <br /> ''Développer de manière concurrente'' : Les tâches permettant d’implémenter les tests/exigences sont créées lors de la Planification du Sprint détaillée et implémentées lors de l’itération. Toutes les activités se déroulent “à peu près en même temps”.<br /> <br /> ''Livrer pour acceptation'' : L’incrément opérationnel du produit — les tests d’acceptation passants — sont livrés pour acceptation aux parties prenantes et discutés avec tous lors de la Revue de Sprint.<br /> <br /> | ||
==Discuter en atelier== | ==Discuter en atelier== | ||
<br /> Les expériences de ces ateliers sont profondément liées à celles citées dans le chapitre Exigences. Cette section couvre les sujets en rapport avec le développement piloté par les tests d’acceptation ; le chapitre Exigences couvre les ateliers sur les exigences plus en détails.<br /> | <br /> Les expériences de ces ateliers sont profondément liées à celles citées dans le chapitre Exigences. Cette section couvre les sujets en rapport avec le développement piloté par les tests d’acceptation ; le chapitre Exigences couvre les ateliers sur les exigences plus en détails.<br /> | ||
<br/> | |||
===Discuter en atelier lors de l’Affinage du Backlog de Produit=== | ===Discuter en atelier lors de l’Affinage du Backlog de Produit=== | ||
<br /> L’équipe et le Product Owner ‘inspecte’ le Backlog du Produit pendant l’[[LeSS%20-%20L%27Affinage%20du%20Backlog%20Produit|Affinage du Backlog Produit (fr)]] pour s’assurer que ce dernier semble correct. Cette activité comprend les éléments suivants :<br /> | <br /> L’équipe et le Product Owner ‘inspecte’ le Backlog du Produit pendant l’[[LeSS%20-%20L%27Affinage%20du%20Backlog%20Produit|Affinage du Backlog Produit (fr)]] pour s’assurer que ce dernier semble correct. Cette activité comprend les éléments suivants :<br /> | ||
| Ligne 45 : | Ligne 49 : | ||
<br /> Les gens sont souvent préoccupés par avoir des livrables tangibles lors d’un atelier - les tests - et ils oublient les effets intangibles - la connaissance. La compréhension et la clarté des exigences sont les livrables clés d’un atelier sur les exigences ; les tests en sont l’expression.<br /> <br /> Il ne s’agit pas d’une fausse dichotomie. Les tests sont importants et cette technique s’appelle le développement piloté par les tests d’acceptations. Sans tests, il s’agirait juste d’un atelier sur les exigences - mais cela permet d’éviter de confondre la fin avec les moyens.<br /> <br /> | <br /> Les gens sont souvent préoccupés par avoir des livrables tangibles lors d’un atelier - les tests - et ils oublient les effets intangibles - la connaissance. La compréhension et la clarté des exigences sont les livrables clés d’un atelier sur les exigences ; les tests en sont l’expression.<br /> <br /> Il ne s’agit pas d’une fausse dichotomie. Les tests sont importants et cette technique s’appelle le développement piloté par les tests d’acceptations. Sans tests, il s’agirait juste d’un atelier sur les exigences - mais cela permet d’éviter de confondre la fin avec les moyens.<br /> <br /> | ||
===Exemples d’utilisation=== | ===Exemples d’utilisation=== | ||
* ''“Pouvez-vous me donner un exemple ?”'' | |||
<br /> Cette question peut soudainement transformer une discussion vague et abstraite en une question claire et concrète. Lors de la discussion sur de nouveaux produits, les gens ont tendance à parler en termes abstraits et conceptuels. Ils débattent les uns avec les autres sans se comprendre - ils restent bloqués. Demander des exemples ramène la discussion à la réalité.<br /> <br /> Par exemple, nous entendons des affirmations telles que “Le système doit se remettre des situations d’erreurs”. C’est plutôt vague, nous demandons donc des exemples qui vont modifier la discussion. Cela pourrait être “Lorsque nous débranchons le câble, le système ne devrait pas tomber en panne” - ce qui est plus concret et plus compréhensible. Les exemples sont aussi utilisés pour avoir davantage de clarifications, tels que, “Comment le système devra t’il se remettre si nous enlevons une unité du système lorsque celui-ci est en train de marcher ?”.<br /> <br /> Examples are not just useful for clarifying requirements but also for clarifying ways of working. “We could never automate all our tests!” is something we would follow up with “Can you give me an example of a non-automatable test?” and that moves the discussion away from principle and into practice.<br /> <br /> Les exemples ne sont pas seulement utiles pour clarifier les exigences mais aussi pour clarifier les manières de travailler. “Nous ne pourrons jamais automatiser tous nos tests !” est une phrase à laquelle nous devrions répondre par “Pouvez-vous me donner un exemple d’un test non-automatisable ?” et ainsi progressivement déplacer le sujet de la discussion du principe vers la pratique.<br /> <br /> [[Image:a-tdd%20examples-fr.png|a-tdd examples-fr.png|link=]]<br /> <br /> L’illustration ci-dessus montre les relations entre les exemples, les exigences et les tests. Lors des ateliers sur les exigences, l’utilisation des exemples pour élaborer les exigences et les transformer en tests.<br /> | |||
<br/> | |||
==="N'optimisez" pas l’atelier sur les exigences=== | ==="N'optimisez" pas l’atelier sur les exigences=== | ||
<br /> Alors que nous étions en train de discuter d’A-TDD avec un groupe produit important, ce dernier a noté, “Nous avons amélioré l’atelier d’A-TDD. Seules trois personnes y participent : le Product Owner, le Scrum Master, et un spécialiste de l’équipe”. Nous leur avons demandé comment les autres membres de l’équipe pourraient être en mesure comprendre les exigences afin de pouvoir les implémenter et la réponse fut “Le spécialiste leur dira”. Ils ont ‘optimisé’ l’atelier en réintroduisant le traditionnel transfert de connaissance analyste-équipe comme avant.<br /> <br /> | <br /> Alors que nous étions en train de discuter d’A-TDD avec un groupe produit important, ce dernier a noté, “Nous avons amélioré l’atelier d’A-TDD. Seules trois personnes y participent : le Product Owner, le Scrum Master, et un spécialiste de l’équipe”. Nous leur avons demandé comment les autres membres de l’équipe pourraient être en mesure comprendre les exigences afin de pouvoir les implémenter et la réponse fut “Le spécialiste leur dira”. Ils ont ‘optimisé’ l’atelier en réintroduisant le traditionnel transfert de connaissance analyste-équipe comme avant.<br /> <br /> | ||
===Éviter d’utiliser des ordinateurs et des projecteurs lors d’un atelier=== | ===Éviter d’utiliser des ordinateurs et des projecteurs lors d’un atelier=== | ||
<br /> Les ordinateurs pompent l’énergie vitale des ateliers. Ils deviennent le centre de la discussion. À part pour vérifier certaines informations, éviter donc d’avoir le besoin d’‘optimiser l’atelier en travaillant directement sur ordinateur. À la place …<br /> | <br /> Les ordinateurs pompent l’énergie vitale des ateliers. Ils deviennent le centre de la discussion. À part pour vérifier certaines informations, éviter donc d’avoir le besoin d’‘optimiser l’atelier en travaillant directement sur ordinateur. À la place …<br /> | ||
<br/> | |||
===Condenser le flux de travail en règles métiers=== | ===Condenser le flux de travail en règles métiers=== | ||
<br /> La clarification des exigences lors des ateliers commence souvent avec des concepts abstraits, et puis lorsque des exemples sont mis sur la table, la focale de la discussion se déplace vers des discussions sur le flux de travail - “Lorsque j’utilise le système, je fais l’étape un, puis l’étape deux, et je m’attends à obtenir comme résultat X.”.<br /> <br /> Il peut arriver que ces exemples de flux de travail soient similaires à l’exception de quelques variations sur une ou deux étapes. Les tests des flux de travail contiennent des règles métiers cachées, qui peuvent être extraites et insérées dans un test orienté données. Cela recentre la discussion sur la clarification du domaine et permet de réduire la complexité en supprimant des détails superflus.<br /> | <br /> La clarification des exigences lors des ateliers commence souvent avec des concepts abstraits, et puis lorsque des exemples sont mis sur la table, la focale de la discussion se déplace vers des discussions sur le flux de travail - “Lorsque j’utilise le système, je fais l’étape un, puis l’étape deux, et je m’attends à obtenir comme résultat X.”.<br /> <br /> Il peut arriver que ces exemples de flux de travail soient similaires à l’exception de quelques variations sur une ou deux étapes. Les tests des flux de travail contiennent des règles métiers cachées, qui peuvent être extraites et insérées dans un test orienté données. Cela recentre la discussion sur la clarification du domaine et permet de réduire la complexité en supprimant des détails superflus.<br /> | ||
<br/> | |||
===Des tests sur les murs=== | ===Des tests sur les murs=== | ||
<br /> L’endroit idéal pour les tests c’est sur le mur - euh, du moins avec un tableau blanc entre les tests et le mur. Ce qui est écrit ou dessiné sur le tableau blanc sont enregistrés à l’aide de photos. Après l’atelier, les tests peuvent être distillés et retranscrits dans un outil.<br /> <br /> [[Image:a-tdd%20testwall1.jpg|a-tdd testwall1.jpg]]<br /> <br /> [[Image:a-tdd%20test-wall2.jpg|a-tdd test-wall2.jpg]]<br /> | <br /> L’endroit idéal pour les tests c’est sur le mur - euh, du moins avec un tableau blanc entre les tests et le mur. Ce qui est écrit ou dessiné sur le tableau blanc sont enregistrés à l’aide de photos. Après l’atelier, les tests peuvent être distillés et retranscrits dans un outil.<br /> <br /> [[Image:a-tdd%20testwall1.jpg|a-tdd testwall1.jpg|link=]]<br /> <br /> [[Image:a-tdd%20test-wall2.jpg|a-tdd test-wall2.jpg|link=]]<br /> | ||
<br/> | |||
===De l’utilisation du format table=== | ===De l’utilisation du format table=== | ||
<br /> Exprimer des règles métiers sous la forme de tables permet de les rendre plus compréhensibles et aident à trouver des cas manquants. Les tables encouragent la clarté de la réflexion. [http://link.springer.com/chapter/10.1007/978-3-7091-6510-2_12#page-1 David Parnas, expert en informatique est un promoteur de longue date] de l’utilisation des tables dans la documentation des exigences.<br /> | <br /> Exprimer des règles métiers sous la forme de tables permet de les rendre plus compréhensibles et aident à trouver des cas manquants. Les tables encouragent la clarté de la réflexion. [http://link.springer.com/chapter/10.1007/978-3-7091-6510-2_12#page-1 David Parnas, expert en informatique est un promoteur de longue date] de l’utilisation des tables dans la documentation des exigences.<br /> | ||
| Ligne 69 : | Ligne 72 : | ||
===De l’utilisation des tests de flux de travail=== | ===De l’utilisation des tests de flux de travail=== | ||
<br /> Récupérer les règles métiers et faire des tests pilotés par les données ne peut pas toujours se faire ni même s’avérer souhaitable. Certaines exigences s’avèrent tout simplement bien mieux exprimées sous la forme de l’exemple d’un flux de travail (un scénario comportant plusieurs étapes). Les tests des règles métiers pilotés par les données peuvent souvent être complétés par des exemples de flux de travail qui, en un certain sens, permettent de les relier.<br /> <br /> Attention : lorsque la plupart de vos tests sont des tests de flux de travail, alors il est très probable que vous ayez manqué certaines règles métiers<br /> | <br /> Récupérer les règles métiers et faire des tests pilotés par les données ne peut pas toujours se faire ni même s’avérer souhaitable. Certaines exigences s’avèrent tout simplement bien mieux exprimées sous la forme de l’exemple d’un flux de travail (un scénario comportant plusieurs étapes). Les tests des règles métiers pilotés par les données peuvent souvent être complétés par des exemples de flux de travail qui, en un certain sens, permettent de les relier.<br /> <br /> Attention : lorsque la plupart de vos tests sont des tests de flux de travail, alors il est très probable que vous ayez manqué certaines règles métiers<br /> | ||
<br/> | |||
===Agenda type d’atelier=== | ===Agenda type d’atelier=== | ||
<br /> Comment se structure un atelier A-TDD sur les exigences ? Nous suivons fréquemment l’agenda suivant :<br /> | <br /> Comment se structure un atelier A-TDD sur les exigences ? Nous suivons fréquemment l’agenda suivant :<br /> | ||
| Ligne 84 : | Ligne 87 : | ||
==Développer de manière concurrente== | ==Développer de manière concurrente== | ||
<br /> Après que les exigences aient été éclaircies, elles doivent être implémentées. Les différentes activités nécessaires à l’implémentation sont faites de manière concurrente. En même temps, l’équipe étoffe les tests tout en implémentant le code, en écrivant la documentation, en mettant à jour la description de la conception, et ainsi de suite.<br /> | <br /> Après que les exigences aient été éclaircies, elles doivent être implémentées. Les différentes activités nécessaires à l’implémentation sont faites de manière concurrente. En même temps, l’équipe étoffe les tests tout en implémentant le code, en écrivant la documentation, en mettant à jour la description de la conception, et ainsi de suite.<br /> | ||
<br/> | |||
===Distiller les tests=== | ===Distiller les tests=== | ||
<br /> De nombreux exemples sont créés pendant l’atelier sur les exigences. Tous les exemples ne deviennent pas des tests - seuls les éléments essentiels des exigences sont distillés sous la forme de tests. Les éléments non essentiels ou en doublons sont écartés - ils ont rempli leurs rôles pendant l’atelier d’accroissement des connaissances.<br /> <br /> Comment à partir des exemples en distiller des tests ? Voici quelques techniques :<br /> <br /> | <br /> De nombreux exemples sont créés pendant l’atelier sur les exigences. Tous les exemples ne deviennent pas des tests - seuls les éléments essentiels des exigences sont distillés sous la forme de tests. Les éléments non essentiels ou en doublons sont écartés - ils ont rempli leurs rôles pendant l’atelier d’accroissement des connaissances.<br /> <br /> Comment à partir des exemples en distiller des tests ? Voici quelques techniques :<br /> <br /> | ||
| Ligne 91 : | Ligne 94 : | ||
* '''Classe d’équivalence''' — Certains exemples font partie de la même classe d’équivalence et donc un seul test peut s’avérer suffisant. La présence de testeurs spécialisés est tout spécialement bienvenue, étant donné que le partitionnement par classe d’équivalence est une technique de tests classique. | * '''Classe d’équivalence''' — Certains exemples font partie de la même classe d’équivalence et donc un seul test peut s’avérer suffisant. La présence de testeurs spécialisés est tout spécialement bienvenue, étant donné que le partitionnement par classe d’équivalence est une technique de tests classique. | ||
* '''Acceptation''' - Étant donné que tous les exemples ne sont pas d’égale importance, il convient de demander au Product Owner “Quels sont les exemples que vous voulez voir fonctionner à la fin de l’itération ?” | * '''Acceptation''' - Étant donné que tous les exemples ne sont pas d’égale importance, il convient de demander au Product Owner “Quels sont les exemples que vous voulez voir fonctionner à la fin de l’itération ?” | ||
<br/> | |||
===Faites-vous accompagner de facilitateurs et de coachs spécialisées en A-TDD=== | ===Faites-vous accompagner de facilitateurs et de coachs spécialisées en A-TDD=== | ||
<br /> L’A-TDD est facile à faire, et difficile à adopter. Cela exige de remettre en question des postulats ancrés profondément et des changements d’habitudes. Un coach (externe) ayant de l’expérience en A-TDD et en changements organisationnels s’avèrent souvent nécessaire pour l’adopter. Trouvez un coach.<br /> <br /> Il est important de réaliser que les compétences d’un bon coach en A-TDD sont différentes de celles d’un bon coach en TDD. Le coaching en TDD est davantage technique, et davantage focalisé sur les développeurs, alors que l’A-TDD concerne toute l’équipe. En plus d’avoir des compétences techniques, un bon coach en A-TDD possède aussi d’excellentes compétences en facilitation d’ateliers.<br /> | <br /> L’A-TDD est facile à faire, et difficile à adopter. Cela exige de remettre en question des postulats ancrés profondément et des changements d’habitudes. Un coach (externe) ayant de l’expérience en A-TDD et en changements organisationnels s’avèrent souvent nécessaire pour l’adopter. Trouvez un coach.<br /> <br /> Il est important de réaliser que les compétences d’un bon coach en A-TDD sont différentes de celles d’un bon coach en TDD. Le coaching en TDD est davantage technique, et davantage focalisé sur les développeurs, alors que l’A-TDD concerne toute l’équipe. En plus d’avoir des compétences techniques, un bon coach en A-TDD possède aussi d’excellentes compétences en facilitation d’ateliers.<br /> | ||
<br/> | |||
===Utiliser un outil d’A-TDD=== | ===Utiliser un outil d’A-TDD=== | ||
<br /> | <br /> | ||
| Ligne 104 : | Ligne 107 : | ||
===N’utilisez pas les outils conventionnels pour faire du développement piloté par les tests d’acceptation=== | ===N’utilisez pas les outils conventionnels pour faire du développement piloté par les tests d’acceptation=== | ||
<br /> Some product groups we worked with try to use their conventional test tools such as Lisp-based scripts or TTCN for A-TDD. This invariably fails. Why? A-TDD-style tests are created so that the Product Owner or user can read and understand the tests. But the test format—scripts—of these conventional tools are created for testers and are thus unsuitable for documenting requirements. It is nearly impossible to involve the Product Owner in writing examples using such tools.<br /> <br /> Certains des groupes de produits avec lesquels nous travaillons essayent d’utiliser des outils de tests conventionnels tels que des scripts en Lisp ou des notations de tests et de contrôle de tests (NdT : pour plus d’informations sur ces notations consultez https://fr.wikipedia.org/wiki/TTCN) adapté à l’A-TDD. Tout cela échoue invariablement. Pourquoi ? Le style des tests pour l’A-TDD est fait afin que le Product Owner ou que l’utilisateur puisse lire et comprendre les tests. Mais le format de type des scripts des tests de ces outils conventionnels sont faits pour un testeur professionnel et s’avère donc inapproprié pour la documentation d’exigences. Il est presque impossible d’impliquer le Product Owner dans la rédaction d’exemples avec de tels outils.<br /> | <br /> Some product groups we worked with try to use their conventional test tools such as Lisp-based scripts or TTCN for A-TDD. This invariably fails. Why? A-TDD-style tests are created so that the Product Owner or user can read and understand the tests. But the test format—scripts—of these conventional tools are created for testers and are thus unsuitable for documenting requirements. It is nearly impossible to involve the Product Owner in writing examples using such tools.<br /> <br /> Certains des groupes de produits avec lesquels nous travaillons essayent d’utiliser des outils de tests conventionnels tels que des scripts en Lisp ou des notations de tests et de contrôle de tests (NdT : pour plus d’informations sur ces notations consultez https://fr.wikipedia.org/wiki/TTCN) adapté à l’A-TDD. Tout cela échoue invariablement. Pourquoi ? Le style des tests pour l’A-TDD est fait afin que le Product Owner ou que l’utilisateur puisse lire et comprendre les tests. Mais le format de type des scripts des tests de ces outils conventionnels sont faits pour un testeur professionnel et s’avère donc inapproprié pour la documentation d’exigences. Il est presque impossible d’impliquer le Product Owner dans la rédaction d’exemples avec de tels outils.<br /> | ||
<br/> | |||
===Mais à la place utilisez un outil dédié à l’A-TDD qui servira d’intermédiaire aux outils de tests conventionnels=== | ===Mais à la place utilisez un outil dédié à l’A-TDD qui servira d’intermédiaire aux outils de tests conventionnels=== | ||
<br /> Devez-vous abandonner tous les outils conventionnels de tests lorsque vous adoptez l’A-TDD ? Peut-être pas.<br /> <br /> Un groupe de produits, dédié aux graphismes, avec lequel nous avons travaillé avait passé plusieurs années à mettre en place un langage de scripts afin d’automatiser leurs tests. Cela devrait leur prendre quelques années de plus pour développer du code permettant de faire le liant (bibliothèques de tests ou fixtures) entre le framework A-TDD et leur système en tests - d’ailleurs la majeure partie de ce code sera du même acabit que ce qu’ils ont pu faire avec leur langage de scripts.<br /> <br /> Une alternative est de laisser le code faisant le liant d’englober leur langage de scripts et ainsi de réutiliser le travail déjà fait. Les outils conventionnels de tests ne sont pas nécessairement de mauvais outils, mais simplement ils fournissent le mauvais format - le mauvais langage - permettant d’avoir des spécifications exécutables.<br /> <br /> | <br /> Devez-vous abandonner tous les outils conventionnels de tests lorsque vous adoptez l’A-TDD ? Peut-être pas.<br /> <br /> Un groupe de produits, dédié aux graphismes, avec lequel nous avons travaillé avait passé plusieurs années à mettre en place un langage de scripts afin d’automatiser leurs tests. Cela devrait leur prendre quelques années de plus pour développer du code permettant de faire le liant (bibliothèques de tests ou fixtures) entre le framework A-TDD et leur système en tests - d’ailleurs la majeure partie de ce code sera du même acabit que ce qu’ils ont pu faire avec leur langage de scripts.<br /> <br /> Une alternative est de laisser le code faisant le liant d’englober leur langage de scripts et ainsi de réutiliser le travail déjà fait. Les outils conventionnels de tests ne sont pas nécessairement de mauvais outils, mais simplement ils fournissent le mauvais format - le mauvais langage - permettant d’avoir des spécifications exécutables.<br /> <br /> | ||
==Livrer pour acceptation== | ==Livrer pour acceptation== | ||
<br /> Le code est implémenté et tous les tests passent. Et ensuite ? Le cycle d’A-TDD, comme celui de Scrum, renferme un cycle d’inspection-adaptation dans lequel les résultats sont livrés aux parties prenantes, qui en inspectent les effets à travers les tests et qui décident comment procéder - quelles exigences seront implémentées par la suite.<br /> | <br /> Le code est implémenté et tous les tests passent. Et ensuite ? Le cycle d’A-TDD, comme celui de Scrum, renferme un cycle d’inspection-adaptation dans lequel les résultats sont livrés aux parties prenantes, qui en inspectent les effets à travers les tests et qui décident comment procéder - quelles exigences seront implémentées par la suite.<br /> | ||
<br/> | |||
===Montrer les tests lors de la Revue de Sprint=== | ===Montrer les tests lors de la Revue de Sprint=== | ||
<br /> Lors d’une Revue de Sprint, l’équipe démontre des progrès visibles au Product Owner en montrant ce qui a été produit lors de l’itération.<br /> <br /> Nous avons travaillé avec certains groupes pour définir les étapes de la démo pendant la Planification du Sprint. Une équipe passait un temps disproportionné en préparation de démo. Un gaspillage total.<br /> <br /> Lors de la Planification du Sprint, une alternative possible est de définir les exemples qui doivent passer et montrer les progrès en utilisant les tests lors de la Revue de Sprint.<br /> | <br /> Lors d’une Revue de Sprint, l’équipe démontre des progrès visibles au Product Owner en montrant ce qui a été produit lors de l’itération.<br /> <br /> Nous avons travaillé avec certains groupes pour définir les étapes de la démo pendant la Planification du Sprint. Une équipe passait un temps disproportionné en préparation de démo. Un gaspillage total.<br /> <br /> Lors de la Planification du Sprint, une alternative possible est de définir les exemples qui doivent passer et montrer les progrès en utilisant les tests lors de la Revue de Sprint.<br /> | ||
<br/> | |||
==Ouvrages recommandés== | ==Ouvrages recommandés== | ||
* [https://www.amazon.fr/Specification-Example-Gojko-Adzic/dp/1617290084 Specification by Example] de Gojko Adzic. Ce livre aborde plusieurs études de cas de “spécifications par l’exemple”. Gojko a inventé ce terme afin de remplacer tous les précédents termes comme l’A-TDD. | * [https://www.amazon.fr/Specification-Example-Gojko-Adzic/dp/1617290084 Specification by Example] de Gojko Adzic. Ce livre aborde plusieurs études de cas de “spécifications par l’exemple”. Gojko a inventé ce terme afin de remplacer tous les précédents termes comme l’A-TDD. | ||
* [https://www.amazon.fr/Bridging-Communication-Gap-Specification-Acceptance/dp/0955683610/ Bridging the Communication Gap] de Gojko Adzic. Ce livre précède l’ouvrage Specification by Example et se concentre plus particulièrement sur la clarification des exigences et sur les ateliers. | * [https://www.amazon.fr/Bridging-Communication-Gap-Specification-Acceptance/dp/0955683610/ Bridging the Communication Gap] de Gojko Adzic. Ce livre précède l’ouvrage Specification by Example et se concentre plus particulièrement sur la clarification des exigences et sur les ateliers. | ||
| Ligne 122 : | Ligne 123 : | ||
* [http://robotframework.org/robotframework/latest/RobotFrameworkUserGuide.html Robot Framework User Guide]. Ce guide n’aborde pas en tant que tel l’A-TDD mais donne une excellent introduction sur l’outil Robot Framework. | * [http://robotframework.org/robotframework/latest/RobotFrameworkUserGuide.html Robot Framework User Guide]. Ce guide n’aborde pas en tant que tel l’A-TDD mais donne une excellent introduction sur l’outil Robot Framework. | ||
* [https://www.amazon.fr/Test-Driven-NET-Development-FitNesse/dp/0955683602 Test-Driven .NET Development with FitNesse] de Gojko Adzic. Ce livre met moins l’emphase sur l’A-TDD et davantage sur FitNesse. Il offre néanmoins une bonne description de l’outil. | * [https://www.amazon.fr/Test-Driven-NET-Development-FitNesse/dp/0955683602 Test-Driven .NET Development with FitNesse] de Gojko Adzic. Ce livre met moins l’emphase sur l’A-TDD et davantage sur FitNesse. Il offre néanmoins une bonne description de l’outil. | ||
