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>
Prochain SlideShare
Chargement dans…5
×

Présentation Agile Testing

9 682 vues

Publié le

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

Publié dans : Technologie, Business
1 commentaire
18 j’aime
Statistiques
Remarques
Aucun téléchargement
Vues
Nombre de vues
9 682
Sur SlideShare
0
Issues des intégrations
0
Intégrations
221
Actions
Partages
0
Téléchargements
0
Commentaires
1
J’aime
18
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • 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

    ×