Boîte à Outils - Consultant en QA Agile

WeFiiT Conseil Product & Quality Management
WeFiiT Conseil Product & Quality ManagementDo the right product and do it right. à WeFiiT
© WeFiiT
1
Do the right product


and do it right !
La boite à outils


de la QA Agile
Des outils pour vous permettre


d’assurer la qualité de votre produit
© WeFiiT
© WeFiiT
Le Toolkit des acteurs de la qualité


produit numérique
WeFiiT vous propose plusieurs outils à glisser dans
votre mallette de la QA Agile :


• Le Behavior-Driven Development (BDD)


• La Cérémonie des Trois Amigos


• La place du QA au sein des US


• La lecture de la User Story


• Rédiger les critères d’acceptation


• Rédiger un cas de test
© WeFiiT
Le Behavior-Driven Development
Qu’est-ce que l’approche BDD (Behavior-Driven
Development) ?


Le Behavior-Driven Development, ou BDD, est une méthode
de développement Agile dans laquelle le produit est
conçu autour du comportement qu’un utilisateur s’attend à
expérimenter.


Le principe du BDD est donc de préciser un « comportement
désiré ». Cela sera matérialisé par des critères d’acceptation
qui seront déclinés en scénario de test et qui serviront de
référence au développement du code.


Le BDD est une méthode de développement dérivée
du Test-Driven Development, ou TDD, qui a émergé
pour répondre aux di
ffi
cultés rencontrées par cette
dernière :


• L’interprétation de l’expression du besoin suite à
l’utilisation d’un langage technique, non commun
à l’ensemble des intervenants du projet (métier,
PO, QA et développeur)


• L’imprécision sur le périmètre de test entre ce qui
doit être ou ne pas être testé car celui-ci se base
sur la véri
fi
cation de codes unitaires successifs et
non d’un comportement attendu d’un utilisateur
Quels sont les avantages de l’approche BDD (Behavior-
Driven Development) ?


• Une meilleure communication entre les intervenants


• Un développement guidé par le comportement utilisateur


• Un développement auto-documenté
© WeFiiT
Pour aller plus loin sur le blog de WeFiiT:


• Réussir son intégration d’une approche Behavior-
Driven Development (BDD)
Les étapes du Behavior-Driven Development
© WeFiiT
La Cérémonie des 3 Amigos
La cérémonie des 3 Amigos rassemble trois acteurs
travaillant sur un produit a
fi
n de bien dé
fi
nir les besoins et les
spéci
fi
cations de ses fonctionnalités.


Les 3 Amigos, c’est :


• Un Product Owner (ou Business Analyst), un développeur
et un QA agile qui se regroupent pour af
fi
ner et valider des
User Stories


• Une meilleure compréhension des comportements
attendus par l’ensemble des Amigos


• Une validation du périmètre de test par l’écriture des
critères d’acceptation et des scénarios de test


• Des développements de meilleure qualité grâce à la
réduction des risques d’interprétation


• Un rituel agile à réaliser de préférence avant celui du
Backlog re
fi
nement
La Cérémonie a plusieurs objectifs :


• Clari
fi
er les enjeux et les attentes de l’utilisateur


• Af
fi
ner et challenger les User Stories


• Ecrire les critères d’acceptation


• Anticiper le Backlog re
fi
nement / Grooming
Que fait-on lors de cette cérémonie Agile ?


• Le Product Owner va présenter le besoin, décrire l’attente
utilisateur, pointer les impacts business et lister les règles
métiers.


• Le développeur va identi
fi
er les briques de code impactées,
soulever les problèmes techniques et orienter ainsi les tests de
non régression (TNR).


• Le QA Agile va identi
fi
er les jeux de données nécessaires,
soulever les problèmes fonctionnels et anticiper sa stratégie de
test en proposant des scénarios de test qui valideront les
critères d’acceptation décidés en séance.


Pour aller plus loin sur le blog de WeFiiT:


• Tout savoir sur les 3 Amigos de l’Agilité !
© WeFiiT
La place du QA au sein des User Story
Une User Story vie, s’enrichie et évolue à travers
différentes étapes :


1. Identifier le besoin utilisateur


2. Déterminer clairement la valeur ajoutée apportée au
produit


