Spécification par lexempleSpécification par lexempleArnaud Bailly ­ Jonathan Perret13 octobre 2011Plan      15: Principes ...
Des tests orienté­métier pour soutenir léquipe   Tests définis du point de vue de lusage du produit, des utilisateurs   Ex...
La Spécification par lexemple      "Pour établir une pratique, les règles ne suffisent pas; on a également besoin dexemple...
Cest à vous de travailler !Faire vivre le produit     Mais nous voulons construire un produit…     Les "stories" représent...
Prochain SlideShare
Chargement dans…5
×

Agile Tour Nantes 2011 - Arnaud Bailly et Jonathan Perret - spécification par l'exemple

1 464 vues

Publié le

Les méthodes agiles, du moins celles qui s'intéressent au contenu du logiciel produit plus qu'à l'organisation de ceux qui le produisent, insistent toutes sur l'importance des tests automatisés, et ce à tous les niveaux de granularité: test unitaires, d'intégration, fonctionnels, systèmes, "smoke tests", d'interface... Mais on automatise les tests depuis que l'on écrit du code.
La vraie révolution introduite initialement par eXtreme Programming, qui reste la référence sur les pratiques concrètes d'ingénierie du logiciel, sur le travail au quotidien du développeur, a été de renverser la perspective : ce n'est plus le code qui définit quoi tester, ce sont les tests qui disent quoi coder. Ce saut conceptuel, ce renversement à la dimension quasi-copernicienne de la perspective du travail de développement, a eu un impact profond sur le métier de développeur - coder la réponse la plus simple à la question posée, pas plus, pas moins - mais aussi sur le métier de testeur - aider les développeurs au plus tôt et critiquer le produit, plutôt que gérer des montagnes de scripts.
Aujourd'hui, c'est sous diverses appellations que le TDD étend sa sphère d'influence au delà du code, vers le domaine autrefois réservé du fonctionnel, le royaume des analystes, des consultants, des QA : Acceptance TDD, Spécification par l'exemple, Spécifications Exécutables ou encore Behaviour Driven Development sont quelques uns des néologismes forgés pour désigner l'activité spécifique consistant à ne pas écrire de code avant que d'avoir défini précisément, au moyen d'un test
exécutable, les contours de la fonctionnalité attendue.
Au delà des outils, cette session propose de construire des réponses, évidemment partielles, pas nécessairement définitives et certainement pas dogmatiques, aux questions suivantes: pourquoi est-il important de mettre en place une démarche de Spécification par l'exemple ? Quels en sont les bénéfices pour le logiciel ? Comment cela s'articule-t'il avec d'autres tests (régression, smoke, unitaires, d'intégration) ? D'autres pratiques d'assurance qualité ? Le processus de développement ? Comment ne pas (trop) se tromper lorsqu'on veut mettre en place une telle démarche ? Comment sont définis, réalisés, exécutés et maintenus ces tests ? Comment ces tests sont-ils liés aux autres pratiques agiles, et en particulier à la définition des "User stories" ?

0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 464
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
28
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Agile Tour Nantes 2011 - Arnaud Bailly et Jonathan Perret - spécification par l'exemple

  1. 1. Spécification par lexempleSpécification par lexempleArnaud Bailly ­ Jonathan Perret13 octobre 2011Plan 15: Principes des "tests dacceptation" Agile 30: Exercice de Spécification par lexemple 15: Conclusion & perspectivesTDD Pratique centrale de XP, test unitaire, "Test First development" Tests orientés technologie qui soutiennent léquipe Idée fausse: TDD est une technique pour créer des tests de regression TDD est un outil pour guider le développement vers une "Conception Simple"BDD BDD is a second­generation, outside­in, pull­ based, multiple­stakeholder, multiple­scale, high­automation, agile methodology.Dan North, cité par Gojko Adzic "TDD done right" ? Remonter le niveau dabstraction des "tests" à celui des "User Stories": Le "Quoi faire?" plutôt que le "Comment faire?" Définition fluctuante et changeante, souvent liée à des outils: jBehave, RSpec, jDave... et plutôt un changement de perspective sur les tests unitairesATDD Acceptance Test­Driven Development ou Développement Dirigé par les Tests de Recette Mise en place AA­FTT Workshop à partir dAgile 2008 Comment intégrer la pratique du test et les testeurs dans les équipes Agile ? Que deviennent les spécifications dans les projets Agile ? La Recette est un terme contractuel or lAgilité promeut la collaboration sur le contrat : quid des "Tests de recette" ?Les quadrants de Marick
  2. 2. Des tests orienté­métier pour soutenir léquipe Tests définis du point de vue de lusage du produit, des utilisateurs Expliciter les besoins avant de développer : quelle est la fonctionalité que lon souhaite produire ? Construire une suite de tests de non­régression pour vérifier que des développements futurs ne cassent rienCollaborer pour… Développer le bon logiciel, celui qui est attendu par les utilisateurs Ne pas développer des fonctionnalités inutiles Ne pas accumuler de dette technique et maintenir lexistantFormaliser les spécifications ? Approche pilotage par les modèles Travailler à un niveau dabstraction plus élevé mais plus compréhensible pour les utilisateurs Automatiser le processus de réalisation du système à partir des modèles pour garantir la cohérence Mais modéliser, cest déjà coder : on ne peut pas automatiquement produire une information qui nest pas déjà dans le modèleLes problèmes que lon cherche à résoudre
  3. 3. La Spécification par lexemple "Pour établir une pratique, les règles ne suffisent pas; on a également besoin dexemples"L.Wittgenstein, De la certitude, 1969La Spécification par lexemple ATDD Done Right ! Grandement inspiré par les travaux de Gojko Adzic et dautres dans la communauté du Test Agile (Lisa Crispin, Janet Gregory, Brian Marick...) On parlera aussi de Spécification Exécutable, mais… une spécification est elle­même un encodage du problème considéré on ne parle ici que dexemples, ç.à.d. un échantillonage de lespace du problème/des solutions terme plutôt en faveur pour des spécifications formellesDéfinir le "Quoi?" Spécification de "stories" par­delà le post­it Une "story" devrait être une opportunité de conversation, mais comment savoir quand nous avons fini ? Les exemples soutiennent la conversation, offrent des points dappui pour étudier de nouvelles perspectivesÉcrire les exemples Proposition: Utiliser des formes contraintes pour décrire les spécifications 1 story = But/Rôle/Action Afin datteindre un certain but un Utilisateur Veut réaliser une action 1 exemple = Etant donné/Quand/Alors Etant donné un certain état du système Quand lutilisateur fait quelque chose Alors le système atteint tel état Ne pas confondre le quoi et le comment Ne pas oublier le pourquoiExercice
  4. 4. Cest à vous de travailler !Faire vivre le produit Mais nous voulons construire un produit… Les "stories" représentent le chemin que nous suivons pour développer le logiciel : chaque "story" modifie le produit dune façon spécifique Mais le produit nest pas la somme des "stories" : il nest pas possible de reconstruire la séquence exacte de "stories" implémentées étant donné un état particulier du produit (sauf à consulter le système de gestion de versions, bien sûr) Doù la question : faut­il garder tous les tests que nous écrivons pour implémenter les "stories" ? Et la réponse est : "Probablement non !" Les tests comme le code doivent être remaniés, évoluer avec le produit/systèmeFaire évoluer les tests 1.  Définir les tests de recette pour une "story" donnée avant le début du codage, les écrire comme ils viennent sous forme exécutable 2.  Une fois la "story" finie, transformer les tests en exemples de spécification : les regrouper avec lensemble des tests pour la fonctionnalité que cette "story" ajoute ou complète 3.  Utiliser le test exploratoire pour améliorer les spécifications du produit, et ce faisant créer de nouvelles "stories". En particulier, les testeurs (et les développeurs bien sûr) sont habiles à trouver des cas extrêmes, des chemins non couverts, des contradictions…Mieux communiquer Cest donc que “suivre la règle” est une pratique. Croire que lon suit la règle nest pas la suivre. Cest donc aussi quon ne peut pas suivre la règle privatim ; sinon croire que lon suit la règle serait la même chose que la suivre.L.Wittgenstein, Recherches Philosophiques, §202, 1953 On cherche à construire une documentation vivante qui ne soit pas que le code Noeud de communication entre les différents rôles de léquipe (testeurs, experts métiers, développeurs, designers, entre autres)Références Gojko Adzic, Specification By Example, Manning 2011 Gojko Adzic, Bridging the Communication Gap, Neuri 2009 L.Crispin & J.Gregory, Agile Testing, Addison­Wesley, 2009

×