20110519 cara tests_agiles_grenoble_all
50
www.clubagile.org Tests Agiles Rencontre agile Grenoble Jeudi 19 Mai 2011 Nicolas PELLOUX-PRAYER – Amaris Email : [email protected] Twitter: @npelloux Sylvain FRANCOIS - Kalistic Email : [email protected] Twitter: @syllant Johan Martinsson - Indépendant Email : [email protected] Twitter: @johan_alps
-
Upload
caralyon -
Category
Technology
-
view
945 -
download
0
description
Rencontre CARA Grenoble - 19 Mai 2011@npelloux@johan_alps@syllant
Transcript of 20110519 cara tests_agiles_grenoble_all
www.clubagile.org
Tests Agiles
Rencontre agile GrenobleJeudi 19 Mai 2011
Nicolas PELLOUX-PRAYER – Amaris
Email : [email protected]
Twitter: @npelloux
Sylvain FRANCOIS - Kalistic
Email : [email protected]
Twitter: @syllant
Johan Martinsson - Indépendant
Email : [email protected]
Twitter: @johan_alps
www.clubagile.org
Evénements
26 et 27 mai 2011 – Paris
conf.agile-france.org
www.clubagile.org
Evénements
www.breizhcamp.org
www.clubagile.org
Evénements
7 juin 2011 – Lyon
lyon.clubagile.org
www.clubagile.org
• Historique• Coût d'un 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
Plan
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
• Dernier rempart
• Tensions avec le dev
Rôle de la QA
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 fonctionnels
Sylvain 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.
Indicateurs de qualitédes tests
« Tester juste »
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
… ROI souvent difficile à mesurer
Temps
Coûtcumulé
Tests manuelsTests automatisés
ROI
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é aux
Tests 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, …
• Pertinence du taux de couverture ?
• Coût pour atteindre les 100%
100%
Effort
Couverture
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é aux
Tests 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 code
Régressions
Nouveautés,
Corrections
Bugs dormants
« Old good code »
Niveau
de
risque
Co
de
mo
dif
iéC
od
e n
on
mo
dif
ié
Modifications non tracées
Modifications tracées
Bugs non critiques
RAS
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]
Fiche User Story (dans l’outil JIRA)
Fonctionnalités impactées
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.com
http://twitter.com/kalistick
http://www.kalistick.com
mailto:[email protected]
www.clubagile.org
Et vous ?
