Retour d'expérience TAA - 2011/03/29

  • 1,046 views
Uploaded on

Présentation : Retour d'expérience sur l'automatisation de tests d'acceptation dans un environnement Agile …

Présentation : Retour d'expérience sur l'automatisation de tests d'acceptation dans un environnement Agile

Elapse Technologies

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,046
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • PR
  • PR
  • ND
  • PR
  • PR
  • ND
  • PR
  • ND
  • PR
  • PR
  • PR
  • PR
  • PR
  • PR
  • PR
  • PR
  • ND
  • ND
  • ND
  • ND
  • ND
  • ND
  • ND
  • PR
  • PR
  • PR
  • ND
  • ND
  • PR
  • ND
  • PR
  • ND
  • PR
  • ND
  • PR
  • ND
  • PR

Transcript

  • 1. Retour d'expérience Automatisation des tests d'acceptation dans un environnement agile Elapse Technologies Inc.
  • 2. Présentations
    • Elapse Technologies
      • Spécialisé en développement Agile
        • Accompagnement, formation et impartition
        • Mission: aider clients dans leurs efforts de développement logiciel
        • Bureaux à Montréal et Québec, 7 ans déjà…
    • Vos présentateurs :
      • Nicolas Desjardins, B.Sc., CSM
      • Pascal Roy, ing., PMP, CSM
    Elapse Technologies Inc.
  • 3. Plan de la présentation
    • Revue rapide: Concepts TA en mode agile
    • Retour d’expérience sur l’automatisation des TA sur 3 projets différents
    • Recommandations générales
    • Questions
    • Tirage
    Elapse Technologies Inc.
  • 4. Pourquoi cette présentation
    • 3 projets différents :
      • Besoin d’automatiser les TA
        • 2 projets clients
          • 1 er projet: implantation agile et réalisation
          • 2 ième projet: réalisation
        • 1 projet de R&D interne
    • But: partager notre expérience et nos réflexions avec vous
    Elapse Technologies Inc.
  • 5. Concepts Établir un langage commun Elapse Technologies Inc.
  • 6. Concepts Rôle des TA en Agile
    • S’entendre sur ce qui doit être fait
      • Scénarios de tests : spécification du système
        • Langage informel ou non
        • Exemples et écrans très efficace
    • Guider le développement
      • Développeurs implémentent le code pour faire passer les cas de tests
    • Mesurer objectivement l’avancement
      • Vérification : exécution correcte du scénario = « Complété »
      • Régression : si automatisé
        • nécessaire en mode incrémental et itératif
    Elapse Technologies Inc.
  • 7. Concepts Cycle de vie typique d’un User Story Elapse Technologies Inc.
    • Acceptation:
    • Vérification & Validation
    • Vérification
    • « Construit correctement? »
    • Conforme aux spécifications
    • « Complété »
    • Validation
    • « Construit la bonne chose? »
    • Apte à l’utilisation en mode production (« Fit for use »)
    • « Complété Complété»
  • 8. Concepts Anatomie d’un TAA Elapse Technologies Inc.
  • 9. Retour d’expérience Présentation des 3 projets Elapse Technologies Inc.
  • 10. Projet #1 : Contexte
    • Projet client : Refonte bottin électronique (6m)
      • Introduction à l’Agilité
        • 1 chargé de projets + 2 analystes d’affaire (client)
        • 2,5 développeurs (1,5 seniors, 1 intermédiaire)
        • 1 testeur: programmeur très junior
      • Technologies
        • Application .NET WinForm
        • SQLServer , NHibernate + HsqlDB
        • TestComplete (Tests d’acceptation : 1 licence)
    Elapse Technologies Inc.
  • 11. Projet #1: Approche TAA Elapse Technologies Inc.
  • 12. Projet #1: Itération 1
    • Résultats
      • Courbe d’apprentissage importante pour le responsable de l’AQ (autre langage)
        • Mais, on s’en doutait
      • Aucun TAA utilisables, tests manuels avec client
    • Rétrospective
      • On pense se reprendre à l’itération 2
    Elapse Technologies Inc.
  • 13. Projet #1: Itération 2
    • Résultats
      • Testeur toujours en apprentissage
      • Certains tests de l’itération 1 automatisés
      • Doute sur la capacité d’un seul testeur de fournir tous les développeurs
    • Rétrospective
      • Nous voulons impliquer les développeurs, mais
        • Une seule licence disponible (restriction $)
        • Investir dans les développeurs pour apprendre un nouveau langage?
        • Développeurs rébarbatifs à l’idée d’apprendre un langage d’AQ
        • Finalement, on décide de mettre un consultant senior à mi-temps pour travailler en pair avec le testeur
    Elapse Technologies Inc.
  • 14. Projet #1: Itération 3-5
    • Résultats
      • Nette amélioration de la productivité des TAA
      • Arrivée du senior
        • Meilleure architecture et organisation des tests
        • Tests un peu moins fragiles
      • Toujours en retard dans les itérations
    • Rétrospective
      • On rattrape le retard…
    Elapse Technologies Inc.
  • 15. Projet #1: itération 6+
    • Résultats
      • Base de code de tests augmente beaucoup en grosseur et en complexité
      • Nouvelles fonctionnalités requièrent une approche différente
        • Refactoring majeur à faire
        • Pas d’outils pour ça dans TestComplete – travail très ardu et beaucoup d’erreurs
      • A partir de ce point, nous avons pris un retard irrécupérable
    • Rétrospective
      • Démonstration manuelle des User Stories de l’itération
      • L’approche n’est pas vraiment viable en temps réel et nous ne sommes pas prêt à investir plus
    Elapse Technologies Inc.
  • 16. Projet #1: Constat
    • Jamais en mesure d’avoir les TAA en cours d’itération, cycles désynchronisés
      • Malgré plus de 40% de l’effort dans les TAA
    • Outil TestComplete (Boite Noire)
      • Les tests sont très fragiles à des changements mineurs
        • Ex: positionnement des contrôles ou changement dans la hiérarchie visuelle.
      • Refactoring des tests ardu et potentiellement dangereux
        • Pas de bons outils de refactoring (en fait aucun)
      • Courbe d’apprentissage imposante (autre langage à apprendre)
        • Développeurs extrêmement réticents à s’investir
      • Tests pas plus faciles à lire (scripts de code)
    Elapse Technologies Inc.
  • 17. Projet #2: Contexte
    • Second projet client : Facturation (3-4m)
      • Mandat d’exécution
        • 1 chargé de projets + 2 à 3 analystes d’affaire (client)
        • 4 développeurs (3 seniors, 1 junior)
        • 1 DBA à temps partiel
      • Technologies
        • Application .NET WinForm
        • SGBDR, Procédures stockées
        • NUnitForms, Fit …
    Elapse Technologies Inc.
  • 18. Projet #2: Approche TAA Elapse Technologies Inc.
  • 19. Projet #2: Itération 1
    • L’approche fonctionne
      • Tous les tests de l’itération sont automatisés
      • Nous avons une définition exécutable de « Complété »
      • Tout le monde est bien content 
    Elapse Technologies Inc.
  • 20. Projet #2: Itération 2
    • Problème des interfaces modales
    • Léger ralentissement, solution complexe trouvée
      • Rend le code de test plus obscur (délégué) 
    Elapse Technologies Inc.
  • 21. Projet #2: Itération 3
    • Maudite base de donnée!!! ;-)
      • BD de Microsoft Dynamics (hack)
      • Couche d’affaire dans la BD (Stored Procs PLSQL)
        • Aucun tests unitaires
        • Tentative avec SQLUnit (DBA pas convaincu, non disponible)
        • BD (groupe séparé…)
        • Outils de refactoring inexistants, changements risqués
    • Donc, aucun tests sur les procédures stockées 
    • Sérieux impact sur la productivité
    Elapse Technologies Inc.
  • 22. Projet #2: Itérations 4+
    • Remarque que les tests sont plus fragiles
      • Changement dans un test brise d’autres tests…
      • Changement d’un écran requiert des changements dans plusieurs tests
    • Difficulté de mettre la BD partagée dans un état connu avant chaque test
        • Mocks peu utiles car 80% fonctionnalités dans les Stored procs
    Elapse Technologies Inc.
  • 23. Projet #2: Constat
    • Manque d’organisation dans les fixtures de tests
      • Duplication de code
      • Fragilité
    • Procédures stockées
      • Rend l’application plus dure et dispendieuse à tester
    • Malgré les problèmes de BD, l’approche TAA fonctionnait
      • Développeurs impliqués directement
    Elapse Technologies Inc.
  • 24. Projet #3
    • Organisateur d’information (R&D interne)
      • Pas en mode production…
      • 2/3 développeurs à temps partiels (interruptions)
      • Technologies
        • Java Swing , Db4o, Client-Serveur (Internet app)
        • Cross-platform (Windows/Linux/OSX)
        • Jemmy (TAA), Mockito
    Elapse Technologies Inc.
  • 25. Projet #3 : Approche TAA Elapse Technologies Inc.
  • 26. Projet #3: Objectifs TAA
    • Solutionner les problèmes de fragilité des tests
      • Navigation
      • Données de tests
    • Solutionner les problèmes d’organisation du code des tests
      • Est ce que ça existe déjà? Où?
    Elapse Technologies Inc.
  • 27. Projet #3: Constat (1/3)
    • Fragilité des tests
      • Isoler la navigation : Développement d’une fixture de navigation
        • navFixture.run(« Login en tant que l’utilisateur Pascal Roy »)
        • navFixture.run(« Affiche l’écran des préférences »)
      • Briser l’interdépendance des tests au niveau des données
        • Développement d ’une fixture de setup des données de test
        • Service : Remise à Zero des données
          • dataFixture.reset();
        • Service : Méthodes de création de données
          • dataFixture.creerEmployePascalRoy () dataFixture.creerListeDeBaseDEmployes()
      • Très simple!!!
        • Et très efficace: Stabilité accrue des tests face au changements typiques
    Elapse Technologies Inc.
  • 28. Projet #3: Constat (2/3)
    • Organisation du code des tests
      • Se donner une convention. Un écran = une fixture. (vs User Story)
        • Facile à localiser le code de fixture
        • Ou de figurer ou mettre une fixture dans la hierarchie de code
      • Avantage imprévu de cette organisation = abstraction de l’écran
        • fixture.entrerNomUtilisateur(« Pascal Roy »)
        • fixture.enterMotDePasse(« xxxxxx »)
        • fixture.login();
        • Diminue la complexité d’écrire des tests par la suite!!
    Elapse Technologies Inc.
  • 29. Projet #3: Constat (3/3)
    • Réflexion sur le processus d’acceptation dans l’itération
      • TAA représente la partie Vérification
        • Tester la conformité aux spécifications : « Complété »
      • Est-ce suffisant pour accepter un user story en cours d’itération?
        • Agile: « User Story supposément livrable à la fin d’itération»
        • Mais: Est-ce le cas???
          • Client: Est-ce que je suis confiant de livrer cette fonctionnalité?
        • Rôle de la revue d’itération
          • Certaine validation par le client (exécution manuelle des scénarios)
            • Manque certains tests (utilisabilité, exploration, performance…)
            • Par contre, est-ce possible en cours d’itération?
          • Difficile d’obtenir le « Complété Complété »
    Elapse Technologies Inc.
  • 30. Recommandations Elapse Technologies Inc.
  • 31. Recommandations TAA (1/8)
    • Avoir des attentes réalistes lors de la mise en place des TAA
      • Ce n’est pas simple, mais incontournable pour supporter le développement itératif efficace
      • Ne minimisez pas la courbe d’apprentissage
        • Expérimentez outils et techniques sur de petits projets pilotes
      • La direction doit supporter l’équipe pleinement
        • Il y aura de nombreuses embûches
    Elapse Technologies Inc.
  • 32. Recommandations TAA (2/8)
    • Comprenez les limites des TAA
      • Excellent pour la Vérification
        • Mais n’adresse pas nécessairement la validation
        • D’autres types de tests sont nécessaires:
          • Utilisabilité, performance, exploration…
      • Pour pouvoir livrer « Complété Complété », le client devra «valider » le système (fit for use)
        • La confiance ultime du client envers le logiciel est plus dans la validation que dans la vérification!!!
    Elapse Technologies Inc.
  • 33. Recommandations TAA (3/8)
    • Impliquer l’équipe au complet
      • Les développeurs doivent être impliqués.
        • Sinon, désynchronisation Code/Test
        • Responsabilisation
          • le test doit fonctionner pour que code soit « Complété »
      • Erreur communes
        • Confier le développement des tests exclusivement à l’AQ
        • Confier le développement des tests à des juniors (développeurs ou testeurs)
    Elapse Technologies Inc.
  • 34. Recommandations TAA (4/8)
    • Spécification des scénarios de test: Requiert la collaboration de toute l’équipe
      • Clair pour tous : définition de « Complété »
      • Concrétiser cette définition
        • Exemples concrets
        • Prototypes d’écrans
        • Tout ce qui peur aider à clarifier l’intention du test…
      • Symptôme typique de non collaboration:
        • scénarios de tests écrits exclusivement par les développeurs…
    Elapse Technologies Inc.
  • 35. Recommandations TAA (5/8)
    • Automatiser ce qui est le plus critique: 80/20 (Pareto)
      • Scénario principal de chaque User Story
      • Réfléchir au ROI pour les scénarios secondaires ou cas d’exceptions
        • Ils seront validés manuellement lors de l’acceptation avec le client
      • !(Tout ou rien):
        • 10% mieux que 0%, 20% mieux que 10%,...
        • Inspection and adaptation
    Elapse Technologies Inc.
  • 36. Recommandations TAA (6/8)
    • Rechercher la simplicité dans l’approche
      • Utiliser des outils que vous connaissez déjà en priorité
        • IDE, langages,…
      • Réduire le nombre d’outils impliqués
      • Implémenter les tests au niveau le plus approprié
        • Test unitaire/Test intégration/Test acceptation partiel/Test acceptation End to End
          • Ex: règle d’affaire (couche domaine)
        • Tester tout End To End = duplication dans les tests des différents niveaux.
    Elapse Technologies Inc.
  • 37. Recommandations TAA (7/8)
    • Maintenez vos tests à jours
      • Donner lui le même amour que le code de production
        • Bonnes pratiques de développement
        • Organiser bien vos tests et vos fixtures de tests
          • Ex: une fixture par contexte d’interaction
        • É viter la duplication de code comme la peste
      • Les cas de tests représentent les spécifications fonctionnelles du système en format exécutable
        • Certains utilisent les TAA pour générer la documentation utilisateur à partir des cas de tests automatisés (Framework Naked Objects)
    Elapse Technologies Inc.
  • 38. Recommandations TAA (8/8)
    • Solidifier vos tests
      • Éviter des dépendances inutiles
        • Ex: pour tester si un nouvel employé a été ajouté
        • assertEquals(5, employeeListFixture.count()); //non
        • assertEquals(previousCount+1, employeeListFixture.count()); //ok
        • assertTrue(employeeListFixture.holdsEmployee(newEmployee)); //ok
      • Rendre les tests indépendants les uns des autres
        • Toujours connaître l’état de départ du test
        • Pour des TAA, le côté performance est un moins critique que pour des tests unitaires
    Elapse Technologies Inc.
  • 39. Questions? 10 minutes… Tirage Suite question (au besoin) Elapse Technologies Inc.
  • 40. Mot de la fin
    • Annonce: Formation « Clean Code »
      • Robert «Uncle Bob » Martin : signataire Manisfeste Agile
      • Formation 2 jours, le 27 et 28 Octobre (Québec)
        • S’adresse aux développeurs
        • Reconnaître du code « propre » et « malpropre »
        • Comprendre son impact sur la maintenabilité
        • Apprendre principes et utiliser des techniques pratiques
        • pour améliorer la qualité de votre code
    • Pour plus d’information : www.elapsetech.com
    • Tirage du livre « Clean Code » dédicacé par Bob.
    Elapse Technologies Inc.