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.

1. Stratégie de Test
La faire bien pour en faire moins
1

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. 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. 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. 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. 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. 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. 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. 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. • 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. 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. 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. 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. 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. 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. Cartographie des risquesProbabilité
Impact
Sansimpact
Improbable
Haut risque
Dan North, in Testing Faster workshop20

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. 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. 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. Efficience
Temps, Ressources, Capacité
• …
• Tests de performances/charge
• Monitoring système et applicatif
• Demos
• Oui, des rapports de tirs de
Performance, etc.
24

23. Compatibilité
Coexistence (i.e. : avec du legacy),
Interopérabilité
• Consumer Driven Contracts
• Approval Testing
• Double Run / Suivi de Production
• Demos
25

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. 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. 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. 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. 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. 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. Les tests prescriptifs se sont adaptés
M
O
S
C
O
W
32

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. « Une » architecture testable
WS
Impl
App
Layer
Repositories
Aggregate
Root
Domain
Object
Domain
Object
Shared
Utility
Shared Model
34

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. 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. 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. 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. 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. 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. 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. « should_return_empty_when_friend_has_no_trips »
Is valuable as a documentation ?
42

41. 43

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. 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. Test FIRST en équipe
BDD : Behaviour Driven Development
• Spécifications exécutables
-- Alberto Brandolini46