Grâce aux tests par mots-clés « keyword-driven testing », les équipes Agiles peuvent maintenant automatiser leurs tests à chaque sprint avant même que le développement des fonctions soit complété, sans avoir besoin de connaissances techniques. Implémentez des stratégies de tests automatisés en utilisant les mots-clés et augmentez la productivité de l'équipe sans devoir en changer sa composition. Jean-Yves Allard

1. Les tests automatisés par mots-clés,
le complément parfait d’un projet Agile
Jean-Yves Allard, ing.
Agile Tour Montréal 2018

2. Agenda
• Introduction
• Mise en contexte
• Le BDD et les tests en pratique
• Les mots-clés en test
• Quelques exemples avec des outils
• À retenir
• Questions

3. Qui suis-je ?
Ingénieur informatique de formation
Plus de 32 ans d’expérience professionnelle
De l’embarqué aux systèmes distribués
De l’assembleur au python, Java et .Net
Du Waterfall à l’Agile/BDD, en passant par JAD/RAD et XP

4. Le contexte

5. Pourquoi tester et automatiser ?
• Ça coûte trop cher
• On n’a pas le temps
• C’est impossible de tout tester
• On est Agile!
• Les QAs font le faire
• On va manquer notre fenêtre de livraison

6. X Exigences mal comprises
X Produit mal adapté
X Usagers experts pas consultés
X Pas de projet pilote
X Peu ou pas de tests
X Pas de plan de retour en arrière
Source : Rapport du comité du Sénat
https://sencanada.ca/content/sen/committee/421/NFFN/reports/NFFN_Ph%C3%A9nix_rapport32_WEB_f.pdf
Le Phœnix ne renaîtra pas de ses cendres !

7. • Les tests et l’automatisation en vase clos auraient probablement
un peu aidé, mais le résultat final serait le même.
• À la base, les tests doivent faire l’objet d’une stratégie qui, elle-
même, doit faire partie intégrale du processus de
développement. Agile ou pas.
• La communication et les échanges en continue entre les parties
prenantes sont impératifs.
• Le développement logiciel est avant tout, encore pour l’instant,
une activité humaine, socialement très complexe.
• Chacun amène son lot d’idées et de préjugés à la table d’un
projet; chacun a sa propre perception et sa propre motivation.
• Même si on se dit Agile, les gens ont tendance à « sérialiser » les
activités selon leur rôle (récits-dev-test-QA-UAT-livraison).
Cette vision n’a pas changé depuis plus de 30 ans !
Les tests auraient-ils tout changé ?

8. 1. Le processus de développement, de la création à l’opération,
doit favoriser la communication et les échanges en continu
entre les parties prenantes.
2. Il faut se doter d’un langage commun entre les usagers,
l’équipe de développement, la gestion et l’opération.
3. Les tests et l’automatisation encadrés par une stratégie et
intégrés au départ donnent des logiciels de qualité.
4. L’assurance qualité ce n’est pas le contrôle de la qualité. Elle
inhérente à l’objectif du processus de développement.
• Il faut se doter d’une manière de penser, soutenue de
méthodes et d’outils adaptés.
• Il faut rester Agile, dans tous les sens du terme !
À éviter: Version plus colorée, plus complexe,
mais essentiellement la même !
Que faire alors ?

9. Les principes et méthodes Agile forment le fondement.
 ATTENTION: l’agilité ce n’est pas du mini Waterfall!
On y adjoint une stratégie d’assurance qualité intégrée.
On adopte les principes du BDD, pour le code applicatif et les tests.
On élabore un catalogue de produits en utilisant par exemple le « Feature Mapping »,
ensemble avec le PO/AA, les développeurs et les analystes, scripteurs, testeurs en
assurance-qualité.
On adopte un langage commun pour décrire les fonctionnalités du catalogue de produit.
 Au début du projet, c’est un roadmap plus au moins détaillé
 qui sera raffiné au fil des sprints.
1. Le processus de développement

10. Précis et succinct
Indépendant des outils et langages de programmation
 Tests unitaires = spécification du comportement d’une classe
 Tests fonctionnels = spécification du comportement d’une fonction d’affaires
