20110519 cara tests_agiles_grenoble_all

Tests Agiles Rencontre agile Grenoble Jeudi 19 Mai 2011Nicolas PELLOUX-PRAYER – Amaris Johan Martinsson - Indépendant Sylvain FRANCOIS - KalisticEmail : npellouxprayer@gmail.com Email : martinsson.johan@gmail.com Email : sylvain.francois@kalistick.frTwitter: @npelloux Twitter: @johan_alps Twitter: @syllant www.clubagile.org

Evénements 26 et 27 mai 2011 – Paris conf.agile-france.org www.clubagile.org

Evénementswww.breizhcamp.org www.clubagile.org

Evénements 7 juin 2011 – Lyon lyon.clubagile.org www.clubagile.org

Plan• Historique• Coût dun bug• Approche classique• Catégorisation des tests• Apport des principes Agiles• Pourquoi faut-il soigner sa pyramide de tests• Indicateurs de qualité• « Tester juste »• Spécificités d’un projet agile www.clubagile.org

Un peu d’histoire…1968 => Génie logiciel www.clubagile.org

• Tests décorrélés• Rôle de la QA• Centré sur la doc www.clubagile.org

Tests décorrélés www.clubagile.org

Rôle de la QA• Dernier rempart• Tensions avec le dev www.clubagile.org

Documentation • Lourd • Utile ? www.clubagile.org

Coût de détection 1.Détection d’un bug 2.Impact 3.Résolution www.clubagile.org

Agile testing quadrant www.clubagile.org

Soutien de l’équipe• les tests de gauche sont là pour aider l’équipe !• Q1 aide à construire la qualité interne du logiciel• Q2 définit les features que le client souhaite et la qualité externe• Fournissent un feedback rapide et un guide aux développeurs www.clubagile.org

Critique du produit• Q3 permet de savoir si le produit est efficace et adapté.• Q4 permet d’évaluer la performance, robustesse et sécurité.• Les tests de critique produit pourront fournir des entrées pour les carrés de gauche. www.clubagile.org

Approche agile www.clubagile.org

Individus et interaction• Responsabiliser l’équipe• Tout le monde teste www.clubagile.org

Alléger les procédures• Doc => Checklist• Priorisation des tests• Esprit critique• Cf. Exploratory testing www.clubagile.org

Adaptation au changement• Tester au plus tôt – TDD• Tester plus vite – Automatisation des tests• Tester plus souvent – Intégration Continue www.clubagile.org

Attention au « Done – Done »Développement ET Tests ! www.clubagile.org

Références• Elisabeth Hendrickson• Lisa Crispin• Cem Kaner www.clubagile.org

Indicateurs de qualité pour les tests unitaires et fonctionnelsSylvain FRANCOISDirecteur R&D www.clubagile.org

• Start-up lyonnaise (2007)• Plateforme SaaS – Qualité des développement – Optimisation de la phase de test / validation• Forte activité R&D – Développement orienté Agile – Vraie activité de recherche www.clubagile.org

Tester, c’est bien.Bien tester, c’est mieux. « Tester juste » Indicateurs de qualité des tests www.clubagile.org

Sommaire• La vision « Tester Juste »• … appliquée aux tests unitaires• … appliquée aux tests fonctionnels• Spécificités pour un projet Agile www.clubagile.org

La vision« Tester Juste » www.clubagile.org

Tester coûte cher Coût Tests manuelscumulé Tests automatisés ROI Temps … ROI souvent difficile à mesurer www.clubagile.org

Le coût de l’automatisation• Conception / mise en œuvre – Profils experts• Analyse des résultats• Licences produits / TCO• Coûts matériels (à la demande sur le Cloud)• Maintenance des tests• Délais d’exécution www.clubagile.org

La question : que tester ?• Souvent difficile de tout tester• Quelques critères de choix : – Ancienneté du code – Intérêt / criticité pour le client – Risques techniques – Résultats des tests précédents – Charge de test / Planning www.clubagile.org

Collaboration développeur - testeur• Pierre d’achoppement récurrente• Objectifs parfois différents• Vision code / vision fonctionnelle• Outils différents (idem pour développeur – exploitant) www.clubagile.org

Le « Tester Juste » appliqué auxTests Unitaires (TU) www.clubagile.org

