• Português
  • 简体中文
  • English
  • Français
  • Deutsch
  • 日本語
  • Lietuvių
  • Español
Accueil

Submitted Conference Content

Nom(s) et Prénom(s)

Arnaud Bailly et Jonathan Perret

JobDeveloper
emailarnaud [dot] oqube [at] gmail [dot] com
Entreprise/OrganisationPolyspot / UT7
Ville (Pays)Paris
Temps1h
Type de conférenceWorkshop / 40 attendees
NiveauEverybody

Le développement dirigé par les tests d'acceptation: Mythe ou réalité ?

Biographie

Arnaud Bailly est payé pour développer des logiciels depuis une quinzaine d'années. Il est tombé dans l'agilité en suivant le chemin de la vérification de programmes, des tests automatisés, du TDD... Il est aujourd'hui développeur sénior/coach agile/grand mamamouchi dans une startup parisienne. Jonathan Perret a, d'un certain point de vue, un parcours assez similaire quoique le résultat final soit très différent. Après un long passage chez Augure, il est désormais associé dans l'aventure /ut7 et consultant.

Description

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" ? Déroulement: - Introduction (10'): introduction et retour d'expérience sur la mise en place de pratiques d'ATDD, ce qui marche, ce qui ne marche pas, la classification des différents types de test; - Atelier collectif (35'): Exercice de spécification par l'exemple au moyen de l'outil FitNesse : à partir d'un problème/besoin relativement imprécis et concret (Twitter), construire des spécifications exécutables utilisables pour guider le développement; - Discussion (15'): Étude et évaluation collective des propositions de tests et améliorations possibles. Comment fera-t'on vivre ces tests ?

Bénéfices pour les participants

Objectif: - débroussailler le maquis de la terminologie sur les tests au moyen du "quadrant de Marick", - comprendre comment les méthodes agiles proposent d'intégrer les tests "fonctionnels" le plus tôt possible dans le processus de développement et ce que cela implique pour les spécifications: le quoi développer plutôt que le comment, - mettre en avant le fait que les tests, c'est aussi du code: ils doivent être maintenus, mis à jour, évalués en fonction de leur pertinence et de leur efficacité sur le projet, réusinés et moins il y en a à maintenir, mieux on se porte... - proposer des pistes pour faciliter le passage des "test monkeys" aux spécifications exécutables et au test exploratoire, pour augmenter la valeur ajoutée des tests, la qualité et la quantité d'information qu'ils exposent, identifier les pièges courants dans la mise en place et l'utilisation d'ATDD
Go to the submission page!
Soumis par ppetit le lun, 06/13/2011 - 02:02

World Sponsor

India Sponsors

Sponsors France

Connexion utilisateur

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
                                                        
  ad88888ba     ad888888b,    ad88888ba     ad88888ba   
 d8"     "88   d8"     "88   d8"     "8b   d8"     "88  
 8P       88           a8P   Y8a     a8P   8P       88  
 Y8,    ,d88        aad8"     "Y8aaa8P"    Y8,    ,d88  
  "PPPPPP"88        ""Y8,     ,d8"""8b,     "PPPPPP"88  
          8P           "8b   d8"     "8b            8P  
 8b,    a8P    Y8,     a88   Y8a     a8P   8b,    a8P   
 `"Y8888P'      "Y888888P'    "Y88888P"    `"Y8888P'
Enter the code depicted in ASCII art style.