Rencontre CARA Grenoble - 19 Mai 2011 @npelloux @johan_alps @syllant

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

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

3. Evénements
www.breizhcamp.org
www.clubagile.org

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

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

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

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

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

10. Documentation
• Lourd
• Utile ?
www.clubagile.org

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

12. Agile testing quadrant
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

15. Approche agile
www.clubagile.org

16. Individus et interaction
• Responsabiliser l’équipe
• Tout le monde teste
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

20. Références
• Elisabeth Hendrickson
• Lisa Crispin
• Cem Kaner
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

25. La vision
« Tester Juste »
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

36. Le TestRelevancyIndex (TRI) [2/2]
Couverture des TU pondérée par le TRI
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

45. Les spécificités pour
un projet Agile
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

49. http://blog.kalistick.com
http://twitter.com/kalistick
http://www.kalistick.com
mailto:sylvain.francois@kalistick.fr
www.clubagile.org

50. Et vous ?
www.clubagile.org