4. Evénements
7 juin 2011 – Lyon
lyon.clubagile.org
www.clubagile.org
5. Plan
• 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
www.clubagile.org
13. 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
14. 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
17. Alléger les procédures
• Doc => Checklist
• Priorisation des tests
• Esprit critique
• Cf. Exploratory testing
www.clubagile.org
18. Adaptation au changement
• Tester au plus tôt
– TDD
• Tester plus vite
– Automatisation des tests
• Tester plus souvent
– Intégration Continue
www.clubagile.org
19. Attention au « Done – Done »
Développement
ET
Tests !
www.clubagile.org
21. Indicateurs de qualité
pour les tests
unitaires et fonctionnels
Sylvain FRANCOIS
Directeur R&D
www.clubagile.org
22. • 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
23. Tester, c’est bien.
Bien tester, c’est mieux.
« Tester juste »
Indicateurs de qualité
des tests
www.clubagile.org
24. 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
26. Tester coûte cher
Coût Tests manuels
cumulé Tests automatisés
ROI
Temps
… ROI souvent difficile à mesurer
www.clubagile.org
27. 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
28. 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
29. 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
30. Le « Tester Juste »
appliqué aux
Tests Unitaires (TU)
www.clubagile.org
31. 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
32. 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
33. 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
34. 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
35. 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
37. Le « Tester Juste »
appliqué aux
Tests Fonctionnels
www.clubagile.org
38. 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
39. Identifier les modifications du code
Code modifié
Modifications non tracées
Régressions
Nouveautés,
Modifications tracées
Corrections Niveau
de
risque
Code non modifié
Bugs non critiques Bugs dormants
RAS « Old good code »
www.clubagile.org
40. 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
41. 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
42. Exemple de rendu [1/3]
Couverture globale des tests fonctionnels et unitaires
www.clubagile.org
43. Exemple de rendu [2/3]
Couverture par fonctionnalités
www.clubagile.org
44. Exemple de rendu [3/3]
Fonctionnalités
impactées
Fiche User Story (dans l’outil JIRA)
www.clubagile.org
46. 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
47. 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
48. 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