AFUP Day Poitiers 2024 - Définir sa stragégie de test

Hello,

Voici les slides de ma présentation "Définir sa stratégie de test" lors de l'AFUP Day 2024 à Poitiers.

Désolé pour ceux qui ne la découvrirons que maintenant, vous n'aurez pas tous les détails / justifications orales qu'il y a eu avec... Je reste disponible si vous avez des questions ;)

Transcript

1. Définir sa stratégie de test Donovan Bourlard AFUP Day Poitiers - 24 mai 2024 1
2. Qui commence ses revues de code en lisant les tests ? 2
3. Pourtant les tests donnent pleins d’indicateurs : • Ils documentent le code • S’ils sont trop complexes, ils peuvent pointer un souci de conception de code • S’ils ne sont pas clairs / mal nommés ◦ Ils ne seront pas compris ◦ Ils vont finir détournés voire supprimés / dupliqués Pourquoi commencer ses revues par lire les tests ? 3 “ J’ai fait une review minutieuse du code source et il y a des tests, chouette ! Je ne m’attarde pas à les lire, ils vont refléter le code source “
4. Qu’est ce qu’il se passe sans direction claire ? 4 Les tests dérivent et on perd confiance dans la couverture et qualité des tests • Je ne comprends pas un test, je le laisse de côté • Un scénario ne semble pas testé, je rajoute le test • J’oublie de tester certaines classes • J’oublie de tester certains scénarios Suppression Et dans 2 ans ? Manque de couverture Compensation en e2e Duplication
5. On constate souvent un code source travaillé et des tests “négligés” Et si on mettait un peu d’ordre dans tout ça ? 5
6. Qui suis-je ? Donovan Bourlard @Yousign Développeur depuis 2015 J’aime le dev, la qualité de code et le travail d’équipe Au quotidien, je joue avec du DDD / Hexa / CQS / AMQP 6 DonovanBourlard
7. Définir sa stratégie de test 7
8. On commence par se documenter Ça veut dire quoi “Tester” ? 8
9. Pourquoi tester son application ? On veut s’assurer que : • Les fonctionnalités ne sont pas buggées • L’application correspond bien au besoin du client / de l’équipe produit Avec différents moyens possibles : • Tests automatisés • Cahier de recette testé manuellement • En production, par l’utilisateur final 9
10. La pyramide des tests Tests unitaires (~70%) Tests de composants / intégrations (~20%) Tests fonctionnels (~10%) https://blog.octo.com/la-pyramide-des-tests-par-la-pratique-1-5 10
11. Mon interprétation concrète Tests unitaires On teste une méthode/classe PHP sans contact extérieur Tests de composants On teste une classe PHP avec ses dépendances, sans sortir de l’application Tests d’intégrations On teste une classe PHP avec ses dépendances, en interagissant avec l’extérieur (ex: requête à la base de données) Tests de contrats On teste nos contrats HTTP, nos validations, nos ACL Tests end-to-end (e2e) Test du système via interface (Site web) ou client HTTP (API) 11 https://blog.octo.com/la-pyramide-des-tests-par-la-pratique-1-5
12. Mais aussi d’autres typologies de tests … Tests de performances Tests de résiliences Tests de sécurité Tests de fumée / Smoke tests Monkey tests … 12 Se documenter : ISTQB + Les familles de tests (Norme ISO/IEC 25010)
13. Et la stratégie de test, dans tout ça ? 13
14. 14 Qu’est ce qu’une stratégie de test ? “ Documentation alignée sur la politique de test qui décrit les exigences génériques pour les tests et détaille la façon d'effectuer les tests au sein d'une organisation. Source : ISTQB.org
15. 15 Qu’est ce qu’une stratégie de test ? Image : https://latavernedutesteur.fr/2019/08/19/politique-strategie-et-plans-de-test/ Exemple d’une politique de test : https://dt.bosa.be/sites/default/files/download s/Testing_Policy_v1_FR.pdf “A guide to mastering test strategy” https://muuktest.com/blog/test-strategy
16. Étudions un exemple concret au niveau d’un projet 16 Une stratégie de test peut être écrite au niveau organisationnel (entreprise) mais aussi au niveau d’un projet (un niveau plus bas).
17. Notre fil rouge 17 L’AFUP commande une refonte de son site web
18. La méthode que nous allons utiliser 18 On va simplement réfléchir la stratégie de test autour de questions simples … Quoi ? Qui ? Comment ? Quand ? Où ? On va itérer sur ces questions jusqu’à avoir notre stratégie de test définie
19. Quelles sont les personnes qui vont travailler sur le projet ? On commence notre analyse … 19
20. • Back / Front / Inté • 1 ou 2+ équipes Développement • Inclus dans l’équipe de Dev • Équipe dédiée • Extérieur à l’entreprise 20 Quelles sont les parties prenantes ? Qui ? Assurance Qualité (QA) Produit • Interne ou externe • Product Manager ou Product Owner La stratégie de test doit être adaptée à la composition et séniorité de l’équipe
21. On construit notre document de travail 21 Dev QA Product Manager On commence par lister nos parties prenantes
22. Mais concrètement, que va-t-elle tester ? On connaît l’équipe qui va intervenir 22
23. 23 On liste les choix et contraintes du projet Stack technique • Symfony • DDD avec architecture Hexagonale Vision projet • Long terme • Politique “Zéro bug” Contraintes • Politique de test • Le produit veut être en capacité de lire les tests d’acceptation Contexte d’équipe • Ne maîtrise pas le TDD Quoi ?
24. On définit ce qu’on souhaite tester 24 Quoi ? Contrat d’interface • L’affichage respecte les maquettes • L’API retourne les bons codes HTTP et le bon contenu • Le contenu est bien sécurisé Technique • Mes classes PHP sont testées • Mon application dialogue correctement avec l’extérieur • Mon code respecte mon architecture logicielle et conventions de codage C’est un choix qui va varier selon les exigences et la typologie du projet Opérationnel • Les critères d'acceptation sont respectés • L’utilisateur peut réaliser les actions souhaitées On liste et catégorise nos exigences
25. 25 On peut affiner notre besoin en itérant Mes classes PHP sont testées Les agrégats et leurs actions sont testés Les services / composants sont testés Les Controllers sont testés Mon application dialogue correctement avec l’extérieur Mes repositories persistent / hydratent bien les agrégats en Database Les clients HTTP fonctionnent et retournent la bonne donnée …
26. Notre document de travail évolue 26 Dev Les fonctionnalités sont utilisables QA Tests “critiques” à automatiser Cahier de recette à maintenir et jouer Product Manager Teste chaque fonctionnalité finalisée Dev Tests comportementaux en Gherkin (intégration) Tests “techniques” (unitaires) Les actions de mon agrégat fonctionnent comme attendus Les critères d’acceptation sont respectés Mes classes PHP sont testés L’utilisateur peut réaliser les actions souhaités On ajoute les objectifs et les actions associées Contrainte respectée : Le produit veut pouvoir les lire Par Via
27. Mais comment met-on en place ces tests ? On connaît maintenant ce qu’il faut tester, et qui va le tester 27
28. Quelle(s) librairie(s) utiliser ? Utiliser une librairie • qui correspond à votre besoin • maintenue • avec une communauté active Unit Contract Component Intégration End-to-end PHPUnit PHPSpec Pest Behat Cypress K6 Panther Symfony Crawler 28 Comment ? Le framework que vous utilisez vous proposera une méthodologie et librairie de test
29. Notre document de travail évolue 29 On ajoute les librairies choisies sur chaque action Dev Les fonctionnalités sont utilisables QA Tests “critiques” à automatiser Cahier de recette à maintenir et jouer Product Manager Teste chaque fonctionnalité finalisée Dev Tests comportementaux en Gherkin (intégration) Cypress Env. “Recette” Behat PHPSpec Tests “techniques” (unitaires) Les actions de mon agrégat fonctionnent comme attendus PHPUnit Les critères d’acceptation sont respectés Mes classes PHP sont testés L’utilisateur peut réaliser les actions souhaités Env. “Recette” Via Par
30. Mais quand allons-nous pouvoir mettre en place ces tests ? On connaît maintenant les actions à réaliser, par qui, et avec quelle librairie 30
31. Quand écrire ses tests ? Ca dépend : • Projet agile / cycle en V • Projet en construction / production • TDD • … 👮 Restez cohérent et pensez “tests” le plus tôt possible Quelques exemples : • Ecrire les tests techniques durant le développement • Ecrire les e2e dès que la fonctionnalité est mergée • Faire des tests de performances dès qu’une fonctionnalité majeure est mergée 31 Quand ? Release Vérification / QA Implémentation Cadrage Cycle de vie d’une fonctionnalité
32. Quand exécuter ses tests ? Il faut exécuter les tests automatisés le plus souvent possible Une bonne stratégie de test sera optimisée et permettra 32 Quand ? Exécution de 1086 tests unitaires sur CI (0,5 secondes) Exécution de 466 tests de Contrats + Composants + Intégration sur CI (9,5 secondes) Par exemple : À chaque commit Lancement des tests Unitaires + Composants + Contrats + Intégrations À chaque déploiement en recette Lancement des tests fonctionnels / end-to-end Recette manuelle par une personne de l’équipe À chaque changement impactant Lancement de tests de performances
33. Notre document de travail évolue 33 On ajoute le moment où chaque action doit avoir lieu Dev Les fonctionnalités sont utilisables QA Tests “critiques” à automatiser Cahier de recette à maintenir et jouer Product Manager Teste chaque fonctionnalité finalisée Dev Tests comportementaux en Gherkin (intégration) Cypress Env. “Recette” Behat PHPSpec Avant chaque déploiement À chaque déploiement “Recette” Tests “techniques” (unitaires) Les actions de mon agrégat fonctionnent comme attendus À chaque fin de dev. d’une fonctionnalité À chaque pipeline de CI PHPUnit À chaque pipeline de CI Les critères d’acceptation sont respectés Mes classes PHP sont testés L’utilisateur peut réaliser les actions souhaités Env. “Recette” Via Par
34. Où allons-nous écrire ces tests ? Il ne nous reste plus qu’une étape … 34
35. Vous pouvez prévoir une convention de placement et nommage sur de gros projets Définir une convention de placement / nommage Où ? On choisit une convention de placement 35 Et une convention de nommage des tests • Avec le code source ou un dépôt externe ? • Sous quel arborescence ? On ne cherche plus ses tests, on met fin à la duplication et incompréhension des scénarios
36. Notre document de travail évolue 36 On ajoute la destination de chaque test Dev Les fonctionnalités sont utilisables QA Tests “critiques” à automatiser Cahier de recette à maintenir et jouer Product Manager Teste chaque fonctionnalité finalisée Dev Tests comportementaux en Gherkin (intégration) Cypress Env. “Recette” Behat PHPSpec Avant chaque déploiement À chaque déploiement “Recette” Tests “techniques” (unitaires) Les actions de mon agrégat fonctionnent comme attendus À chaque fin de dev. d’une fonctionnalité À chaque pipeline de CI PHPUnit À chaque pipeline de CI Dossier tests/Unit/ Projet externe : app-test Dossier tests/Behat Google Sheet Les critères d’acceptation sont respectés Mes classes PHP sont testés L’utilisateur peut réaliser les actions souhaités Env. “Recette” Via Par
37. C’est construit à plusieurs, de manière itérative, qui doit/va vivre On teste quoi ? Qui va tester ? Comment les tests seront rédigés ? Quand seront-ils écrits et joués ? Où pourrais-je les retrouver ? 37 En résumé … Réalisez une note de travail pour réfléchir vos idées et ne pas en oublier
38. Comment partager cette stratégie de tests ? 38
39. On documente sa stratégie de test Exemple d’une stratégie / plan de test mis en place sur une application Yousign 39 On part de son document de travail, on s’assure que tous les objectifs y sont remplis puis on met en forme sa stratégie de test • Les objectifs • Les responsabilités • Les tâches principales • Les pratiques • Les critères d’entrées et de sortie • Les risques N’hésitez pas à lister toute information utile : • Liens vers les autres ressources (politique de test, cahier de recette, …) • Assurance qualité du projet • …
40. On documente sa stratégie de test 40 Scope & attendu On illustre On donne un exemple
41. 41 En conclusion Se réfléchit collégialement pour bénéficier d’une couverture complète, continue et inspirer confiance Quoi ? Qui ? Comment ? Quand ? Où ? Réflexion Doit être documentée pour être claire, partagée et utilisée à chaque moment de doute Documentation Selon l’évolution de l’équipe, de la vision projet ou des faiblesses de la stratégie, elle peut être adaptée Évolutivité
42. 42 Pour aller plus loin … • Respect des bonnes pratiques d’écriture de tests • Avoir des tickets / user stories bien qualifiés et détaillés • Avoir un code bien découpé • Avoir des outils de code quality (phpstan, deptrac, …) Expérimentez ! Une stratégie de test peut être aidée par un processus qualité global du projet
43. Et si vous commenciez vos revues de code en lisant les tests ? 43
44. 44 Merci de votre attention ! Avez-vous des questions ? Un feedback sur la conférence ? 😉 DonovanBourlard