3. Déterminer les critères qui valideront pour
l’utilisateur la valeur ajoutée (Definition Of Done)*


4. Rédiger de manière détaillée les étapes nécessaires
à la validation de ces critères (Cahier de test)


5. L’amélioration continue par la relecture par des
pairs ou l’expérience acquise lors de l’exécution


*,La Definition of Done (DOD) est l’ensemble de critères définis
par l’équipe Projet déterminant si une User Story peut être considérée
comme traitée.
Cette répartition des rôles permet de :


• Rendre clair et accessible pour tous les tests
exécutés


• Partager les risques avec l’ensemble de l’équipe
projet


• Répartir les forces de chacun aux étapes clés


• Gagner du temps en priorisant les tests dès la
conception


• Faciliter l’amélioration continue
Pour être le plus clair possible :


• Eviter les jargons internes incompréhensibles de
tous


• Préciser ce qui est hors périmètre également


• Partager et valider chaque étape par l’ensemble de
l’équipe
© WeFiiT
Pour aller plus loin sur le blog de WeFiiT:


• Les bonnes pratiques de l’organisation QA Agile


• La « definition of done », un impératif de la qualité
du produit  
PO QA
2. Description de
la User Story
(valeur ajoutée)
4. Rédaction des
cas de test
1. Identification du
besoin utilisateur
3. Définition des critères
d’acceptation


(DOD)
5. Feedback
relecture /
exécution des tests
Les rôles au sein du cycle de vie d’une User Story
© WeFiiT
La lecture de la User Story
La description de la User Story :


• Indique clairement la valeur ajoutée pour l’utilisateur


• Doit être claire et précise


• Doit correspondre à une tâche simple


• Est écrite via le langage Gherkin (Given/When/Then)


• Est validée par l’ensemble de l’équipe projet (PO/QA/Dév)


• Est testable et validée par un ou des critères d’acceptation
Inclure les critères d’acceptation dans la User Story durant les
échanges techniques avec toute l’équipe permet de :


• Lister tous les scénarios à prendre en compte,


• Exclure du périmètre les scénarios non pertinent.


Ils permettent de mettre tout le monde d’accord sur la manière
dont va être vérifiée l’implémentation de l’US : « Comment je
vérifie que j’ai obtenu ce que je voulais ».
Utiliser la méthode SMART pour l’écriture de ces
critères d’acceptation :


• Specific  : compréhensible, facile à reproduire


• Measurable : quantifiable et observable


• Achievable : possible à réaliser (sans
complexité excessive)


• Relevant :  approprié à la user story en
question


• Time Bound  : circonscrit dans le temps
© WeFiiT
La lecture de la User Story
Description de la
valeur ajoutée de la
User Story écrit en
Gherkin
Critère
d’acceptation de la
User Story
Titre de la


User Story
Titre du critère
d’acceptation


(= scénario de test)
Pour aller plus loin :


• Sur le blog WeFiiT : Rédiger des User Stories de qualité en 3 étapes


• Les critères d’acceptation
© WeFiiT
Rédiger les critères d’acceptation
Rédigez des critères d’acceptation intuitifs et
cohérents :


• Le scénario reflète-t-il bien le parcours utilisateur ?


• Les critères d’acceptation valident bien le
périmètre des tests


• Incorporez les données de test dans le scenario


• Privilégiez des steps clairs et concis pour ne pas
les surcharger et générer des interprétations
Les critères d’acceptation :


• Déterminent la définition of done QA d’une US


• Doivent être compréhensibles par tous


• Sont résumés par un titre clair (scénario du test)


• Sont écrits via le langage Gherkin (Given/When/Then)


• Reflètent tous les parcours utilisateurs/règles métiers


• Sont rédigés par le QA


• Contiennent les jeux de données nécessaires à l’exécution


• Sont validés par l’ensemble de l’équipe projet
La standardisation de l’écriture des critères
d’acceptation permet à tous :


• D’éviter les interprétations


• S’assurer rapidement de la qualité et la couverture
des tests


• L’exécution du cas de test par n’importe quel acteur
du projet


• Faciliter l’automatisation des tests
© WeFiiT
Rédiger les critères d’acceptation
Scénarios de test écrit
en Gherkin
Jeux de données
utilisés dans les
scénarios de test
Règles métiers à
couvrir pour valider la
User Story
Pour aller plus loin :


