Agilité et Testing Julien Behr – 30 avril 2009
Présentations  Julien BEHR [email_address] Tel : +41 (0)79 924 20 64 Consultant En efficacité des organisations informatiq...
Agenda <ul><li>Pourquoi on continue à tester ?
Actualité </li><ul><li>Comment on teste en mode Agile ?
Comment on teste en mode « classique » ? </li></ul><li>Perspective </li><ul><li>Mais qu'est-ce que je dois tester ?
Que veut-on éviter ?
Comment puis-je répartir mes moyens ?
De qui ai-je besoin ?
Comment puis-je m'organiser ?
Et dans la pratique qu'est-ce que çà donne ?
Un outil çà aide ?
Bon je commence comment ? </li></ul></ul>
La philosophie La confiance n'exclut pas le contrôle
Les postures face au test <ul><li>Le Joueur </li><ul><li>Serre les fesses
Brûle un cierge
Consulte les astres
Compte sur les autres </li></ul></ul><ul><li>Le Méthodique </li><ul><li>Défini un parcours immuable
S'y  tient coûte que coûte
(TMM) </li></ul></ul><ul><li>L'Empirique </li><ul><li>Fait ce qu'il peut
Du mieux possible
S'attache aux cas très particuliers et complexes </li></ul></ul><ul><li>Le Pragmatique </li><ul><li>Questionne préalablement
Adapte le dispositif aux risques et au délai </li></ul></ul>
Pourquoi (continuer) à tester ? <ul><li>Évolutions  </li><ul><li>Maturité de l'informatique
Approche générique par composant - Templates
Atelier de développement guidé
Projets : de plus en plus d'intégration </li></ul><li>Alors pourquoi encore tester ? </li><ul><li>Système d'informations d...
Risques pour le métier
Concurrence
Assurance Qualité – Normes
Prévention insuffisante </li></ul></ul>
Le Test dans les démarches Agiles <ul><li>Manifesto </li><ul><li>« Working software is the primary measure of progress »
« Continuous attention to technical excellence and good design enhances agility » </li></ul><li>Les pratiques pour répondr...
Tester plus vite  ->  Automatisation des tests (unitaires)
Tester plus souvent ->  Intégration continue
Faciliter le re-factoring </li><ul><li>Centrer la démarche de test sur la non-régression
Contrôler le respect des standards (analyse de code)
Maitriser l'exhaustivité des tests unitaires (couverture de code) </li></ul></ul><li>L'organisation </li><ul><li>Toute l'é...
La qualité est au coeur des préoccupations
Le Métier participe à la validation à chaque sprint </li></ul></ul>
Upcoming SlideShare
Loading in...5
×

Présentation Agile Testing

6,802

Published on

How to test in Agile mode and how testing could become Agile

Published in: Technology, Business

