At2009 Soigner Sa Schizophrenie 1.2
Upcoming SlideShare
Loading in...5
×
 

At2009 Soigner Sa Schizophrenie 1.2

on

  • 3,928 views

Introduction à Acceptance test Driven Development

Introduction à Acceptance test Driven Development

Statistics

Views

Total Views
3,928
Views on SlideShare
2,287
Embed Views
1,641

Actions

Likes
2
Downloads
19
Comments
0

13 Embeds 1,641

http://www.ehsavoie.com 1328
http://www.clubagilerhonealpes.org 236
http://clubagilerhonealpes.org 26
http://clubagile.org 17
http://wiki.almerys.local 11
http://grenoble.clubagilerhonealpes.org 7
http://feeds2.feedburner.com 6
http://www.slideshare.net 5
http://www.lmodules.com 1
http://saisiman.blogspot.com 1
http://translate.googleusercontent.com 1
http://www.linkedin.com 1
http://wpcara.fr 1
More...

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Le terme de schizophrénie (« schizo » du grec «  σχίζειν  » [ phon . schizein] signifiant fractionnement et «  φρήν  » [ phon . phrèn] désignant l’esprit) La schizophrénie est une psychose, c’est-à-dire une maladie mentale dont le malade n’est pas conscient et caractérisée par la perte du contact avec la réalité et par des troubles plus ou moins graves de la personnalité.
  • Jusqu'à présent la communication MOA / MOE : idée / réalisation se fait par l'intermédiaire de l'écrit (spécifications , cartes CRC, …).
  • The ATDD Cycle Discuss : work with the business stakeholders to understand their real needs and concerns. In traditional environments, this is usually called “requirements elicitation.” In the context of Agile development, the purpose of this discussion is not to gather a huge list of requirements but rather to understand what the business stakeholder needs from one particular feature. During these discussions, ask questions designed to uncover assumptions, understand expectations around non-functional needs such as stability, reliability, security, etc., and explore the full scope of work the business stakeholder is requesting. Distill : collaborate with the business stakeholders to distill their stated needs into a set of acceptance tests, or examples, that define “done.” These tests should focus on externally detectable behavior and will be expressed in tables or keywords. Develop : write the code to implement the requested feature using test-driven development (TDD). Demonstrate : show the business stakeholder the new feature in the emerging system and request feedback.
  • Le scénario ne passe pas Ecrire le code nécessaire au scénario Ecrire le test unitaire Ecrire le code nécessaire au test unitaire Valider le scenario Le scénario ne passe pas Ecrire le code nécessaire au scénario Ecrire le test unitaire Ecrire le code nécessaire au test unitaire Valider le scenario