• Écrire les critères
d'acceptation avec Gherkin


• Les tests d’acceptance : un
pilier de l’agilité
PO QA
© WeFiiT
Rédiger un cas de test
• Éviter les répétitions, préférer les appels de cas de test


• Ajouter des pièces jointes (screenshots, …) si
nécessaire


• Pas plus de 15 steps par cas de test
Le cas de test détaille pas à pas les étapes à
suivre pour valider la valeur ajoutée du critère
d’acceptation.


La rédaction des cas de test ne se fait pas dans la
User Story.


Pour cela, on utilise la section « Test Plan » d’un
logiciel spécialisé (ALM/QC, Squash TM, Xray,
Azure DevOps…) ou un fichier Excel par défaut.


La somme de tous ces cas de test joués lors d’une
phase de tests (Sprint) formera le cahier de tests.
Un cas de test doit :


• être rédigé de manière simple et transparent :


• être facilement identifiable


• être réfléchi en se mettant à la place de l’utilisateur


• être rédigé à partir des critères d’acceptation


• revu par un pair (Peer review)


• être répétable et maintenable


• assurer 100% de couverture
© WeFiiT
Rédiger un cas de test
Pour aller plus loin :


• Créer des cas de test efficaces en 4 étapes
© WeFiiT
“Talent wins games, but teamwork and
intelligence win championships”


Michael Jordan
Site & Blog wefiit.com
Nos articles
Société de conseil


spécialisée dans le Product & Quality
Management
LinkedIn
Quelques exemples :


• Prioriser sa roadmap : Le framework
LUV-Me de Prestashop


• La place de la QA dans l’agilité
Notre veille
1 sur 14

Contenu connexe

En vedette(20)

ChatGPT webinar slidesChatGPT webinar slides
ChatGPT webinar slides
Alireza Esmikhani30.2K vues
More than Just Lines on a Map: Best Practices for U.S Bike RoutesMore than Just Lines on a Map: Best Practices for U.S Bike Routes
More than Just Lines on a Map: Best Practices for U.S Bike Routes
Project for Public Spaces & National Center for Biking and Walking6.9K vues
Barbie - Brand Strategy PresentationBarbie - Brand Strategy Presentation
Barbie - Brand Strategy Presentation
Erica Santiago25.1K vues
9 Tips for a Work-free Vacation9 Tips for a Work-free Vacation
9 Tips for a Work-free Vacation
Weekdone.com7.1K vues
I Rock Therefore I Am. 20 Legendary Quotes from PrinceI Rock Therefore I Am. 20 Legendary Quotes from Prince
I Rock Therefore I Am. 20 Legendary Quotes from Prince
Empowered Presentations142.8K vues
How to Map Your FutureHow to Map Your Future
How to Map Your Future
SlideShop.com275.1K vues
Read with Pride | LGBTQ+ ReadsRead with Pride | LGBTQ+ Reads
Read with Pride | LGBTQ+ Reads
Kayla Martin-Gant1.1K vues
The Student's Guide to LinkedInThe Student's Guide to LinkedIn
The Student's Guide to LinkedIn
LinkedIn87.8K vues

