Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

20111004 04 - Présentation ATDD

96 views

Published on

Acceptance test driven development

Published in: Software
  • Be the first to comment

  • Be the first to like this

20111004 04 - Présentation ATDD

  1. 1. ACCEPTANCE  TEST  DRIVEN   DEVELOPMENT   (ATDD)                 4  octobre  2011  
  2. 2. Sommaire   u  Présenta4on  de  l’ATDD   u  Constats    sur  l’industrie  du  test   u  Les  grands  principes  de  l’ATDD     u  Pour  quels    bénéfices  ?   u  Retour  d’expérience   u  Mme  Bénédicte  Taillebois,   Responsable  des  études  d’ASTRIA     Club  Qualité  Logicielle  -­‐  4  octobre  2011   2  
  3. 3. -­‐  I  -­‐   Présenta4on  de  l’ATDD  
  4. 4. Constats     sur     l’industrie  du  test  
  5. 5. Chiffres   5   50  %   Ra5o  maximum  code   testé   15  %   Bugs  connus   livrés  en     produc5on   40  %   Coût  des  tests  
  6. 6. Conséquences   u  Infla4on  du  coût  et  des  délais   u  Fossé  entre  la  qualité  perçue  par  les  u4lisateurs   finaux  et  le  coût  du  test   u  Effort  important  sur  les  tests  de  non  régression   souvent  manuels   u  Difficulté  à  automa4ser  et  à  maintenir  les  tests   Club  Qualité  Logicielle  -­‐  4  octobre  2011   6  
  7. 7. Bugs  et  Tests   Club  Qualité  Logicielle  -­‐  4  octobre  2011   7   1.  Specifica5on   2.  Développement   3.  Tests   4.  Bugs   Origine  des  bugs  dans  les    projets  IT   Spécifica4on   Développement   Autre   Résultats?  
  8. 8. Pourquoi  ne  pas?     u  Piloter  les  spécifica4ons  du  logiciel   u  et  son  implémenta4on   u  par  des  exemples  concrets?     Club  Qualité  Logicielle  -­‐  4  octobre  2011   8  
  9. 9. ATDD  ?   5  principes  
  10. 10. ATDD  en  pra4que   Club  Qualité  Logicielle  -­‐  4  octobre  2011   10   Partager  une  vision  fonc4onnelle  commune  de  l’applica4on   Ecrire  les  tests  d’acceptance   Automa4ser  les  spécifica4ons  exécutables   Implémenter  le  code   U4liser  les  spécifica4ons  exécutables  comme  une   documenta4on  «  vivante  »  pour  faciliter  le  changement   1   2   3   4   5  
  11. 11. Club  Qualité  Logicielle  -­‐  4  octobre  2011   11   Expert  mé4er   Développeurs   Testeurs   L’équipe   Grands  domaines   fonc5onnels  de  l’applica5on     Processus  et  workflows     Fonc5onnalités  principales     Vocabulaire     1.  Partager  une  vision  fonc4onnelle   commune  de  l’applica4on    
  12. 12. 2.  Ecrire  les  tests  d’acceptance     Club  Qualité  Logicielle  -­‐  4  octobre  2011   12   1a.  Le  but   QUI?   QUOI?   POUR  QUOI?   2.  Les  tests   CONTEXTE?   ACTION  ?   RESULTATS  ?   1b.  Règles  de  ges4on   QUELLE  REGLE  ?      
  13. 13. 3.  Automa4ser  les    spécifica4ons   exécutables   Club  Qualité  Logicielle  -­‐  4  octobre  2011   13       Code                  Fixture   Tests   d’acceptanc e   exécutables     Tests   d’acceptance   automa5sés   Tests   Tests     Tests    
  14. 14. 4.  Implémenter  le  code  en  fonc4on  des   tests  d’acceptance   Club  Qualité  Logicielle  -­‐  4  octobre  2011   14   1ère  exécu4on     du  TA   KO   Code  Ini5al   FINI   2ème  exécu4on     du  TA      3ème  exécu4on     du  TA     KO   KO    n-­‐ième  exécu4on     du  TA       OK  
  15. 15. 5.  U4liser  les  spécifica4ons  exécutables  comme  une   documenta4on  ‘vivante’  pour  faciliter  le   changement       Ü   Facile  à  écrire   Ü   Facile  à  lire   Ü   Facile  à  changer   Club  Qualité  Logicielle  -­‐  4  octobre  2011   15       Ü   Précis   Ü   Consistant   Ü   Valide  le  logiciel  
  16. 16. Pour  quels  bénéfices?  
  17. 17. Manager  :  Pour  quels  bénéfices?   En  tant  que  manager,  je  veux    :   ü   Suivre  l  ’avancement  des  développements  avec   des  indicateurs     En  tant  que  manager,  j’ai:   ü  Repor4ng  immédiat:  sta4s4ques  tests  OK/test   KO   Ø   Retour  client  :  “Il  était  difficile  d’avoir  des  retours   concrets  des  équipes”     Club  Qualité  Logicielle  -­‐  4  octobre  2011   17  
  18. 18. Expert  mé4er:  Pour  quels  bénéfices?   En  tant  qu’expert  mé5er,  je  veux    :   ü   Développeurs  comprennent  et  implémentent   correctement  les  besoins  spécifiés   ü   Testeurs  détectent  au  plus  tôt  le  maximum  de   bugs     En  tant  qu’expert  mé5er,  j’ai:   ü   Valida4on  immédiate  du  logiciel   Ø   Retour  client  :  “Les  développeurs  comprennent  mieux   notre  besoin  avec  des  exemples  concrets”     Club  Qualité  Logicielle  -­‐  4  octobre  2011   18  
  19. 19. Développeur  :  Pour  quels  bénéfices?   En  tant  que  développeur,  je  veux  :   ü   Spécifica4ons  soient  les  moins  ambigües  possible   ü   Pouvoir  valider  mon  code  juste  après  l’avoir  écrit     En  tant  que  développeur,  j’ai  :   ü   Confiance  :    au  code  et  à  l’équipe   ü   Direc4on    bien  définie   Ø  Retour  client  :  “Je  sais  quand  m’arrêter”     Club  Qualité  Logicielle  -­‐  4  octobre  2011   19  
  20. 20. Testeur:  Pour  quels  bénéfices?   En  tant  que  testeur,  je  veux  :   ü   Eviter  de  faire  et  refaire  les  mêmes  tests   ü   Vérifier  les  règles  mé4er  en  un  clic   En  tant  que  testeur,  j’ai  :   ü   “Test  intelligent”   Ø   Retour  client  :  “Nous  pouvons  nous  concentrer  sur  des   tests  plus  complexes  (exploratoires)”   Club  Qualité  Logicielle  -­‐  4  octobre  2011   20  
  21. 21. -­‐  II  -­‐   Retour  d’expérience   ASTRIA  
  22. 22. ASTRIA  :  le  contexte   u  Projet  de    refonte  de  SI  mé4er  représentant  plus  de  50%   de  l’ac4vité,  évalué  à  10  000  j/h,  entamé  en  juillet  2008   u  Passer  d’une  applica4on  monolithique  à  une   architecture  applica4ve  urbanisée  avec  des  référen4els   u  Permegre  une  adapta4on  du  programme  de  refonte  à   des  changements  fréquents  dans  le  planning  et  le   périmètre   u  Eviter  le  trauma4sme  d’un  big  bang  vécu  en  2005   u  Décision  :  développer  en  méthode  agile,  industrialiser  les   développements,  u4liser  les  spécifica4ons    exécutables   u  Ou4llage  :  php  et  java,  Greenpepper   Club  Qualité  Logicielle  -­‐  4  octobre  2011   22  
  23. 23. 3  ans  après  :  des  chiffres   u  60%  de  la  refonte  réalisée   u  Processus  de  projets  :   u 1  phase  de  cadrage   u 1  phase  de  développement   u  Des  spécifica4ons  exécutables,   automa4quement    (ou  pas)   u  20  applica4ons  en  produc4on  ou  en   développement     u     environ  10  000  tests  exécutables  Greenpepper   u     120  tests  Selenium   Club  Qualité  Logicielle  -­‐  4  octobre  2011   23  
  24. 24. Les  spécifica4ons  exécutables,  c’est   quoi  ?   Club  Qualité  Logicielle  -­‐  4  octobre  2011   24  
  25. 25. Les  spécifica4ons  exécutables,  c’est   quoi  ?   Club  Qualité  Logicielle  -­‐  4  octobre  2011   25  
  26. 26. Les  spécifica4ons  exécutables,  c’est   quoi  ?   Club  Qualité  Logicielle  -­‐  4  octobre  2011   26  
  27. 27. Les  spécifica4ons  exécutables,  c’est   quoi  ?   Club  Qualité  Logicielle  -­‐  4  octobre  2011   27   u  Des  spécifica4ons   u  Des  exemples  de  cas  de  recege   u  De  la  glue  pour  servir  de  passe-­‐plat  :  on  exécute   le  code  de  l’applica4on  sur  des  jeux  de  données   préparées  à  l’avance  et  stables   u  Possibilité  pour  le  Product  Owner  ou  le   développeur  d’ajouter  des  cas  de  tests  pour   valider  la  robustesse  de  son  code    
  28. 28. Pourquoi  des  specs  exécutables  ?   u  Pour  livrer  plus  vite  durablement   u  Pour  avoir  en  permanence  un  statut  sur   l’ap4tude  à  livrer  une  applica4on   u  Pour  pouvoir  faire  évoluer  le  logiciel  avec  des   ressources  qui  changent   u  Pour  appliquer  le  principe  du  «  fail  early  »   u  Pas  de  (mauvaise)  surprise  à  la  fin     Club  Qualité  Logicielle  -­‐  4  octobre  2011   28  
  29. 29. Stratégie  de  l’ATDD   u  Les  spécifica4ons  exécutables  sont  pluggées  sur   la  couche  de  services   u  Leur  qualité  est  essen4elle,  car  elle  détermine  la   structure  des  services  de  l’applica4on   u  Et  le  reste  ?  Des  tests  d’IHM  sur  le  process   standard  (  test  de  santé  )   u  Sécurisa4on  des  applica4ons  legacy  par  un   harnais  de  tests  IHM  pe4t  à  pe4t  remplacés  par   des  tests  Greenpepper   Club  Qualité  Logicielle  -­‐  4  octobre  2011   29  
  30. 30. L’organisa4on  liée  aux  tests   u  L’idéal  :  c’est  le  mé4er  qui  écrit  les  tests.  Pas   facile  !   u  L’AMOA    écrit  les  tests   u  Pas  d’équipe  de  testeurs  dédiés   u  Bien  séparer  les  tests  unitaires  (de  la   responsabilité  des  développeurs)  des   spécifica4ons  exécutables  (de  la  responsabilité   des  Product  Owners)   Club  Qualité  Logicielle  -­‐  4  octobre  2011   30  
  31. 31. Les  tests  sont  un  inves4ssement   u  Ces  tests  sont  un  patrimoine  dans  lequel   l’entreprise  inves4t   u  Il  faut  rentabiliser  l’inves4ssement  ini4al  en   entretenant  le  capital   u   améliorer  la  couverture,  modifier  les  tests,  les   maintenir  opéra4onnels,  en  supprimer  certains   u  Une  applica4on  ne  passe  en  produc4on  que  si  les   Greenpepper  sont  verts   u  Principe  :  1  bug  =  1  test   Club  Qualité  Logicielle  -­‐  4  octobre  2011   31  
  32. 32. Les  indicateurs  associés   u  Pas  d’indicateurs  standards  fournis  par  les   usines  qualité   u  Développement  en  cours  d’un  indicateur  de   couverture  des  tests  GP   u  Mise  en  place    envisagée  d’un  indicateur  de   couverture  fonc4onnelle  des  tests  GP  (  sur  une   idée  de  GEFCO)   Club  Qualité  Logicielle  -­‐  4  octobre  2011   32  
  33. 33. Et  si  on  arrêtait  de  faire  des  specs   exécutables  ?   u  3  semaines  après  :  ça  devient  difficile  de  faire   une  modifica4on  fonc4onnelle   u  3  mois  après  :  on  souffre  pour  remegre  tout  ça   au  propre   u  On  voudrait  ne  plus  jamais  arrêter  d’en  faire,   mais  il  faut  augmenter  la  qualité  des  spécs   exécutables   Club  Qualité  Logicielle  -­‐  4  octobre  2011   33  
  34. 34. Problèmes  de  qualité   u  La  qualité  est  cruciale   u  Pour  réussir,  il  faut  :   u   Une  équipe  de  développement  qui  lit  les  spécifica4ons   u   Faire  rédiger  les  spécifica4ons  en  commun  par  les   Product  Owners  et  les  développeurs   u   Ne  pas  négliger  de  megre  des  tests  sur  les  interfaces   entrantes  /  sortantes  /  WS  et  même  sur  les  traitements   de  reprise   u  Notre  dernière  idée  :  des  Technical  Reviews  sur   les  spécifica4ons  exécutables   Club  Qualité  Logicielle  -­‐  4  octobre  2011   34  
  35. 35. L’ATTD   u  Ne  supprime  pas  les  tests  faits  directement  par   les  u4lisateurs  finaux,  mais  les  sécurise   u  N’est  pas  un  ou4l  magique  mais  évite  bien  des   sueurs  froides   u  Trouve  sa  pleine  mesure  dans  un  environnement   de  développement  industrialisé   u  Permet  de  réduire  les  temps  de  cycle  et   l’incrémental-­‐itéra4f  n’est  plus  seulement  une   promesse   u  Demande  des  équipes  de  bon  niveau  et  qui   travaillent  de  manière  proche  Club  Qualité  Logicielle  -­‐  4  octobre  2011   35  
  36. 36. Ques4ons  ?   u  Gilles  Mergoil,  gilles.mergoil@neoxia.com   u  Bénédicte  Taillebois,  benedicte.taillebois@astria.com             36  Club  Qualité  Logicielle  -­‐  4  octobre  2011  

×