Refactoring et mocking
 On ne comprend pas tout au départ
 « Diviser pour régner »
Les mots-clés constituent votre vocabulaire commun
 Indépendants de l’implantation
 Résistants aux changements
2. Un langage et une méthode communs

11. Elle considère le processus de bout en bout, autant pour le logiciel développé
que des rôles et responsabilités de chacun, et des outils et méthodes choisies
pour le projet.
Les plans de tests sont découpés en fonction de leur valeur tout au long du
développement, de la mise en production et même pour l’opération.
L’équipe définit le partitionnement des tests entre les tests unitaires et les
fonctionnels, pour optimiser la couverture et l’impact.
Les tests utilisent le mêmes cas d’usage en les bonifiant avec des scénarios
particuliers au besoin, par exemple pour les tests de performance.
3. Une stratégie d’assurance qualité intégrale

12. En pratique

13. C’est quoi le BDD ?
Behaviour Driven Development, basé sur l’approche Test Driven Development
• Emphase sur la coopération engagée entre les clients/usagers, les développeurs, les testeurs et toute autre partie
prenante.
• Ensemble, les fonctionnalités créées doivent contribuer à ajouter de la valeur. Tout le reste est inutile et constitue
du gaspillage (Lean anyone ?).
• Spécification des comportements attendus par exemples concrets. Ultimement automatisable.
• On doit s’attendre à ce que notre compréhension des exigences ou fonctionnalités évolue au cours du projet.
• Comme toute méthode, la qualité et la précision des récits et scénarios sont nécessaires à la valeur espérée.
• Attention aux abus lorsque l’exercice devient une fin en soit. Comme pour l’agilité en général, il faut à tout prix
éviter les dogmes.

14. 2018-11-16 14
Récit utile (pas vraiment)
• En tant qu’usager
• Je veux faire une action
• Dans le but d’obtenir un bénéfice
Scénario 1
• Étant donné ce contexte
• Lorsque je fais cette action
• Alors je m’attends à ce résultat
Scénario 2
• Étant donné cet autre contexte
• Lorsque je fais cette autre action
• Alors je m’attends à cet autre résultat
DÉVELOPPER LA CONFIANCE
À retenir :
Une bonne technique pour
arriver à des récits concrets, de
qualité et réalisables :
« Feature Mapping » ou
« Example Mapping »
5 « Whys »
Récits usagers (ou fonctionnalités) en BDD

15. 2018-11-16 15
Fonctionnalité : Gérer les propriétaires
En tant que Commis de clinique, dans le but de gérer les informations des propriétaires d’animaux qui sont clients de la
clinique, je veux pouvoir :
• Scénario 1 : consulter le répertoire des clients
• Scénario 2 : chercher un propriétaire en particulier
• Scénario 3 : ajouter un propriétaire s’il n’existe pas
o Étant donné que la page Rechercher Propriétaire est affichée
o Lorsque j’active la fonction Ajouter Propriétaire
o Et que j’entre les informations du propriétaire sans fautes
o Et j’active la fonction Ajouter
o Alors le propriétaire existe
• Scénario 4: modifier les informations du propriétaire s’il existe.
DÉVELOPPER LA CONFIANCE
Ensemble, il faut se
poser des questions
pour clarifier
Et avec un récit plus utile en BDD

16. • Propriétaire existe ou non
o Si le propriétaire recherché n’existe pas, que fait
l’application? Affiche un message? Si oui lequel?
Sinon quoi?
• Client
o Est-ce qu’un client est obligatoirement un
propriétaire d’animaux?
o Est-ce qu’un client est usager de l’application?
• Informations d’un propriétaire
o Nom, prénom, adresse (rue, ville, province, code
postal)?
o Actif? Usager de l’application?
o Infos financières?
o Nous définissons que l’application affiche un message
indiquant le propriétaire n’existe pas. Il faudra ajouter ce
comportement à notre récit.
o Oui
o Non
o Nous définissons: Nom, prénom et adresse
o Non nécessaire
o Non nécessaires
Posons-nous ensemble des questions pour clarifier

