Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Strategie de test à agile tour bordeaux

197 vues

Publié le

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.

Publié dans : Ingénierie
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Strategie de test à agile tour bordeaux

  1. 1. Stratégie de Test La faire bien pour en faire moins 1
  2. 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. 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. 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. 5. Les demandes clients d’aujourd’hui • Nous avons du mettre en place une phase de stabilisation, mais • Elle nous prend du temps et de l’énergie Temps QA / Stabilisation 5
  6. 6. Itération Données / IO Tests Ambiance Sprint 0 S + 1 S + 2 Les demandes clients d’aujourd’hui • Nous avons une campagne de tests automatisés, mais • Elle nous demande trop d’efforts • À concevoir ou produire • À maintenir • Elle dure trop longtemps • La CI bloque de plus en plus • Les développeurs ne les lancent plus 6
  7. 7. Une stratégie de tests « agile » •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. 7
  8. 8. Stratégies d’hier Tests fonctionnels End 2 End : manuels ou « manuels robotisés » Sur toute la stack technique Valider Appels Code « métier » T 8
  9. 9. Stratégies d’hier Tests fonctionnels End 2 End : une « user journey » de bout en bout End Start M O S C O W 10
  10. 10. 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 11
  11. 11. La qualité permet de rester dans la course Les tests sont des preuves de qualité S’organiser seulement pour livrer : « à la James Dean » 12
  12. 12. • 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 Comme d’habitude ☺ Le test en théorie 14
  13. 13. Program testing can be used to show the presence of bugs, but never to show their abscence ! Notes on Structured programming, 1970 Edsger Djikstra 15
  14. 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, - d’évolutions sans casser de tests 16
  15. 15. Nous avons le budget pour produire la qualité, mais pour … • La démontrer avec des tests, avant la mise en production • Faire face aux risques (sécurité, pannes, …) • Tenir tous les enjeux (performance, charge, …) Les critères de qualités n’ont pas de limites, nos budgets en ont une.17 Qualité Vs Budget
  16. 16. Priorisation par les risques Coût d’un risque = probabilité perçue * impact perçu 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 18
  17. 17. Priorisation par les risques Risques non acceptables Efforts de tests rentable Risques acceptable (enfin, je crois) Efforts de monitoring (pour être sûr) Risques acceptables et indolores Corrections à la demande 19
  18. 18. Cartographie des risquesProbabilité Impact Sansimpact Improbable Haut risque Dan North, in Testing Faster workshop20
  19. 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 21
  20. 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 §22
  21. 21. Fonctionnalité Complète, Correcte, Appropriée • Behaviour Driven Development • Use case • Règles de gestion • Tests fonctionnels manuels • Workflow/E2E • Métriques applicatives • Demos 23
  22. 22. Efficience Temps, Ressources, Capacité • … • Tests de performances/charge • Monitoring système et applicatif • Demos • Oui, des rapports de tirs de Performance, etc. 24
  23. 23. Compatibilité Coexistence (i.e. : avec du legacy), Interopérabilité • Consumer Driven Contracts • Approval Testing • Double Run / Suivi de Production • Demos 25
  24. 24. Utilisabilité Approprié, Apprenable, Opérable, Sécurisé pour l’utilisateur, Esthétique, Accessible • Tests d’intégration • Ou fonctionnel dédié • Tests de Régression Visuelle • Tests Exploratoires • Métriques Applicatives • Demos 26
  25. 25. Fiabilité Maturité, Disponibilité, Tolérance aux Pannes, Récupérabilité • Tests sur le gestion des pannes • Et la journalisation en tant que guide de suivi de prod • Tests d’endurance, charge • Chaos Monkeys • Mean Time Between Failures • Taux d’échec de mise en prod • Demos 27
  26. 26. Sécurité Confidentialité, Intégrité, Non répudiation, Responsabilité, Authenticité • Tests négatifs • Un utilisateur inconnu n’obtient pas la fonctionnalité • Audit de vulnérabilités • Pistes d’audit • Demos 28
  27. 27. Maintenabilité Modularité, Réutilisabilité, Analysabilité, Modifiabilité, Testabilité • Compile !, ArchUnit • Clean Code, Pair Programming • Test first • Revue de Code • Analyse de code statique (Sonar) • Productivité de l’équipe de réalisation • Demos 29
  28. 28. Portabilité Adaptabilité, Installabilité, Remplaçabilité • Intégration et livraison continue • Conteneurisation (Docker) • Infra as code • ansible-test sanity --list-tests • Molecule • Ansible-test integration –docker-no-pull –v […] • Kubernetes en service managé • Demos 30
  29. 29. Avant Après l’écriture du code Fonctionnels Décrit / défini le produit Supporte le produit Techniques Les tests se sont adaptés Prescriptif Descriptif Par Brian Marick, diffusé par Lisa Crispin et Janet Gregory Gojko Adzic en propose une mise à jour en 2013 31
  30. 30. Les tests prescriptifs se sont adaptés M O S C O W 32
  31. 31. « Une » stratégie d’aujourd’hui _ |_| X Valider Appels Code « métier » Tous les leaders d’opinions sur BDD, dooble looop, TDD outside-in ou non 33
  32. 32. « Une » architecture testable WS Impl App Layer Repositories Aggregate Root Domain Object Domain Object Shared Utility Shared Model 34
  33. 33. Tests d’intégration « boite blanche » WS Impl App Layer Repositories Aggregate Root Domain Object Domain Object Shared Utility Shared Model Narrow Integration Test API Call API Mock System Under Test 35
  34. 34. Tests unitaires « fonctionnels ? » WS Impl App Layer Repositories Aggregate Root Domain Object Domain Object Shared Utility Shared Model Unit Test API Call System under test 36
  35. 35. Security, caller error’s management Tests unitaires « techniques ? » WS Impl App Layer Repositories Aggregate Root Domain Object Domain Object Shared Utility Shared Model Unit Test API Call Unit Test Unit Test API Mock Utils by use as « nullOrEmpty » ➔ Cover by caller’s tests Utils by rule as « Financial Maths » ➔ Cover as a Library you own Technical support 37
  36. 36. 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 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) 38
  37. 37. Tests et niveaux d’abstraction Quantitéde codestimulé abstraction fonctionnelle Mike Cohn : Pyramide de tests Gerard Meszaros : The right abstraction level for your tests Concret Abstrait 39
  38. 38. Réduire le coût d’écriture des tests • Générateur de données • Data set builder • DataSetBuilder .makePromotion(shops=4, packaging.as(40 XXL, 60L, 200S, 1000XS), TEC=80%) • Factories : données référentielles • Given.REGISTERED_USER, GIVEN.anyUser() • Builder : variabilité composable par cas de tests • Given.aCustomeUser().withTrips({}).withFriends({}).build() 40
  39. 39. Réduire le coût d’écriture des tests • Librairie d’assertions • Assertj • assertThat(boolean).isTrue().IsNull(); • assertThat(test).containsIgnoringCase(Text); • assertThat(pojo).IsEqualIgnoringNullsTo(nex ExpectedPojo(field1, null, field3)); • Custom Business Difference Tool • Ignore derivated data from calculation • Ignore déclarative data (as user comments) • Etc. 41 • Test Data Record and Replay • Spring aspect • Debug and snippet • Xstream
  40. 40. « should_return_empty_when_friend_has_no_trips » Is valuable as a documentation ? 42
  41. 41. 43
  42. 42. 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 productionFIRST Quality ! 44
  43. 43. 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 45
  44. 44. Test FIRST en équipe BDD : Behaviour Driven Development • Spécifications exécutables -- Alberto Brandolini46

×