Stratégie de tests : la faire bien pour en faire moins

Une stratégie de tests, on sait tous que c’est nécessaire, mais sans forcément savoir à quoi ça ressemble.
Une stratégie de tests est la façon de s’organiser pour montrer qu’une application est de qualité suffisante pour aller en production. Il ne s’agit donc pas d’un inventaire de tests manuels ou automatisés, mais d’un raisonnement avec des choix et des renoncements.
Dans cette présentation nous verrons comment une stratégie de tests vise à optimiser la confiance et les preuves de qualité dans le cadre du développement d’un produit agile.

Transcript

1. Stratégie de Test La faire bien pour en faire moins
2. Nicolas Fédou • Artisan Développeur chez • Coach Craft • Aka. Coach Technique • Aka formateur et accompagnant en bonnes pratiques de développement agile • Ex-Testeur du logiciel des CFM56 (Moteur d’avion) 2
3. L’origine • Développement en phases longues • IE. : Livraison tous les 6 mois => 6 livraisons en 3 ans • Livraison de périmètres fonctionnels complets, non remis en cause plus tard (dans l’idéal ☺) Valider Appels Code « métier » T 3
4. L’origine Stratégie de tests : l’art de sélectionner les tests fonctionnels à jouer pour éviter les régressions et évidement montrer la présence des évolutions 4
5. De nos jours : Vision Produit Il n’y a pas de date de fin Le périmètre fonctionnel itère de semaine en semaines • 1 livraison / 2 semaines=> 6 livraisons en 3 mois ! • Re-travail fréquent du code pour intégrer les slices suivants, les fonctionnalités suivantes • Autant d’évènements stressants pour le code 5
6. Vision Produit et itérations On livre plus de valeur, plus vite, plus souvent Un produit agile vit plus vite ! 6
7. Vision Produit et itérations Un produit agile vieillit plus vite ! Les qualités, fonctionnalités ET les défauts s’expriment plus souvent 7
8. S’organiser seulement pour livrer : « à la James Dean » Livrer permet juste d’entrer dans la course L’édition de logiciel est un coût Un logiciel ne rapporte qu’en production 8
9. La qualité permet de rester dans la course Les tests sont des preuves de qualité une documentation S’organiser seulement pour livrer : « à la James Dean » 9
10. Dual track (for one team) -- Jeff Patton et Marty Cagan S’organiser pour durer 10
11. Une stratégie de tests : •Est l’ensemble des moyens et pratiques que l’on se donne pour construire un produit de qualité. •Est une façon de s’organiser pour avoir toutes les preuves de qualité logicielle nécessaires et suffisantes à moindre effort pour livrer le produit en continu. 11
12. La stratégie de tests seule n’existe pas… Elle est inclue/diluée dans une approche produit globale Dans une vision produit (de qualité) La stratégie de tests seule devient un sujet quand les pratiques de tests existantes ne suffisent plus 12
13. Le test en théorie • Un test, c’est exercer une pression sur un système Pour en constater la réponse Pour obtenir un feedback délibérément • Dijkstra: Testing shows the presence, not the absence of bugs NATO SOFTWARE ENGINEERING CONFERENCE 1969 13
14. Le test en pratique •Un test montre un fonctionnement attendu Il réduit la probabilité d’un défaut sur une fonctionnalité •Un ensemble de tests décrivant toutes les facettes d’une fonctionnalité… + de mesures, - de surprises •Nombre de tests, périmètre fonctionnel et volume de code évoluent ensemble 14
15. Le compromis • La stratégie de tests : • Permet d’obtenir des preuves de qualités • Permet de stabiliser le présent et de se concentrer sur l’avenir • Permet de se protéger d’un risque de défaut futur • Mais cela représente un effort qui coûte
16. Priorisation par les risques Coût d’un risque = probabilité perçue * impact perçu Rentabilité d’un test = coût du risque / coût du test George Fairbanks, Chapter 3 of the book Just Enough Software Architecture: A Risk-Driven Approach http://www.methodsandtools.com/archive/agilesoftwarearchitecture.php Preuves de qualités Confiance Zone de fiabilité Zone d’acceptation du risque 16
17. Cartographie des risques Probabilité Impact Sans impact Improbable Haut risque Dan North, in Testing Faster workshop 17
18. Types de Risques • Explicites : • Visibles, souhaitées • Implicites : • Évidentes … si on y pense -- Pascale Lagière, 18
19. Modèle de qualité logicielle ISO 25010 (2011) remplace l’iso 9126 (2001) Critères de qualité https://www.iso.org/obp/ui/#iso:std:iso-iec:25010:ed-1:v1:en §4.2 19
20. Modèle de qualité logicielle ISO 25010 (2011) remplace l’iso 9126 (2001) Nouveauté 2011 !!! Critères de qualité https://www.iso.org/obp/ui/#iso:std:iso-iec:25010:ed-1:v1:en §4.1 20
21. Moyens de tests Par Brian Marick, diffusé par Lisa Crispin et Janet Gregory Gojko Adzic en propose une mise à jour en 2013 21
22. Test FIRST Tests avant le code ! • Implémentation • Vérification d’un travail fini • Objectif à atteindre • Fonctionnalité attendue • Fast • Rapide • Isolated • Une raison d’échouer • Repeatable • Self Validating • Validation automatique • Timely • Avant le code de production 22
23. Test : moteur du développement • Test Driven Development (TDD) • Test FIRST + • Code de production sans tests • Minimum de tests pour être non passant • Minimum de code de production pour le faire passer • Seulement les API • Conception et clean code seulement en phase de refactoring 23
24. Test FIRST en équipe BDD : Behaviour Driven Development • Spécifications exécutables • Aligner l’équipe sur des exemples concrets • scénarii conçus en équipe • Format automatisable 24 -- Alberto Brandolini
25. Au-delà du test FIRST Approval Testing : valider un résultat obtenu au lieu de le définir à l’avance • Un test sans assert : un simulateur de cas • Faire valider le résultat par un tier • Mettre en avant et valider les différences 25
26. Tests et niveau d’abstraction Valider Appels Code « métier » T 26 End to End
27. Tests et niveau d’abstraction _ |_| X Valider Appels Code « métier » Tous les leaders d’opinions sur BDD, dooble looop, TDD outside-in ou non 27
28. Tests et niveau d’abstraction _ |_| X Valider Appels Code « métier » Tests d’intégration système End to End Tests d’intégration logicielle et unitaires Tous les leaders d’opinions sur BDD, dooble looop, TDD outside-in ou non 28 Tester les détails d’une fonctionnalité depuis l’API la plus proche de l’implémentation Moins de code à stimuler, tests plus simples à implémenter Les tests fonctionnels ne sont pas que de bout en bout (End to end)
29. Tests et niveaux d’abstraction Quantité de code stimulé abstraction fonctionnelle Mike Cohn : Pyramide de tests Gerard Meszaros : The right abstraction level for your tests Concret Abstrait 29
30. Réduire l’effort de tests WS Impl App Layer Repositories Aggregate Root Domain Object Domain Object Shared Utility Shared Model 30
31. Réduire l’effort de tests • Tests manuels sur des zones de code stables et ne répondant qu’à un cas d’usage • Déploiement, une partie du socle technique (configuration, …) • Non régression par transitivité (Si B est correct, A doit être correct) • Si les tests d’intégrations passent, l’application est déployable 31
32. Conseil en stratégie de tests 32
33. Merci ! 33