At2009 Soigner Sa Schizophrenie 1.2 At2009 Soigner Sa Schizophrenie 1.2 Presentation Transcript

  • Soigner sa schizophrénie MOA / MOE Voyage autour des spécifications exécutables Rémy Sanlaville Expert Senior en Ingénierie Logicielle   Orange Labs [email_address] Emmanuel Hugonnet Architecture J2EE Silverpeas [email_address] Hervé Lourdin Architecte Sénior / Coach agile OCTO Technology [email_address]
  • Contrat de la session Ce que vous verrez dans cette session
    • Une introduction aux spécifications exécutables ?
      • A quoi ca sert, pourquoi c'est utile…
    • Vivre un exemple basé sur la fonctionnalité d'authentification
    • Un panorama du domaine
      • outils existants : approches, les avantages et inconvénients
      • les père fondateurs
    Ce que vous ne verrez pas dans cette session
    • Une démonstration des outils
      • cf. session Coding Dojo - Kata sur le pilotage par les tests d'acceptances (ATDD)
    • Une solution magique à tous vos problèmes
  • Double Personnalité Double Audience " Stakeholders are the people whose life you touch with your software " Dan North MOA MOE
  • Deux hémisphères MOA MOE Architecture Technique Artisanat Bien faire Ce qu’il faut faire Idées Métier Valeur
  • Un problème de communication
  • Communication MOE exprime Client délivre comprend décrit MOA Insatisfaction Gaspillage Besoin Couvert
  • Fonctionnalités et leur utilisation pour un logiciel Source CHAOS
  • Communication Définition de "terminé" MOA MOE
  • ATDD cycle model by Jim Shore with changes suggested by Grigori Melnick, Brian Marick, and Elisabeth Hendrickson
  • Ensemble tout devient possible Atelier de spécifications Bug Bash copyright by Hans Bjordahl — www.bugbash.net
  • ATDD cycle model by Jim Shore with changes suggested by Grigori Melnick, Brian Marick, and Elisabeth Hendrickson
  • Un Langage Commun External Domain Specific Language Given … When … Then …
  • Spécifier par l’exemple
    • Les histoires d’utilisateur sont décrites au travers d’exemples : les scénarii
    Les utilisateurs doivent utiliser des mots de passe sécurisés (une chaine de caractères dont la taille est comprise entre 8 et 20 Et qui contiennent au moins une lettre, un chiffre et un caractère spécial)
  • Atelier de Spécifications Discussion Que ce passe t'il si un utilisateur entre un mot de passe non sécurisé ? Pouvez vous me donner des exemples de mots de passe sécurisés et non sécurisés ? Quels sont les caractères spéciaux ? Comment prend on en compte les espaces ? Que fait on pour les mots de passe basés sur un dictionnaire avec une substitution simple comme ‘p@ssw0rd’ ? Comment gère t on les comptes existants ? Comment savoir que cette fonction est "terminée" ?
  • Atelier de spécifications Discussion
    • Que ce passe t'il si un utilisateur entre un mot de passe non sécurisé ?
    • Pouvez vous me donner des exemples de mots de passe sécurisés et non sécurisés ?
    • Quels sont les caractères spéciaux ?
    • Comment prend on en compte les espaces ?
    • Que fait on pour les mots de passe basés sur un dictionnaire avec une substitution simple comme ‘p@ssw0rd’?”
    • Comment gère t on les comptes existants ?
    • Comment savoir que cette fonction est "terminée" ?
  • Les scénarii Etant donné un nouvel Utilisateur Lorsqu 'il crée un compte avec un mot de passe sécurisé Alors le message 'SUCCESS' apparait Et lorsqu'il essaye de se connecter sur ce compte Alors le message 'Hello $login' apparait Etant donné un nouvel Utilisateur Lorsqu 'il crée un compte avec un mot de passe non sécurisé Alors le message 'FAILURE' apparait Et lorsqu'il essaye de se connecter sur ce compte Alors il n'y parvient pas et le message 'FAILURE' apparait
  • Exemples
    • Exemples de mots de passe sécurisé
      • [email_address]
      • d1ction n@ire
      • dictionnaire_01
    • Exemples de mots de passe non sécurisés
      • Trop court: [email_address]
      • Trop long: dictionnaire_01_ dictionnaire_01
      • Sans chiffre: p@ssword
  • L’information circule
  • ATDD cycle model by Jim Shore with changes suggested by Grigori Melnick, Brian Marick, and Elisabeth Hendrickson
  • Scénarii Distillés
  • Exemples
  • ATDD cycle model by Jim Shore with changes suggested by Grigori Melnick, Brian Marick, and Elisabeth Hendrickson
  • Développer
    • ATDD / BDD : bien faire ce que je dois faire
    • Le métier pilote le développement
    • TDD : bien faire les choses
    • Émergence du design
  • On commence au Rouge
  • Il manque la Fixture Fixture : code de liaison entre le test (les tableaux) et le code du sysème testé (SUT)
  • Ecriture de la Fixture
  • Prêt à Développer
  • Première Etape
  • TDD – Ecriture du Test
  • TDD – Ecriture du Code
  • Vérification Fonctionnelle
  • Fonctionnalité Terminée
  • Les exemples permettent de prouver "scientifiquement" la théorie du développeur Les tests d'acceptance sont le scanner du projet
  • Enfin les tests : l’exploration Tests Exploratoires Tests d'Acceptance Tests Unitaires et d'Intégration Disponibilité Scalabilité Sécurité … *ité Aspect Technologique Aspect Métier Support du Développement Critique du Produit
  • Rendre les spécifications exécutables
    • Différentes approches
      • Proche du code
        • JBehave, Rspec, Easyb…
      • Format moins technique
        • Wiki : Fitnesse/SLIM, GreenPepper…
        • HTML : Concordion, Robotframework…
      • De nouveaux outils en cours de maturation
        • Twist, JBehave 2…
  • Les Pères Fondateurs
    • JBehave : Dan North, Chris Matt
    • Test Driven Development: Kent Beck
    • FIT: Ward Cunningham
    • Example Driven Development: Brian Marick
    • User Stories: Mike Cohn
    • Domain Driven Design: Eric Evans
    • Test Obsessed: Elisabeth Hendrickson
  • Bilan
    • Une meilleure communication entre les différents acteurs du projet
        • Discuss : tous ensemble
        • Distill : définition par l'exemple
        • Develop : pilotage par l'exemple - "FAIT"
        • Demo : Validation
    • Bref, une seule équipe
  • Perspectives
    • Emergence d'une nouvelle génération d'outils pour relever de nouveaux défis
    • Intégration au cycle de vie du projet (SCM)
    • Facilité de prise en main par la MOA
    • Meilleure Intégration avec les outils de développement
    • Rapports plus complets (couverture des exigences, évolution dans le temps…)
    • 5 doigts : Excellente Super c'est exactement ce qu'il me fallait !
    • 4 doigts : Bonne Très intéressant,
    • 3 doigts : Juste Moyenne Intéressant, sans plus. Je n’ai pas perdu mon temps.
    • 2 doigts : Utile Bof ! J'ai perdu du temps.
    • 1 doigt : Inutile Je n'ai rien appris. J’ai vraiment perdu mon temps
    ROTI (Return On Time Invested)