Présentation Agile Testing

  1. 1. Agilité et Testing Julien Behr – 30 avril 2009
  2. 2. Présentations Julien BEHR [email_address] Tel : +41 (0)79 924 20 64 Consultant En efficacité des organisations informatiques En politique et stratégie de test Scrum Master Formateur Responsable Technique
  3. 3. Agenda <ul><li>Pourquoi on continue à tester ?
  4. 4. Actualité </li><ul><li>Comment on teste en mode Agile ?
  5. 5. Comment on teste en mode « classique » ? </li></ul><li>Perspective </li><ul><li>Mais qu'est-ce que je dois tester ?
  6. 6. Que veut-on éviter ?
  7. 7. Comment puis-je répartir mes moyens ?
  8. 8. De qui ai-je besoin ?
  9. 9. Comment puis-je m'organiser ?
  10. 10. Et dans la pratique qu'est-ce que çà donne ?
  11. 11. Un outil çà aide ?
  12. 12. Bon je commence comment ? </li></ul></ul>
  13. 13. La philosophie La confiance n'exclut pas le contrôle
  14. 14. Les postures face au test <ul><li>Le Joueur </li><ul><li>Serre les fesses
  15. 15. Brûle un cierge
  16. 16. Consulte les astres
  17. 17. Compte sur les autres </li></ul></ul><ul><li>Le Méthodique </li><ul><li>Défini un parcours immuable
  18. 18. S'y tient coûte que coûte
  19. 19. (TMM) </li></ul></ul><ul><li>L'Empirique </li><ul><li>Fait ce qu'il peut
  20. 20. Du mieux possible
  21. 21. S'attache aux cas très particuliers et complexes </li></ul></ul><ul><li>Le Pragmatique </li><ul><li>Questionne préalablement
  22. 22. Adapte le dispositif aux risques et au délai </li></ul></ul>
  23. 23. Pourquoi (continuer) à tester ? <ul><li>Évolutions </li><ul><li>Maturité de l'informatique
  24. 24. Approche générique par composant - Templates
  25. 25. Atelier de développement guidé
  26. 26. Projets : de plus en plus d'intégration </li></ul><li>Alors pourquoi encore tester ? </li><ul><li>Système d'informations de plus en plus stratégique pour l'entreprise
  27. 27. Risques pour le métier
  28. 28. Concurrence
  29. 29. Assurance Qualité – Normes
  30. 30. Prévention insuffisante </li></ul></ul>
  31. 31. Le Test dans les démarches Agiles <ul><li>Manifesto </li><ul><li>« Working software is the primary measure of progress »
  32. 32. « Continuous attention to technical excellence and good design enhances agility » </li></ul><li>Les pratiques pour répondre aux nouveaux besoins </li><ul><li>Tester au plus tôt -> Test Driven Developpement
  33. 33. Tester plus vite -> Automatisation des tests (unitaires)
  34. 34. Tester plus souvent -> Intégration continue
  35. 35. Faciliter le re-factoring </li><ul><li>Centrer la démarche de test sur la non-régression
  36. 36. Contrôler le respect des standards (analyse de code)
  37. 37. Maitriser l'exhaustivité des tests unitaires (couverture de code) </li></ul></ul><li>L'organisation </li><ul><li>Toute l'équipe teste
  38. 38. La qualité est au coeur des préoccupations
  39. 39. Le Métier participe à la validation à chaque sprint </li></ul></ul>
  40. 40. L'approche classique du test MEP Développement Tests Développement Tests Développement Tests Tests Développement Tests
  41. 41. Les meilleures pratiques dans le cas général Planification & Suivi P & S EB SFG SFD Réal. TU TAss Tests Fonc. Recette Pré- Expl. Expl. Début du projet MEP C S P E P & S E C S P
  42. 42. L'approche classique du test dans un mode Agile <ul><li>Ne fonctionne pas car : </li><ul><li>Il n'y a pas d'équipe de test
  43. 43. Il n'y a (normalement) pas de responsable de test en Scrum
  44. 44. Il n'y a pas de temps pour rédiger un plan de test
  45. 45. Les spécifications sont limitées, voire inexistantes </li><ul><li>La revue de documentation ne peut pas avoir lieu
  46. 46. Définir des tests à partir des spécifications est difficile </li></ul><li>A chaque sprint est livré un applicatif pouvant (théoriquement) être mis en production
  47. 47. On ne peut pas attendre que le produit soit fini </li></ul></ul>
  48. 48. Définition Qualité = Degré de perfection dans le respect des exigences exprimées ou potentielles
  49. 49. Savoir ce que l'on teste <ul><li>Construire un carré bleu en gomme </li></ul>Couleur ? Taille ? Tenue de la couleur ? Perméabilité de la surface ?
  50. 50. Le Test : une affaire de perspective Rayon ? Résistance à la compression ?
  51. 51. Elargir sa vision - Définir la perspective Confort? Robustesse? Facilité d'utilisation? Facilité d'installation?
  52. 52. Illustration Supply Chain Management
  53. 53. Savoir POURQUOI on teste Couleur ? Taille ? Tenue de la couleur ? Perméabilité de la surface ? Impossible à associer et à intégrer Pas beau Beau pas longtemps Perte d'image de marque Fuite –Rupture Sollicitation SAV = ?
  54. 54. Un risque ó une caractéristique de qualité <ul><li>Facture fausse -> perte de d'image de marque -> fuite des clients (ou du CA) </li></ul>Connectivité – Continuité -Contrôle de données - Efficacité Business - Efficacité Système – Flexibilité – Fonctionnalité – Infrastructure – Maintenabilité – Administration - Performance – Portabilité – Réutilisabilité – Sécurité – Convenance – Testabilité - Ergonomie <ul><li>Désertion des utilisateurs si le temps de réponse > 2 s </li></ul><ul><li>Changement de plateforme technique -> Budget x 2 </li></ul><ul><li>Perte d'un brevet si la concurrence accède aux données de l'entreprise
  55. 55. Budget Infrastructure sur-dimensionné si le CPU ne fonctionne qu'à 5% </li></ul>
  56. 56. Un risque ó une caractéristique de qualité (2) <ul><li>Opérations </li><ul><li>Correction (fait d'être correct)
  57. 57. Fiabilité
  58. 58. Intégrité
  59. 59. Ergonomie
  60. 60. Efficience </li></ul><li>Révisions </li><ul><li>Maintenabilité
  61. 61. Flexibilité
  62. 62. Testabilité </li></ul><li>Transition </li><ul><li>Interopérabilité
  63. 63. Réutilisabilité
  64. 64. Portabilité </li></ul><li>(Source McCall, Richards, Walter) </li></ul><ul><li>Fonctionnalité </li><ul><li>Convenance, Exactitude, Interopératibilité, Conformité, Sécurité </li></ul><li>Fiabilité </li><ul><li>Maturité, Tolérance aux pannes, Récupérabilité </li></ul><li>Ergonomie </li><ul><li>Compréhensibilité, Facilité d'appréhension, Opérabilité </li></ul><li>Efficience </li><ul><li>En termes de temps, de ressources </li></ul><li>Maintenabilité </li><ul><li>Analysabilité, Flexibilité, Stabilité, Testabilité </li></ul><li>Portabilité </li><ul><li>Adaptabilité, Installabilité, Conformité, Interchangeabilité </li></ul><li>(Source ISO) </li></ul>
  65. 65. Qu'est-ce qui peut (doit) être testé ? <ul><li>Les produits </li><ul><li>Le logiciel applicatif
  66. 66. Le paramétrage
  67. 67. L'implémentation
  68. 68. Les données
  69. 69. Les outils (ex: migration)
  70. 70. Les procédures
  71. 71. Les environnements
  72. 72. Les logiciels systèmes
  73. 73. Le matériel
  74. 74. Les outils d'exploitation (backup, supervision, …)
  75. 75. Le paramétrage d'exploitation
  76. 76. La documentation (spécifications, manuels, ...)
  77. 77. La formation
  78. 78. Le support
  79. 79. ... </li></ul></ul>
  80. 80. Pas de risque -> Pas de test Choix
  81. 81. Définir la répartition <ul><li>Pour éviter : </li><ul><li>La dispersion de l'effort
  82. 82. Les « trous » -> Confiance </li></ul></ul>Dans le sprint Dans un sprint parallèle En fin de chaîne
  83. 83. Tester plus tôt <ul><li>Software Errors Cost U.S. Economy $59.5 Billion Annually (NIST) </li></ul>1 X 6,5 X 15 X 100 X Conception Réalisation Validation Déploiement Exploitation Coût relatif de correction des anomalies Sources Gartner / IBM 2003
  84. 84. Le Test : une affaire de spécialiste <ul><li>Testeur – Test Manager </li><ul><li>Un rôle à part </li><ul><li>A l'écoute - Posant des questions
  85. 85. Formé (ISTQB, méthodes structurées, ...)
  86. 86. Donnant de la visibilité sur la qualité
  87. 87. Nécessitant du crédit auprès des équipes </li></ul><li>Des compétences spécifiques </li><ul><li>Développement
  88. 88. SGBD
  89. 89. Fonctionnelles
  90. 90. Outils spécifiques
  91. 91. Culture générale </li></ul><li>Organisation </li><ul><li>dans le Team ?
  92. 92. à l'extérieur du Team ? </li></ul></ul></ul>
  93. 93. Hétérogénéïté
  94. 94. L'Agilité dans le Test <ul><li>Constitution d'un projet de test </li><ul><li>Parallèle au projet de construction
  95. 95. Fonctionnant en mode Agile </li></ul></ul>Building Team Testing Team
  96. 96. Le fonctionnement Product Owner Exigences Livrer Donner de la visibilité sur la qualité
  97. 97. L'Agilité dans le Test en pratique <ul><li>Activités de test </li><ul><li>Coordonnées
  98. 98. Imbriquées
  99. 99. En visibilité </li></ul><li>Tester c'est </li><ul><li>Concevoir la stratégie de test
  100. 100. Concevoir les tests
  101. 101. Exécuter les tests
  102. 102. Donner de la visibilité
  103. 103. Capitaliser </li></ul><li>Documentation </li><ul><li>Stratégie de test
  104. 104. Cahier de test </li></ul></ul>
  105. 105. Stratégie de test <ul><li>Applicable à la totalité du projet
  106. 106. Définition des produits
  107. 107. Analyse des risques </li><ul><li>Caractéristiques de qualité </li></ul></ul>
  108. 108. Stratégie de test (2) <ul><li>Répartition de l'effort de test </li><ul><li>Définition des responsabilités </li></ul><li>Contraintes </li><ul><li>Techniques, fonctionnelles, temporelles </li></ul><li>Organisation </li><ul><li>Position des testeurs dans les équipes </li></ul><li>Amélioration continue </li><ul><li>Démarche mise en oeuvre </li></ul><li>Evaluation </li><ul><li>Définition des indicateurs
  109. 109. Visibilité - Reporting </li></ul></ul>
  110. 110. Cahier de mise en oeuvre tests <ul><li>Application </li><ul><li>Défini pour chaque organisation de test
  111. 111. Applicable à chaque sprint
  112. 112. Revu à chaque sprint </li></ul><li>Technique de test </li><ul><li>En fonction des caractéristiques de qualité validées
  113. 113. En fonction de la classe de risque </li></ul><li>Critères d'arrêt
  114. 114. Politique de re-test
  115. 115. Eligibilité à l'automatisation </li><ul><li>Critères </li></ul><li>Environnements </li><ul><li>Plateformes
  116. 116. Données </li></ul></ul>
  117. 117. Pourquoi documenter (a minima) les tests ? <ul><li>Permet de clarifier avec le Product Owner </li><ul><li>L'approche
  118. 118. Les moyens nécessaires
  119. 119. Les exigences de qualité </li></ul><li>Permet de partager </li><ul><li>Intégration d'une nouvelle ressource ou passage de témoin </li></ul><li>Permet de capitaliser </li><ul><li>D'une release à l'autre
  120. 120. D'un projet à l'autre </li></ul><li>Fixe des règles communes </li><ul><li>Permettant de vérifier si on reste en ligne </li></ul><li>L'existence d'un document suscite la réflexion et la contradiction
  121. 121. Obligation réglementaire ou normative </li></ul>
  122. 122. Tests exploratoires vs. Tests scénarisés <ul><li>Alors qu'on envisage ou conçoit le test, pourquoi ne pas l'exécuter dans la foulée ? </li><ul><li>Application en expansion </li><ul><li>Facteurs </li></ul><li>Productivité mythe ou réalité </li><ul><li>Rapidité
  123. 123. Efficacité </li></ul><li>Ne pas se limiter au test « du singe » </li></ul><li>Contexte d'application </li><ul><li>Objectivité, Reproductibilité, Auditabilité
  124. 124. Capacités individuelles ou intelligence globale </li></ul><li>Pour plus d'informations </li><ul><li>Etude comparative de l'Université du Québec à Montréal </li></ul></ul>
  125. 125. Activités de test <ul><li>Au sein du Building Team </li><ul><li>Les testeurs font partie de l'équipe et donc participent au sprint planning
  126. 126. On utilise l'analyse de risques pour identifier les tâches
  127. 127. Les testeurs estiment les tâches de test
  128. 128. L'effort de test dans un sprint est fini (W=Max)
  129. 129. Les testeurs assistent les développeurs pour la définition des tests unitaires
  130. 130. Les développeurs réalisent et exécutent les tests unitaires
  131. 131. Les testeurs représentent la conscience de la qualité pour l'équipe </li><ul><li>Priorité entre toutes </li></ul></ul><li>Dans un Testing Team </li><ul><li>Application des principes Agiles </li><ul><li>Donner de la visibilité tout le temps, s'adapter aux changements dans les exigences, travailler en continu avec le métier, privilégier les rapports directs, s'améliorer continuellement, prioriser en fonction de la valeur métier, … </li></ul><li>Les interactions avec la Building Team sont régulières
  132. 132. Les rapports avec la périphérie (exploitant, fournisseurs, …) doivent être réguliers </li><ul><li>Les intégrer aux meetings si possible </li></ul></ul></ul>
  133. 133. Et les outils dans tout çà ? Quality Manager Functional Tester Demandes & Exigences Portail Capitalisation - Wiki Développement Tests unitaires Intégration continue Gestion des tests Qualimétrie Gestion de configuration SALOME TMF TEST NG
  134. 134. La transition vers plus d'Agilité et plus d'efficience dans les Tests <ul><li>Point de départ </li><ul><li>Appropriation d'une démarche Agile pour le développement
  135. 135. Appropriation d'une démarche de tests structurés (Tmap, TMM, ISTQB,...)
  136. 136. Niveau de maturité </li><ul><li>Test (TPI, TMM, ...)
  137. 137. Développement (Scrum, XP, CMMI, ...)
  138. 138. Exploitation (ITIL,...) </li></ul><li>Taille de l'organisation, de l'équipe
  139. 139. Intervention de fournisseurs extérieurs </li></ul><li>Le changement </li><ul><li>Avancer pas à pas </li></ul></ul>
  140. 140. Mettre toutes les chances de son côté <ul><li>A éviter </li><ul><li>Sous-estimer la résistance au changement
  141. 141. Sous-estimer le projet d'amélioration
  142. 142. Croire aux miracles
  143. 143. Outiller sans méthode
  144. 144. Se limiter à de la formation </li></ul></ul><ul><li>Facteurs de succès </li><ul><li>Trouver un sponsor ayant capacité de décision
  145. 145. Accompagner le changement
  146. 146. Anticiper les points de blocage
  147. 147. Choisir des projets pilotes appropriés
  148. 148. Communiquer sur les succès
  149. 149. Modérer ses ambitions </li></ul></ul>
  150. 150. Merci de votre attention Vos questions ...
  151. 151. Les prochains événements <ul><li>Mardi Gras – La Rétrospective -> 7 mai
  152. 152. XP Days - Paris -> 26 mai
  153. 153. Mardi Gras – ITIL et le support informatique -> courant juin
  154. 154. Meeting : Retours d'expérience sur la mise en oeuvre du CMMI -> automne
  155. 155. Suivre le Blog : http://social.hortis.ch
  156. 156. Prochaines entrées : </li><ul><li>Junit 4 et Mockito : Tests unitaires en langage « presque » naturel
  157. 157. Adaptation des tests unitaires aux projets Legacy
  158. 158. Les plugins essentiels de Hudson
  159. 159. Comparatif de repositories manager Maven </li></ul></ul>
  160. 160. La Rétrospective “ Transmuter le vécu en performance” L'Alchimiste-Agile.ch Mardi Gras 7 mai 2009 XP Day CH '09 – French edition François BACHMANN & Jacques COUVREUR

×