Précisions sur les tests unitaires• Test isolé d’une méthode de code• Utilisation de frameworks de TU – JUnit, TestNG, MSTest, NUnit, …• Utilisation de bouchons (« mocks »)• Automatisables• TDD (Test Driven Development) www.clubagile.org

Inconvénients du TDD• Niveau d’acceptation des TU dans les projets• Toute méthode mérite-t-elle d’être testée ?• Difficulté de tester certains traitements• Refactoring du code testé• Pertinence des TU ? www.clubagile.org

Mesurer la couverture des TU• Outils de coverage – Enregistrent l’exécution – Résultat : taux de code exécuté (%) – Exemples : • Java : JaCoCo, Cobertura, EMMA, … • C# : MSCoverage, NCover, dotCover, … Couverture 100%• Pertinence du taux de couverture ?• Coût pour atteindre les 100% Effort www.clubagile.org

Proposition : cibler ses TU• Prioriser les TU selon : – Le risque fonctionnel / métier – Le risque technique – L’effort de test• Mesurer le niveau de test – Mais de manière pragmatique www.clubagile.org

Le TestRelevancyIndex (TRI) [1/2]• Index créé par Kalistick + CETIC (labo de recherche)• Qualifie l’intérêt de chaque traitement à être testé – méthode, classe, composant, …• Basé sur des métriques unitaires – Complexité, paramètres, variables, dépendances, bugs, …• … et sur le risque métier• Ajuste l’objectif de couverture www.clubagile.org

Le TestRelevancyIndex (TRI) [2/2] Couverture des TU pondérée par le TRI www.clubagile.org

Le « Tester Juste » appliqué auxTests Fonctionnels www.clubagile.org

Notre vision• Privilégier les tests sur le code modifié – Les nouvelles fonctionnalités – Les risques de régression• Vérifier ce qu’ont couvert les tests – Après leur exécution (coverage)• Enrichir le référentiel / plan de test• Faciliter la collaboration développeur - testeur www.clubagile.org

Identifier les modifications du codeCode modifié Modifications non tracées Régressions Nouveautés, Modifications tracées Corrections Niveau de risqueCode non modifié Bugs non critiques Bugs dormants RAS « Old good code » www.clubagile.org

Questions cibles• Qu’est-ce qui a changé entre 2 versions ? – Consolider sa stratégie de test• Les modifications ont-elles été testées ? – Eviter les régressions• Quels scénarios de tests doivent être joués ? – Plan d’action concret pour les testeurs www.clubagile.org

Le testeur est mon ami• Objectifs : – Indicateurs exploitables par le testeur – Améliorer la collaboration testeur – développeur• Le défi : remonter du code au testeur – Modéliser les fonctionnalités de l’application – Réutiliser le référentiel de test • HP Quality Center, TestLink, … www.clubagile.org

Exemple de rendu [1/3]Couverture globale des tests fonctionnels et unitaires www.clubagile.org

Exemple de rendu [2/3] Couverture par fonctionnalités www.clubagile.org

Exemple de rendu [3/3] Fonctionnalités impactées Fiche User Story (dans l’outil JIRA) www.clubagile.org

Les spécificités pour un projet Agile www.clubagile.org

Rôle développeur - testeur• Dans la littérature Agile : un seul profil – Dans la réalité ?• Le testeur Agile est plus proche du code – Plus à même d’analyser les résultats de couverture www.clubagile.org

Risque d’instabilité plus élevé• Adaptabilité aux besoins – Mise à jour des User Stories – Mise à jour des cas de test• Techniques de développement à risques – Refactoring – Qualité du code ! Besoin accru d’automatisation des tests www.clubagile.org

Processus de livraison agile• Rythme de livraison plus soutenu – Notion de « Continuous Delivery » – Besoin de sécuriser la livraison• Indicateurs de DONE – Inclure la couverture des tests fonctionnels ? www.clubagile.org

http://blog.kalistick.comhttp://twitter.com/kalistickhttp://www.kalistick.commailto:sylvain.francois@kalistick.fr www.clubagile.org

Et vous ? www.clubagile.org

20110519 cara tests_agiles_grenoble_all

by CARA_Lyon

Accessibility

Categories

Upload Details

Usage Rights

Statistics

20110519 cara tests_agiles_grenoble_all Presentation Transcript