17. • Sans fautes
o Règles de bas niveau, quelles sont-elles?
o Validation à l’écran en direct ou par le back-end ?
• Commis de clinique
o Considérant ce qui est plus haut, droits de
voir/manipuler les infos financières?
• Sauvegarde, recherche et chargement
o Que fait l’application si il n’est passible de rejoindre le
back-end ?
o Aucune
o Aucune
o Sans objet
o Il faudra ajouter un comportement au récit à l’effet
que l’application indiquera le problème mais ne
pètera pas.
Posons-nous ensemble des questions pour clarifier

18. Les mots-clés sont des actions programmées dont le nom évoque clairement la fonction.
Ils permettent de séparer la programmation des scripts de test de la documentation du cas de test
• Les analystes peuvent se concentrer sur la fonctionnalité et le comportement attendu de l’application à tester.
• Les programmeurs de scripts se concentrent sur l’implantation des cas de tests documentés.
• Mais, entre eux et avec les usagers, ils partagent une compréhension unique des attentes.
Ils améliorent la robustesse face aux changements techniques et aux détails sous-jacents.
Ils facilitent la maintenance des fonctions de tests et permettent de les réutiliser.
Ils sont composables.
Ils deviennent des spécifications exécutables.
On passe aux tests avec des Mots-Clés

19. Tests avec Mots-Clés en BDD
Scénario 3 : Gérer les propriétaires, Je veux ajouter un propriétaire s’il n’existe pas
Étant donné que La page Rechercher Propriétaire est affichée
Open Browser URL
Wait Until Page Contains Element locator_page_open
Activate Element locator_menu_owner
Wait Until Element Is Visible locator_add_button
Et que Le Propriétaire n’existe pas
Query query_check_owner_not_exist nom_du_proprio
Should Be Empty query_result
Lorsque J’active la fonction Ajouter Propriétaire
Activate Element locator_add_owner
On commence avec les mots-clés de bas niveau et on compose

20. Tests avec Mots-Clés en BDD
Et que J’entre les informations du Propriétaire
Input Text locator_name nom_du_proprio
Et que J’active la fonction Ajouter Propriétaire
Activate Element locator_add_owner
Alors Le Propriétaire existe
Query query_check_owner_exists nom_du_proprio
Should Not Be Empty query_result

21. Notre scénario 3 dans une plateforme

22. Composition de mots-clés
Mots-clés de base ou combinés
La complexité
poussée au
dernier niveau
Le langage
simple,
commun à
tous
Une spécification exécutable, sans coder !

23. À retenir
• Le développement Agile de qualité, c’est possible et payant!
• Un langage commun précis et succinct
• Des outils adaptés à soutenir le processus
• Travaillez ensemble, fini les silos!
• Communiquez!
Askida CT
Concordion
Cucumber/Gherkin
Jbehave
Robot Framework
SpecFlow

24. Merci !
Essayez Askida CTMC
https://askidact.com
Renseignez-vous au sujet de nos ateliers
info@askida.com

25. Références
• Livres
o Chelimsky, David, The Rspec Book, The Pragmatic Bookshelf, 2010
o Greever, Tom, Articulating Design Decisions, O’Reilly, 2015
o Kalbach, Jim, Mapping Experiences, O’Reilly, 2016
o Patton, Jeff, User Story Mapping, O’Reilley, 2014
o Smart, John Ferguson, BDD in Action, Manning, 2015
o Wynne, Matt, Hellsoy, Aslak, The Cucumber Book, The Pragmatic Bookshelf, 2012
• Articles et présentations
o Allard, Jean-Yves, Ateliers Tests en BDD avec Askida CT, Groupe Askida, Montréal et Toronto, 2018
o Anderson, Kenneth M., BDD and Cucumber, University of Colorado, Computer Science Lectures, 2012
o Smart, John Ferguson, BDD at the Heart of any DevOps Transformation Story, 2017
o Versaci, Damian, Agile BDD and Integrated Testing with Cucumber, Melbourne ANTZTB SIGIST, 2011