Boîte à Outils - Consultant en QA Agile

  • 1. © WeFiiT 1 Do the right product and do it right ! La boite à outils de la QA Agile Des outils pour vous permettre d’assurer la qualité de votre produit © WeFiiT
  • 2. © WeFiiT Le Toolkit des acteurs de la qualité produit numérique WeFiiT vous propose plusieurs outils à glisser dans votre mallette de la QA Agile : • Le Behavior-Driven Development (BDD) • La Cérémonie des Trois Amigos • La place du QA au sein des US • La lecture de la User Story • Rédiger les critères d’acceptation • Rédiger un cas de test
  • 3. © WeFiiT Le Behavior-Driven Development Qu’est-ce que l’approche BDD (Behavior-Driven Development) ? Le Behavior-Driven Development, ou BDD, est une méthode de développement Agile dans laquelle le produit est conçu autour du comportement qu’un utilisateur s’attend à expérimenter. Le principe du BDD est donc de préciser un « comportement désiré ». Cela sera matérialisé par des critères d’acceptation qui seront déclinés en scénario de test et qui serviront de référence au développement du code. Le BDD est une méthode de développement dérivée du Test-Driven Development, ou TDD, qui a émergé pour répondre aux di ffi cultés rencontrées par cette dernière : • L’interprétation de l’expression du besoin suite à l’utilisation d’un langage technique, non commun à l’ensemble des intervenants du projet (métier, PO, QA et développeur) • L’imprécision sur le périmètre de test entre ce qui doit être ou ne pas être testé car celui-ci se base sur la véri fi cation de codes unitaires successifs et non d’un comportement attendu d’un utilisateur Quels sont les avantages de l’approche BDD (Behavior- Driven Development) ? • Une meilleure communication entre les intervenants • Un développement guidé par le comportement utilisateur • Un développement auto-documenté
  • 4. © WeFiiT Pour aller plus loin sur le blog de WeFiiT: • Réussir son intégration d’une approche Behavior- Driven Development (BDD) Les étapes du Behavior-Driven Development
  • 5. © WeFiiT La Cérémonie des 3 Amigos La cérémonie des 3 Amigos rassemble trois acteurs travaillant sur un produit a fi n de bien dé fi nir les besoins et les spéci fi cations de ses fonctionnalités. Les 3 Amigos, c’est : • Un Product Owner (ou Business Analyst), un développeur et un QA agile qui se regroupent pour af fi ner et valider des User Stories • Une meilleure compréhension des comportements attendus par l’ensemble des Amigos • Une validation du périmètre de test par l’écriture des critères d’acceptation et des scénarios de test • Des développements de meilleure qualité grâce à la réduction des risques d’interprétation • Un rituel agile à réaliser de préférence avant celui du Backlog re fi nement La Cérémonie a plusieurs objectifs : • Clari fi er les enjeux et les attentes de l’utilisateur • Af fi ner et challenger les User Stories • Ecrire les critères d’acceptation • Anticiper le Backlog re fi nement / Grooming Que fait-on lors de cette cérémonie Agile ? • Le Product Owner va présenter le besoin, décrire l’attente utilisateur, pointer les impacts business et lister les règles métiers. • Le développeur va identi fi er les briques de code impactées, soulever les problèmes techniques et orienter ainsi les tests de non régression (TNR). • Le QA Agile va identi fi er les jeux de données nécessaires, soulever les problèmes fonctionnels et anticiper sa stratégie de test en proposant des scénarios de test qui valideront les critères d’acceptation décidés en séance. Pour aller plus loin sur le blog de WeFiiT: • Tout savoir sur les 3 Amigos de l’Agilité !
  • 6. © WeFiiT La place du QA au sein des User Story Une User Story vie, s’enrichie et évolue à travers différentes étapes : 1. Identifier le besoin utilisateur 2. Déterminer clairement la valeur ajoutée apportée au produit 3. Déterminer les critères qui valideront pour l’utilisateur la valeur ajoutée (Definition Of Done)* 4. Rédiger de manière détaillée les étapes nécessaires à la validation de ces critères (Cahier de test) 5. L’amélioration continue par la relecture par des pairs ou l’expérience acquise lors de l’exécution *,La Definition of Done (DOD) est l’ensemble de critères définis par l’équipe Projet déterminant si une User Story peut être considérée comme traitée. Cette répartition des rôles permet de : • Rendre clair et accessible pour tous les tests exécutés • Partager les risques avec l’ensemble de l’équipe projet • Répartir les forces de chacun aux étapes clés • Gagner du temps en priorisant les tests dès la conception • Faciliter l’amélioration continue Pour être le plus clair possible : • Eviter les jargons internes incompréhensibles de tous • Préciser ce qui est hors périmètre également • Partager et valider chaque étape par l’ensemble de l’équipe
  • 7. © WeFiiT Pour aller plus loin sur le blog de WeFiiT: • Les bonnes pratiques de l’organisation QA Agile • La « definition of done », un impératif de la qualité du produit   PO QA 2. Description de la User Story (valeur ajoutée) 4. Rédaction des cas de test 1. Identification du besoin utilisateur 3. Définition des critères d’acceptation 
 (DOD) 5. Feedback relecture / exécution des tests Les rôles au sein du cycle de vie d’une User Story
  • 8. © WeFiiT La lecture de la User Story La description de la User Story : • Indique clairement la valeur ajoutée pour l’utilisateur • Doit être claire et précise • Doit correspondre à une tâche simple • Est écrite via le langage Gherkin (Given/When/Then) • Est validée par l’ensemble de l’équipe projet (PO/QA/Dév) • Est testable et validée par un ou des critères d’acceptation Inclure les critères d’acceptation dans la User Story durant les échanges techniques avec toute l’équipe permet de : • Lister tous les scénarios à prendre en compte, • Exclure du périmètre les scénarios non pertinent. Ils permettent de mettre tout le monde d’accord sur la manière dont va être vérifiée l’implémentation de l’US : « Comment je vérifie que j’ai obtenu ce que je voulais ». Utiliser la méthode SMART pour l’écriture de ces critères d’acceptation : • Specific  : compréhensible, facile à reproduire • Measurable : quantifiable et observable • Achievable : possible à réaliser (sans complexité excessive) • Relevant :  approprié à la user story en question • Time Bound  : circonscrit dans le temps
  • 9. © WeFiiT La lecture de la User Story Description de la valeur ajoutée de la User Story écrit en Gherkin Critère d’acceptation de la User Story Titre de la User Story Titre du critère d’acceptation (= scénario de test) Pour aller plus loin : • Sur le blog WeFiiT : Rédiger des User Stories de qualité en 3 étapes • Les critères d’acceptation
  • 10. © WeFiiT Rédiger les critères d’acceptation Rédigez des critères d’acceptation intuitifs et cohérents : • Le scénario reflète-t-il bien le parcours utilisateur ? • Les critères d’acceptation valident bien le périmètre des tests • Incorporez les données de test dans le scenario • Privilégiez des steps clairs et concis pour ne pas les surcharger et générer des interprétations Les critères d’acceptation : • Déterminent la définition of done QA d’une US • Doivent être compréhensibles par tous • Sont résumés par un titre clair (scénario du test) • Sont écrits via le langage Gherkin (Given/When/Then) • Reflètent tous les parcours utilisateurs/règles métiers • Sont rédigés par le QA • Contiennent les jeux de données nécessaires à l’exécution • Sont validés par l’ensemble de l’équipe projet La standardisation de l’écriture des critères d’acceptation permet à tous : • D’éviter les interprétations • S’assurer rapidement de la qualité et la couverture des tests • L’exécution du cas de test par n’importe quel acteur du projet • Faciliter l’automatisation des tests
  • 11. © WeFiiT Rédiger les critères d’acceptation Scénarios de test écrit en Gherkin Jeux de données utilisés dans les scénarios de test Règles métiers à couvrir pour valider la User Story Pour aller plus loin : • Écrire les critères d'acceptation avec Gherkin • Les tests d’acceptance : un pilier de l’agilité PO QA
  • 12. © WeFiiT Rédiger un cas de test • Éviter les répétitions, préférer les appels de cas de test • Ajouter des pièces jointes (screenshots, …) si nécessaire • Pas plus de 15 steps par cas de test Le cas de test détaille pas à pas les étapes à suivre pour valider la valeur ajoutée du critère d’acceptation. La rédaction des cas de test ne se fait pas dans la User Story. Pour cela, on utilise la section « Test Plan » d’un logiciel spécialisé (ALM/QC, Squash TM, Xray, Azure DevOps…) ou un fichier Excel par défaut. La somme de tous ces cas de test joués lors d’une phase de tests (Sprint) formera le cahier de tests. Un cas de test doit : • être rédigé de manière simple et transparent : • être facilement identifiable • être réfléchi en se mettant à la place de l’utilisateur • être rédigé à partir des critères d’acceptation • revu par un pair (Peer review) • être répétable et maintenable • assurer 100% de couverture
  • 13. © WeFiiT Rédiger un cas de test Pour aller plus loin : • Créer des cas de test efficaces en 4 étapes
  • 14. © WeFiiT “Talent wins games, but teamwork and intelligence win championships” Michael Jordan Site & Blog wefiit.com Nos articles Société de conseil spécialisée dans le Product & Quality Management LinkedIn Quelques exemples : • Prioriser sa roadmap : Le framework LUV-Me de Prestashop • La place de la QA dans l’agilité Notre veille