ISTQB Testeur Agile Niveau Fondation - Cours V1.03

Support de formation
Version 1.03 Novembre 2019

Sogeti Test Academy
Introduction
© 2019 Sogeti. All rights reserved. 2

Audience Cible
 Testeurs expérimentés dans les cycles de vie du développement logiciel (SDLCs) traditionnels
 Testeurs débutants intéressés par le test agile
 Développeurs expérimentés avec des connaissances de base en matière de tests et travaillant
sur des projets agiles
La certification au Niveau Fondation de l’ISTQB® est un prérequis
Sogeti Test Academy Testeur Agile certifié ISTQB foundation V1.03 © 2019 Sogeti. All rights reserved. 3
Objectifs opérationnels
A l’issue de la formation, les participants sauront :

 Collaborer au sein d'une équipe Agile pluridisciplinaire connaissant les principes et les
pratiques de base du développement logiciel Agile.
 Adapter l'expérience et les connaissances existantes en matière de tests aux valeurs et
principes Agiles.
 Soutenir l'équipe Agile dans la planification des activités liées aux tests.
 Appliquer les méthodes et techniques pertinentes pour tester dans un projet Agile.
 Assister l'équipe Agile dans les activités d'automatisation des tests.
 Aider les intervenants métier à définir des user stories, des scénarios, des exigences et des
critères d'acceptation compréhensibles et testables.
 Travailler et partager l'information avec les autres membres de l'équipe en utilisant des styles
et des canaux de communication efficaces.
Bref, un testeur certifié de niveau Fondation Testeur Agile doit savoir travailler
efficacement au sein d'une équipe et d'un environnement Agile.
Plan du cours
1. Développement logiciel Agile
1.1 Les fondamentaux

1.1.1 Le manifeste Agile
Les Valeurs
Les Individus et leurs interactions
 Le développement Agile est axé sur les individus.

 Au sein des équipes qui construisent des logiciels, communication et interactions
continues entre individus apportent plus d’efficacité que le recours aux outils ou
processus.
Des logiciels opérationnels
 Un logiciel opérationnel est beaucoup plus utile et profitable qu’une documentation très
détaillée et permet de fournir des feedbacks rapides à l'équipe de développement.
 Un logiciel opérationnel, même avec des fonctionnalités réduites, disponible beaucoup
plus tôt peut être un avantage déterminant en termes de time-to-market.
 Le développement en mode Agile est donc particulièrement utile dans les secteurs qui
évoluent très rapidement où les problèmes ne sont pas clairs et/ou les solutions
sont innovantes.
La collaboration avec les clients
 Les clients rencontrent souvent beaucoup de difficultés à exprimer le système dont ils ont
besoin.
 Collaborer directement avec le client améliore les chances de comprendre exactement ce
dont il a besoin.
 Bien qu’avoir des contrats avec les clients puisse être important, travailler en collaboration
étroite et régulière avec eux augmente les chances de succès du projet.
S’adapter au changement
 Les changements sont inévitables dans les projets logiciels.

 Des changements dans l'environnement dans lequel l'entreprise évolue, la législation,
l'activité des concurrents, les progrès technologiques et d'autres facteurs peuvent avoir une
influence majeure sur le projet et ses objectifs.
 Ces facteurs doivent être pris en compte dans le processus de développement.
 Pour cette raisons il est plus important d'avoir la flexibilité nécessaire pour s'adapter au
changement que de se borner à se conformer strictement à un plan.
1.1.1 Le manifeste Agile Les 12 principes sous-jacents
Excellence technique
1.1.2 Approche d’équipe Intégrée
 Impliquer chaque personne qui a les connaissances et les compétences nécessaires

pour assurer la réussite du projet.
 L'équipe comprend des représentants des clients et d'autres intervenants Métier qui
déterminent les caractéristiques du produit souhaitées.
 Equipe relativement petite (de 3 à 9 personnes)
 Idéalement, toute l'équipe partage le même espace de travail, cette co-location facilite
fortement la communication et les interactions.
 Réunions quotidiennes ou Stand-up Meeting (voir chapitre 2.2.1) impliquant tous les
membres de l'équipe, et où le travail en cours est communiqué et les obstacles à la
progression sont mis en évidence.
 L‘approche équipe intégrée facilite une dynamique d’équipe plus efficace et efficiente.
L’approche équipe intégrée est un des principes fondamentaux des développements Agile. Les
bénéfices incluent :
 L’amélioration de la communication et de la collaboration au sein de l'équipe
 L’utilisation des diverses compétences au sein de l'équipe au profit du projet
 La Qualité qui devient de la responsabilité de toute l’équipe
Les testeurs, les développeurs et les représentants Métier travaillent ensemble à chaque
étape du processus de développement pour s'assurer que les niveaux de qualité
souhaités sont atteints. Cela inclut, pour les testeurs :
 de soutenir et collaborer avec les représentants des Métiers pour les aider à créer des
tests d'acceptation pertinents,
 de travailler avec les développeurs pour s'entendre sur la stratégie de test, et s’accorder
sur les approches d'automatisation des tests.
Les testeurs peuvent ainsi transférer et étendre la connaissance du test aux autres membres
de l'équipe et influencer le développement du produit.
Le concept d’impliquer toute l’équipe, les testeurs, les développeurs et des représentants
Métier, dans toute présentation, analyse ou estimation des caractéristiques du produit est
connu comme le « pouvoir des trois » ou encore les « 3 amigos ».
1.1.3 Un feedback au plus tôt et fréquent
Avec les approches de développement séquentielles, le client ne voit pas le produit avant
que le projet ne soit pratiquement terminé. À ce stade, il est souvent trop tard pour l'équipe
de développement de s’occuper efficacement des points que le client souhaiterait adresser.
Les projets Agiles ont des itérations courtes afin que l'équipe projet puisse recevoir des
feedbacks au plus tôt et continus sur la qualité des produits tout au long du cycle de
développement.
En recevant un feedback client fréquent au cours de la progression du projet, les équipes
Agiles peuvent intégrer la plupart des nouveaux changements dans le processus de
développement du produit.
Un feedback précoce et fréquent aide à mettre l'accent sur les fonctionnalités qui ont la plus
haute valeur Métier, ou les risques associés les plus importants, et celles-ci sont
livrées en premier au client.
Il permet également de mieux manager l’équipe puisque l’aptitude de l’équipe est
partagée avec tous. Par exemple,
 Quelle quantité de travail peut-on faire dans un sprint ou une itération ? (vélocité)
 Qu’est-ce qui pourrait nous aider à aller plus vite ? (accélérateurs)
 Qu’est-ce qui nous empêche de le faire ? (freins)
1.1.3 Un feedback au plus tôt et fréquent
Avantages :
 Eviter les incompréhensions sur les exigences qui n’auraient été décelées que plus
tard dans le cycle de développement lorsqu’elles sont plus coûteuses à corriger
 Clarifier les fonctionnalités que le client demande, les rendant disponibles au plus tôt
pour les clients afin que le produit reflète mieux ce que veut le client
 Découvrir, isoler et résoudre tôt les problèmes
 Être transparent sur la productivité et la capacité à livrer de l’équipe Agile
 Promouvoir une dynamique de projet durable
Une façon de fournir un feedback rapide est l’intégration continue (voir la Section 1.2.4).
Quiz Time !
Le Manifeste Agile comporte 4 déclarations sur les valeurs. Faites correspondre la valeur agile de
gauche (1-4) avec sa contrepartie traditionnelle de droite (i-iv).
1) La collaboration avec les clients plus que i) Les processus et les outils
2) L'adaptation au changement plus que ii) Le suivi d'un plan
3) Les individus et leurs interactions plus que iii) La négociation contractuelle
4) Des logiciels opérationnels plus que iv) Une documentation exhaustive.
Jeu de réponses :
A. 1 - iii, 2 - iv, 3 - ii, 4 – i
B. 1 - iii, 2 - ii, 3 - i, 4 – iv
C. 1 - iv, 2 - ii, 3 - i, 4 – iii
D. 1 - ii, 2 - iii, 3 - iv, 4 - i
Quiz Time !
Lequel des énoncés suivants reflète le mieux l'une des valeurs du Manifeste Agile ?
Jeu de réponses :
A. Un logiciel opérationnel permet au client de fournir un feedback rapide au développeur.
B. Les développeurs devraient utiliser des outils de test unitaire pour soutenir le processus de
test.
C. Les représentants Métier devraient fournir à l'équipe un backlog de user stories avec leurs
estimations.
D. Adapter les plans aux changements n'ajoute pas de valeur réelle à un projet agile.
Quiz Time !
Quelles sont les DEUX activités ci-dessous qui représentent le mieux les responsabilités qui sont
compatibles avec l'approche d'équipe intégrée du développement agile ?
Sélectionnez DEUX options.
Jeu de réponses :
A. Les testeurs sont responsables du développement des tests unitaires qu'ils transmettent aux
développeurs pour les tests.
B. On attend des représentants Métier qu'ils choisissent les outils que l'équipe utilisera au cours
du projet.
C. On attend des testeurs qu'ils travaillent avec les représentants des clients pour créer des tests
d'acceptation.
D. Toute l'équipe, et pas seulement les testeurs, est responsable de la qualité du produit.
E. On attend des développeurs qu'ils testent les exigences non fonctionnelles (performance,
convivialité, sécurité, etc.).
Quiz Time !
Lequel des éléments suivants est un avantage d'avoir toute l'équipe responsable de la qualité ?
Jeu de réponses :
A. Les entreprises n'ont plus besoin de recruter et de former des spécialistes du test de logiciels.
B. Les tâches d'automatisation des tests sont maintenant la responsabilité de l'équipe de
développement plutôt que de l'équipe de test.
C. Les obstacles liés aux rôles sont éliminés et les membres de l'équipe contribuent à la réussite
du projet en fonction de leurs compétences et perspectives particulières.
D. Les coûts du projet sont moins élevés parce qu'il n'est plus nécessaire de faire appel à une
équipe de test spécialisée.
Quiz Time !
Quels DEUX énoncés sont vrais parmi les suivants ?

1) Un feedback précoce donne aux développeurs plus de temps pour développer de nouvelles
fonctionnalités du système car ils passent moins de temps à retravailler les fonctionnalités
attendues dans une itération donnée.
2) Un feedback précoce permet aux équipes agiles de fournir d'abord les fonctionnalités ayant la
plus grande valeur métier, car le client reste concentré sur les fonctionnalités ayant la valeur
système la plus élevée.
3) Un feedback précoce réduit les coûts parce qu'il diminue le temps nécessaire pour tester le
système.
4) Un feedback précoce rend plus probable que le système construit est ce que le client voulait
parce qu'on lui donne l'occasion d'apporter des changements tout au long de l'itération.
Jeu de réponses :
A. 1 et 4
B. 2 et 3
C. 2 et 4
D. 1 et 3
Quiz Time !
Lequel des éléments suivants est un avantage du feedback précoce et fréquent favorisé par le
processus agile ?
Jeu de réponses :
A. Le nombre total de défauts trouvés au cours du projet est beaucoup plus élevé que sur les
projets traditionnels de développement de logiciels comme le modèle en cascade.
B. Il y a moins de reprises parce que les clients voient le produit régulièrement.
C. Il est facile de déterminer le développeur qui introduit le plus de défauts lors de l'intégration
du code.
D. Il y a assez de temps pour terminer toutes les fonctionnalités prévues pour l'itération donnée.
1.2 Aspects des approches Agile

1.2.1 Approches de développement logiciel Agile
Les pratiques courantes des organisations Agile comprennent :

 la création collaborative des User Story,
 les rétrospectives,
 l’intégration continue,
 la planification de chaque itération comme celle de la release globale.
Chacune des approches Agile implémente les valeurs et les principes du manifeste
Agile de différentes manières. Examinons trois implémentations représentatives de ces
approches Agiles :
 Extreme Programming (XP),
 Scrum,
 Kanban.
Extreme Programming (introduit par Kent Beck en 2004)
 5 valeurs pour guider le développement

 14 principes comme lignes directrices supplémentaires
 13 pratiques primaires
Extreme Programming : Valeurs Nous prendrons chaque engagement

d'itération au sérieux en livrant un
Nous dirons la vérité sur l’avancement et les logiciel opérationnel.
estimations. Nous faisons la démonstration de nos
Nous ne justifions pas nos échecs par des excuses logiciels très tôt, puis nous écoutons
parce que nous avons l'intention de réussir. attentivement et apportons toutes les
Nous n'avons peur de rien parce que personne ne modifications nécessaires.
travaille jamais seul. Nous parlerons du projet et y
Nous nous adapterons aux changements dès qu'ils adapterons nos processus, et non
se produiront. l'inverse.
Chacun donne et reçoit le respect Nous ferons ce qui est nécessaire et

qu'il mérite en tant que membre de demandé, mais pas plus.
l'équipe. Tout le monde apporte de Cela maximisera la valeur créée pour
la valeur, même s'il s'agit l'investissement réalisé à date.
simplement d'enthousiasme. Tout le monde fait partie de l'équipe Nous ferons de petits pas simples pour
Les développeurs respectent et nous communiquons en face à atteindre notre objectif et nous
l'expertise des clients et vice versa. face tous les jours. atténuerons les échecs au fur et à
La direction respecte notre droit de Nous travaillerons ensemble sur tout, mesure qu'ils se produiront.
prendre des responsabilités et de des exigences au code. Nous allons créer quelque chose dont
disposer de l'autorité sur notre Nous trouverons ensemble la nous sommes fiers et le maintenir à
propre travail. meilleure solution à notre problème. long terme pour des coûts raisonnables.
Extreme Programming : Principes (1/3)
 Humanité : Un logiciel est développé par des personnes, prendre en compte leurs besoins
est la clé principale pour fournir des logiciels de qualité
 Économie : Assurez-vous que ce que vous faites a de la valeur pour le client
 Bénéfice mutuel : Chaque activité doit profiter à toutes les parties concernées
 Similitude : Essayez de réutiliser des solutions similaires, dans des contextes différents
 Amélioration : Chaque jour, vous devez vous efforcer d'agir au mieux de vos capacités,
mais aussi de réfléchir à quoi faire pour être encore plus performant demain.
“In software development, ‘perfect’ is a verb,

not an adjective.”
 Diversité : Les équipes doivent avoir des connaissances, des compétences et des
caractères différents pour être en mesure de découvrir et de résoudre les problèmes
 Réflexion : Prendre le temps de réfléchir à la manière dont le projet fonctionne et aux
améliorations possibles
 Flux : Seul un flux continu permet de s'assurer que le système évolue dans la bonne
direction et d'éviter les problèmes liés à l'intégration finale "big-bang"
 Opportunité : Les problèmes doivent être considérés comme une opportunité de

s'améliorer
 Redondance : Les problèmes critiques et difficiles doivent être résolus de plusieurs
manières différentes. Ainsi, si une solution échoue, les autres préviendront une
catastrophe. Le coût de la redondance est facilement remboursé dans ces cas
 Échec : N'ayez pas peur d'échouer. Il vaut mieux essayer quelque chose et échouer, plutôt
que de retarder trop longtemps une action, en essayant de la rendre parfaite dès le début
 Qualité : La qualité doit toujours être au maximum. L'acceptation d'une qualité inférieure
n'entraîne sur le long terme ni économies, ni développement plus rapide.
 Petits pas : L'une des raisons des petits pas est qu'un petit pas dans la mauvaise direction
entraîne de petits dommages, alors qu'un grand pas qui échoue peut gravement
compromettre le projet
 Responsabilité acceptée : La responsabilité ne peut être imposée. Elle ne peut qu'être
acceptée
Extreme Programming : Pratiques primaires
 Stories : les fonctionnalités du système sont décrites à l'aide de stories, de brèves

descriptions des fonctionnalités visibles pour le client. Les stories guident le développement
du système.
 Cycle hebdomadaire : le développement du logiciel est effectué une semaine à la fois. Au
début de chaque semaine, il y a une réunion au cours de laquelle les stories à développer
au cours de la semaine sont choisies par le client.
 Cycle trimestriel : sur une échelle de temps plus longue, le développement est planifié un
trimestre à la fois ; à partir d'une réflexion sur l'équipe, le projet et son avancement.
 Se relâcher : évitez de faire des promesses que vous ne pouvez pas tenir. Dans tous les
plannings, incluez certaines tâches qui peuvent être abandonnées si vous prenez du retard.
De cette façon, vous conserverez une marge de sécurité, à utiliser en cas de problèmes
non prévus.
 S'asseoir ensemble : les équipes de développement doivent travailler dans un espace

ouvert, capable d'accueillir toute l'équipe, pour maximiser la communication.
 Équipe intégrée : l'équipe doit être composée de membres possédant toutes les
compétences et les perspectives nécessaires à la réussite du projet. Ils doivent avoir un
fort sentiment d'appartenance et s'entraider.
 Espace de travail informatif : l'espace de travail devrait être pourvu d'affiches
informatives et autres, donnant des informations sur le statut du projet et sur les tâches à
effectuer.
 Travail énergisé : les développeurs doivent être en forme et détendus, afin qu'ils
puissent se concentrer sur leur travail et être productifs. Par conséquent, limitez les heures
supplémentaires afin que chacun puisse consacrer du temps à sa vie privée. Cette pratique
dans l'ancienne version d'XP s'appelait "rythme durable".
 Programmation par paire : le code est toujours écrit par deux programmeurs sur une
même machine.
 Build en 10 minutes : L'objectif du Build en 10 minutes est de construire

automatiquement l'ensemble du système et d'exécuter tous les tests en 10 minutes.
• Cette pratique encourage votre équipe à automatiser votre processus de build afin que vous soyez
plus susceptible de le faire sur une base régulière et d'utiliser ce processus de build automatisé
pour exécuter tous vos tests.
• Cette pratique soutient la pratique de l'intégration continue et est soutenue par la pratique du
développement Test First.
 Intégration continue: L'intégration continue est une pratique où les changements de
code sont immédiatement testés lorsqu'ils sont ajoutés à une base de code plus large.
L'avantage de cette pratique est que vous pouvez détecter et résoudre les problèmes
d'intégration plus rapidement.
“if it hurts, do it more often”
 Conception incrémentale : XP s'oppose à la production d'un design complet dès le

départ. L'équipe de développement produit le code le plus tôt possible afin d'obtenir un
feedback et améliorer le système continuellement.
 Programmation Test-First : avant de mettre à jour et d'ajouter du code, il est
nécessaire d'écrire les tests pour vérifier le code. Cela résout quatre problèmes :
• Codage à la cow-boy : Il est facile de se laisser emporter à programmer rapidement et mettre
dans le code tout ce qu'on a en tête. Si nous écrivons des tests et que nous devons les exécuter,
les tests nous aident à nous concentrer sur le problème en question, et peuvent prouver que notre
conception est correcte.
• Couplage et cohésion : si vous avez du mal à écrire un test, c’est que vous avez
un problème de conception, non de test ni de codage. Si votre code est faiblement
couplé et hautement cohésif, vous pouvez le tester facilement.
• Confiance : si vous écrivez du code qui fonctionne et que vous le documentez avec des tests
automatisés, vos coéquipiers vous feront confiance.
• Rythme : il est facile de se perdre et d'errer pendant des heures quand on code. Si vous vous
habituez au rythme : test, code, refactor, test, code, refactor, cela n'arrivera pas.
Scrum est un Framework de management Agile qui contient les éléments et règles
suivants :
 Scrum divise un projet en courtes itérations (appelées sprints) de longueur fixe

(habituellement de 2 à 4 semaines).
 Chaque résultat de sprint est un produit potentiellement déployable (appelé
incrément).
 Le Product Owner gère une liste priorisée d’éléments du produit (appelée le Backlog
Produit). Le backlog produit évolue de sprint en sprint (raffinement du backlog).
 Au début de chaque sprint, l’équipe Scrum sélectionne un ensemble d’éléments de priorité
haute (constituant le backlog de sprint) à partir du backlog Produit.
 C’est l’équipe Scrum, et non le Product Owner, qui sélectionne les éléments qu’elle
peut s’engager à réaliser dans le sprint.
Definition of Done
La Définition du Terminé permet d’assurer qu’il y a un produit potentiellement livrable à
chaque fin de sprint, l’équipe Scrum discute et définit les critères appropriés pour la
complétude du sprint.
 La discussion dépend de la compréhension par l’équipe des éléments du backlog et des
exigences Produit.
 Exemple de DoD :
• La revue de code a été effectuée
• Les tests définis dans la User Story ont été réalisés et passés avec succès
• Le Product Owner a vu la démo et a validé le fonctionnement
• Des éléments techniques peuvent également être inclus le cas échéant : des stress tests ont été
réalisés, la documentation concernant l’architecture est fournie…
Timeboxing : Seules les tâches, les exigences, ou les fonctionnalités que l’équipe souhaite
finir dans le sprint font partie du backlog de sprint.
 Si l’équipe de développement ne peut pas finir une tâche lors d’un sprint, la fonctionnalité
du produit associée est supprimée du sprint et est replacée dans le backlog Produit.
 Le Timeboxing s’applique non seulement aux tâches, mais à d’autres situations (ex :
respecter les heures de début et de fin des réunions).
Transparence: L’équipe de développement rapporte et met à jour le statut du sprint sur une
base journalière appelée le Daily Scrum. Cela permet de rendre visible le contenu et
l’avancement du sprint en cours, en incluant les résultats de test, pour l’équipe de
management et toutes les parties intéressées.
Scrum (contrairement à XP) ne dicte pas de technique de développement spécifique (ex :

TDD ou pair programming). De plus, Scrum ne guide pas sur la façon dont le test doit être
réalisé dans un projet Scrum.
Scrum définit trois rôles (≠ des 3 amigos)
 Le Scrum Master :
• assure que les pratiques et les règles Scrum sont implémentées et suivies, et résout toute
violation, problème de ressource, ou tout autre blocage qui pourrait empêcher l’équipe de suivre
les pratiques et les règles.
• Le Scrum Master n’est pas le chef de l’équipe, mais un coach.
 Le Product Owner :
• génère, maintient, et priorise le backlog produit ; valide l’incrément produit lors de la démo
• Le Product Owner n’est pas le chef de l’équipe, il représente le client
 L’équipe de développement :
• développe et teste le produit.
• L’équipe est autoorganisée et prend ses décisions (il n’y a pas de chef d’équipe)
• L’équipe est pluridisciplinaire (voir Section 2.3.2 et Section 3.1.4).
Kanban est une approche de management souvent utilisée dans les projets Agile.
L’objectif général est de visualiser et d’optimiser le flux de travail dans une chaîne de
valeur ajoutée (livrer au plus tôt les items de plus grande valeur).
Kanban utilise trois instruments principaux :
 La visualisation du travail en cours (sur un tableau Kanban) : tout le monde peut voir à
tout moment ce qui est développé et par qui
 La limitation de la quantité de travail en cours (Work In Progress ou WIP) : on fixe un
nombre maximal d’items à chaque étape du Kanban sur lesquels les personnes assignées
peuvent travailler afin d’éviter la dispersion de l’équipe et les goulots d’étranglement pour
passer d’une étape à l’autre.
 Le travail en flux tiré : c’est la demande (en aval) qui tire le travail et non l’inverse. On
produit ainsi juste à temps, en limitant les gaspillages.
Le Timeboxing est optionnel, contrairement à Scrum qui synchronise toutes les tâches dans
un sprint. Le processus Kanban permet de livrer élément par élément en continu.
Kanban comporte des similitudes avec Scrum. Dans les deux frameworks, visualiser les tâches
actives sur un tableau donne de la transparence sur le contenu et la progression des tâches.
Les tâches non encore planifiées sont priorisées et en attente dans un backlog et déplacées sur
le tableau Kanban au fur et à mesure de leur avancement.
Mais Kanban régule le flux en imposant des limites de WIP sur chaque phase, ce qui met en
évidence les goulets d’étranglements et incite à les débloquer plutôt que d’empiler du travail en
attente.
Le principe est « Arrêtez de commencer (des tâches), commencez par terminer ! (celles
en cours) ».
1.2.2 Création collaborative de User Story
Les spécifications sont souvent une des raisons majeures de l’échec de projets. Les
problèmes de spécification peuvent résulter du manque de vision des utilisateurs dans leurs
besoins réels, de l’absence de vision globale du système, des fonctionnalités redondantes ou
contradictoires, et autres problèmes de communication.
Dans un cycle de développement séquentiel, cette vision partagée des fonctionnalités est
donnée au travers des revues formelles après que les exigences soient écrites.
Dans un développement Agile, les User Story sont écrites pour capturer les exigences selon le
point de vue des développeurs, des testeurs, et des représentants Métier.
Dans un projet Agile, cette vision est donnée à travers des revues informelles fréquentes
en même temps que les exigences sont écrites.
Les User Story doivent adresser à la fois les caractéristiques fonctionnelles et non-
fonctionnelles.
Chaque Story inclut des critères d’acceptation pour ces caractéristiques.
Ils donnent une vision étendue de la fonctionnalité aux développeurs et aux testeurs,
fonctionnalité que les représentants Métier vont valider.
Une équipe Agile considère une tâche terminée quand un ensemble de critères d’acceptation
ont été satisfaits.
Ces critères devraient être définis par une collaboration entre les représentants
Métier, les développeurs, et les testeurs.
Cette paternité collaborative de la User Story peut nécessiter de mettre en
œuvre des techniques comme le brainstorming ou le mind-mapping.
Typiquement, la vision du testeur va améliorer la User Story en identifiant
des détails manquants ou des exigences non fonctionnelles.
Un testeur peut contribuer en posant des questions ouvertes sur la User Story aux
représentants Métier, en proposant des façons de tester la User Story, et de confirmer les
critères d’acceptation.
Le testeur peut utiliser la technique INVEST pour les user stories :
 Independent : ne doivent pas dépendre d'autres stories
 Negotiable : doivent exprimer l'essentiel du besoin pour pouvoir être discutées
 Valuable : doivent clairement illustrer la valeur apportée au client
 Estimable : doivent fournir assez d'informations pour une estimation approchée
 Small : la granularité doit être suffisante pour qu'elles puissent être réalisées en aussi peu
de temps que possible
 Testable : doivent pouvoir être testées (un moyen efficace d'assurer la testabilité consiste
à définir des critères d'acceptation pour chaque user story)
Selon le concept des 3C, une User Story est la conjonction de trois éléments :
 Carte: La carte est le media physique décrivant la User Story et ses bénéfices attendus.
Elle identifie l’exigence, sa criticité, les temps de développement et de test, et les critères
d’acceptation pour cette User Story. La description doit être précise, car elle sera utilisée
dans le backlog produit.
 Conversation : La conversation explique comment le logiciel sera utilisé. La conversation
peut être documentée ou verbale. Les testeurs ayant des points de vue différents des
développeurs et des représentants Métier apportent des éléments de valeur pour échanger
sur des idées, opinions, et expériences.
La Conversation commence pendant la phase de planification de la release et
continuera quand la User Story sera planifiée (dans un sprint par exemple).
 Confirmation: Les critères d’acceptation, discutés dans la Conversation, sont utilisés pour
confirmer que la User Story est terminée.
• Ces critères d’acceptation peuvent s’étendre sur plusieurs User Stories.
• Des tests à la fois positifs et négatifs devraient être mis en œuvre pour couvrir les critères.
• Pendant la confirmation, différents participants peuvent jouer le rôle de testeur (développeurs ou
spécialistes en performance, sécurité, interopérabilité, et autres caractéristiques qualité).
• Pour considérer une User Story comme terminée (Done), les critères d’acceptation définis
devraient être testés et leur atteinte démontrée.
Quelle que soit l’approche mise en œuvre pour documenter les User Story, la documentation
devrait être :
 concise,
 suffisante,
 et nécessaire.
1.2.3 Rétrospectives
Une rétrospective est une réunion qui se tient à la fin de chaque itération pour discuter de
ce qui est réussi, de ce qui peut être amélioré, et comment intégrer les améliorations tout
en conservant ce qui est réussi dans les itérations futures.
Les rétrospectives couvrent des éléments comme le processus, les personnes, l’organisation, le
relationnel, et les outils.
Conduites régulièrement, les rétrospectives sont essentielles pour l’auto-organisation et
l’amélioration continue du développement et des tests.
En général, les équipes devraient implémenter seulement quelques améliorations par
itération. Ceci permet une amélioration continue à un rythme soutenable.
Les représentants Métier et l’équipe participent à chaque rétrospective. Dans certains cas,
l’équipe peut inviter d’autres participants à la réunion.
Les rétrospectives doivent se dérouler dans un environnement professionnel de confiance
mutuelle. Les caractéristiques d’une rétrospective réussie sont les mêmes que celles pour tout
autre revue.
1.2.4 Intégration Continue
La livraison de l’incrément d’un produit requiert qu’il soit fiable, qu’il fonctionne, et qu’il soit
intégré dans le logiciel à la fin de chaque sprint.
L’intégration continue permet ce challenge en fusionnant tous les changements faits au logiciel
et en intégrant régulièrement tous les composants modifiés, au moins une fois par jour.
La gestion de configuration, la compilation, le Build du logiciel, son déploiement, et les tests
sont inclus dans un processus simple, automatisé, et répétitif.
Puisque les développeurs intègrent, buildent et testent leur travail constamment, les défauts
dans le code sont détectés plus rapidement.
Check-in
Codage,
Debuggage
Le processus d’intégration continue inclut les activités automatisées suivantes:

 Analyse statique du code: Exécuter l’analyse statique de code et faire le reporting des
résultats
 Compilation: Compiler et lier le code, générer les fichiers exécutables
 Tests unitaires: Exécuter les tests unitaires, vérifier la couverture du code et faire le
reporting des résultats des tests
 Déploiement: Installer le Build dans un environnement de tests
 Test d’Intégration: Exécuter les tests d’intégration et faire le reporting des résultats
 Reporting (tableau de bord): Publier le statut de toutes les activités dans un endroit
public visible ou par email à l’équipe.
L’intégration continue permet aux testeurs Agile d’effectuer les tests automatisés
régulièrement et envoie des feedbacks rapides à l’équipe sur la qualité du code.
Ces résultats de test sont visibles de tous les membres de l’équipe en particulier quand des
rapports automatisés sont intégrés au processus.
Les tests de régression automatisés peuvent être continus tout au long de l’itération.
Une bonne couverture dans les tests de régression automatisés aide à construire (et à tester)
de grands systèmes intégrés.
Lorsque le test de régression est automatisé, les testeurs Agiles sont libérés pour concentrer
leurs tests manuels sur les nouvelles fonctionnalités, les changements implémentés
et les tests de confirmation.
Contrôle et assurance qualité

En plus des tests automatisés, les organisations qui utilisent l'intégration continue utilisent
généralement des outils de build pour mettre en œuvre un contrôle qualité continu :
 tests statiques et dynamiques supplémentaires,
 mesure des performances,
 extraction de la documentation du code source,
 et faciliter les processus manuels d'assurance qualité (respect des normes de nommage, de
programmation…).
Cette application continue du contrôle de la qualité vise à améliorer la qualité du produit ainsi
qu'à réduire le temps nécessaire à sa livraison en remplaçant la pratique traditionnelle qui
consiste à appliquer le contrôle de la qualité après tout le développement.
Déploiement
Les outils de build peuvent être liés à des outils de déploiement automatique, qui peuvent
récupérer le build approprié à partir de l'intégration continue ou du serveur de build et le
déployer dans un ou plusieurs environnements de développement, test, pré-production ou
même en production.
Cela réduit les erreurs et les délais associés au recours à du personnel spécialisé ou à des
programmeurs pour installer les versions dans ces environnements.
Bénéfices
 Permet la détection au plus tôt et facilite l’analyse des causes racines des problèmes dus à
l’intégration et à des changements conflictuels
 Donne un feedback régulier à l’équipe de développement pour confirmer que le code
fonctionne.
 Maintient un délai d'un jour maximum entre la version du logiciel testé et la version en
cours de développement.
 Réduit le risque de régression associé au refactoring du code du développeur grâce à un
re-test rapide de la base de code après chaque petite série de modifications.
 Assure que le travail de développement de chaque jour s’appuie sur une base solide
 Rend visible l'avancement vers l'achèvement de l'incrément du produit, en motivant les
développeurs et les testeurs
 Élimine les risques plannings associés à une intégration big-bang
 Fournit une disponibilité constante du logiciel exécutable tout au long du sprint à des fins
de test, de démonstration ou de formation
 Réduit les activités répétitives de tests manuels
 Fournit un feed-back rapide sur les décisions prises pour améliorer la qualité et les tests
Risques et challenges
 Les outils d’intégration continue doivent être mis en place et maintenus
 Le processus d’intégration continue doit être défini et établi
 L’automatisation des tests requiert des ressources additionnelles et peut être complexe à
mettre en place
 Une couverture de test étendue est essentielle pour que les avantages des tests
automatisés soit réels
 Les équipes font parfois trop confiance aux tests unitaires et font trop peu de tests
systèmes et d’acceptation
L’intégration continue requiert l’utilisation d’outils incluant les outils de test, les outils
d’automatisation du processus de Build, et les outils de contrôle de version.
1.2.5 Planification de release et d’itérations
La planification est une activité continue, et c'est également le cas dans les cycles de vie
Agile.
Pour les cycles de vie Agile, deux types de planification interviennent, la planification des
releases et la planification des itérations.
La planification de release couvre jusqu’à la release du produit, et est souvent faite
quelques mois avant le début du projet. Le planning de release définit et redéfinit le backlog
de produit, et peut impliquer de raffiner des User Story trop grosses en un ensemble de
Story plus petites.
Le planning de release fournit les bases pour une approche de tests et un plan de
test couvrant toutes les itérations.
Les plans de Release sont de haut niveau.
Une fois la planification de release terminée, la planification d’itération pour la première
itération commence.
La planification d’itération va jusqu’à la fin d’une seule itération et est liée au backlog
d’itération.
La planification de release et d’itération est globale et devrait adresser la planification des

tests tout comme la planification des activités de développement. Les sujets spécifiques aux
tests incluent :
 Le périmètre du test, l’étendue des tests pour ce périmètre, les objectifs de test, et les
raisons de ces décisions.
 Les membres de l’équipe qui prennent en charge les activités de test
 Les environnements de test et les données de test nécessaires, quand elles sont
nécessaires, et si aucun ajout ou changement à l’environnement de test et/ou aux données
va survenir avant ou pendant le projet.
 Le calendrier, le séquencement, les dépendances, et les prérequis pour les activités
de test fonctionnels et non fonctionnels (Ex: Quelle fréquence d’exécution des tests de
régression, quelles fonctionnalités dépendent de telle autre ou de données de test, etc),
incluant comment les activités de test sont liées à et dépendent des activités de
développement
 Les risques Qualité et projet à adresser (voir Section 3.2.1)
Bien sûr, la planification globale doit tenir compte du temps et de la charge de travail
nécessaires pour mener à bien les activités de test requises.
Planification de release
Pendant la planification de release, les représentants Métier établissent et priorisent les User
Story pour la release, en collaboration avec l’équipe (voir Section 1.2.2).
Basés sur ces User Story, les risques projet et qualité sont identifiés et une estimation
macroscopique de l’effort est effectuée (voir Section 3.2).
Les testeurs sont impliqués dans la planification de release et apportent de la valeur ajoutée
en particulier dans les activités suivantes :
 Définir des User Story testables, incluant des critères d’acceptation
 Participer aux analyses de risque projet et qualité
 Estimer l’effort de test associé aux User Story
 Définir les niveaux de test nécessaires
 Planifier les tests pour la release
Planification d’itération (1/2)

Pendant la planification de l’itération, l’équipe sélectionne les User Story depuis le backlog
de release priorisé, développe et précise les User Story, complète l’analyse des risques si
nécessaire, et estime la charge pour chacune.
Si une User Story est trop vague, et que les tentatives pour la clarifier ont échoué, l’équipe
peut refuser de l’accepter et utilise la User Story suivante dans l’ordre de priorité.
Les représentants Métier doivent répondre aux questions de l’équipe au sujet de chaque Story
de façon à ce que l’équipe puisse comprendre ce qu’ils doivent implémenter et comment
tester chaque Story.
Le nombre de Story sélectionnées est basé sur la vélocité établie de l’équipe et la taille
estimée des User Story sélectionnées.
Une fois le contenu de l’itération finalisé, les User Story sont divisées en tâches qui
seront prises en charge par les membres appropriés de l’équipe.
Planification d’itération (2/2)

Les testeurs sont impliqués dans la planification d’itération et apportent de la valeur ajoutée
en particulier dans les activités suivantes:
 Participer à l’analyse détaillée des risques des User Story
 Identifier les aspects fonctionnels et non fonctionnels du système à tester
 Déterminer la testabilité des User Story
 Définir les tests d’acceptation pour les User Story
 Diviser les User Story en tâches (particulièrement les tâches de test)
 Estimer l’effort de test pour toutes les tâches de test
Changements (1/2)
Les plans de release peuvent changer en cours de projet, en incluant des changements
sur les User Story individuelles dans le backlog de produit.
Ces changements peuvent être dus à des facteurs internes ou externes.
 Les facteurs internes incluent les capacités à délivrer, la vélocité, et les problèmes
techniques.
 Les facteurs externes incluent la découverte de nouveaux marchés et opportunités, de
nouveaux concurrents, ou des menaces liées au métier qui peuvent changer les objectifs
de release et/ou les dates prévues.
De plus, les plans d’itération peuvent changer pendant une itération.
 Par exemple, une User Story particulière qui était considérée relativement simple lors de
l’estimation peut s’avérer plus complexe que prévue.
Ces changements peuvent s’avérer difficiles pour les testeurs.
Changements (2/2)
Pour planifier les tests, les testeurs doivent avoir une image globale de la release.
Pour développer des tests, ils doivent avoir une base de test adéquate avec des oracles
de test à chaque itération.
Les informations requises doivent être disponibles tôt pour le testeur, et pourtant les
changements doivent être adoptés selon les principes Agile.
Ce dilemme requiert des décisions réfléchies au sujet des stratégies de test et de la
documentation des tests afin de faire face aux challenges des tests Agile (cf. slide suivant).
Challenges des tests Agile

 Faire face au volume et à la vitesse du changement
 Rester efficace pendant les itérations très courtes
 Recevoir du code après un test unitaire incohérent et souvent inadéquat
 Gérer le risque accru de régression
 Se débrouiller avec des oracles de test pauvres, changeants ou manquants
 Gérer une base de test changeante
 De la documentation détaillée à de nombreuses réunions
 Se tenir à des durées de sprint arbitraires
 Gérer les angles morts dans les silos de sprint
 Gérer les attentes
Pour plus d’informations sur les challenges des tests Agile, voir [Rex Black, “Managing the
Testing Process: Practical Tools and Techniques for Managing Hardware and
Software Testing, 3e,” Wiley, 2009.], Chapitre 12.
Quiz Time !
Faites correspondre les approches de développement logiciel agiles suivantes (1, 2, 3) avec leurs
descriptions correspondantes (I, II, III).
1) Extreme Programming
2) Scrum
3) Kanban
I. Adopte 5 valeurs pour guider le développement : Communication, simplicité, feedback, courage
et respect
II. Divise le projet en courtes itérations appelées sprints.
III. Optimise le " flux " du travail dans une chaîne de valeur ajoutée.
Jeu de réponses :
A. 1-iii, 2-i, 3-ii
B. 1-i, 2-ii, 3-iii
C. 1-ii, 2-iii, 3-i
D. 1-iii, 2-ii, 3-i
Quiz Time !
Au cours d'une réunion de planification d'itération, l'équipe partage ses réflexions sur une user
story. Le Product Owner indique que le client devrait avoir un seul écran pour entrer l'information.
Le développeur explique qu'il y a des limites techniques à cette caractéristique, en raison de la
quantité d'informations qu'il faut saisir à l'écran. Un autre développeur affirme qu'il y a des
risques quant aux performances car l'information sera stockée dans une base de données externe
hors site.
Lequel des éléments suivants représenterait le mieux la contribution d'un testeur à cette
discussion ?
Jeu de réponses :
A. Le testeur indique qu'il faut que l'écran pour la user story soit sur une seule page pour réduire
l'effort d'automatisation du test.
B. Le testeur indique que l'utilisabilité est plus importante que la performance.
C. Le testeur conseille que les critères d'acceptation des performances devraient être d'une
seconde maximum pour le stockage des données.
D. Le testeur indique que la user story a besoin de critères d'acceptation pour être testable.
Quiz Time !
Lequel des énoncés suivants décrit le MIEUX un testeur qui participe à une rétrospective ?
Jeu de réponses :
A. En tant que testeur participant à une rétrospective, je devrais aborder des sujets qui ne sont
liés qu'aux tests. Tous les autres sujets seront abordés par d’autres participants.
B. En tant que testeur, je participe à une rétrospective en tant qu'observateur, en m'assurant que
la réunion respecte les règles de rétrospectives et les valeurs agile.
C. En tant que testeur participant à une rétrospective, je devrais fournir des commentaires et des
suggestions sur toutes les activités menées par l'équipe pendant le sprint.
D. En tant que testeur, je ne devrais assister et participer à une rétrospective que si j'ai des
commentaires et des suggestions concernant les activités menées par l'équipe pendant le sprint.
Quiz Time !
Lequel des points suivants NE devrait PAS être soulevé au cours d'une rétrospective ?
Jeu de réponses :
A. Il faudrait mettre davantage l'accent sur les tests unitaires à l'avenir, afin d'améliorer la qualité
globale.
B. Le processus de build est manuel et prend trop de temps. La recherche et la mise en œuvre
d'un framework de build automatisé devraient être effectuées.
C. Le testeur XYZ lutte pour trouver des défauts. Une formation en conception de tests est
requise pour cette ressource.
D. Les suites de tests de régression automatisés prennent trop de temps à s'exécuter. Une revue
des tests, afin d'éliminer des tests redondants ou inutiles est nécessaire.
Quiz Time !
Lequel des énoncés suivants N'EST PAS un principe de l'intégration continue ?
Jeu de réponses :
A. L'intégration continue permet faire des builds réguliers des logiciels modifiés, incluant les tests
et le déploiement, d'une manière automatisée.
B. L'intégration continue permet aux testeurs et aux parties prenantes de disposer fréquemment
de nouvelles versions.
C. L'intégration continue permet d'identifier rapidement les nouveaux défauts d'intégration et
facilite l'analyse de ces défauts.
D. L'intégration continue garantit que les tests des builds sont effectués manuellement, car cela
génère des résultats plus fiables que les scripts automatisés.
Quiz Time !
Laquelle des activités suivantes un testeur effectuerait-il au cours de la planification de la

release ?
Jeu de réponses :
A. Produire une liste de tests d'acceptation pour les user stories.
B. Aider à décomposer user stories en tâches plus petites et plus détaillées.
C. Estimer les tâches de test générées par les nouvelles fonctionnalités prévues pour cette
itération.
D. Aider à clarifier les user stories et s'assurer qu'elles soient testables.
Termes à retenir

Termes à retenir
Automatisation des tests : utilisation de logiciels pour exécuter ou supporter des

activités de tests, p.ex. gestion des tests, conception des tests, exécution des tests ou
vérification des résultats.
Base de test : L'ensemble des informations utilisées comme référence pour l'analyse et
la conception des tests.
Cycle de vie logiciel : Une période temporelle qui commence lorsqu’un produit logiciel
est conçu et se termine lorsque le logiciel n’est plus disponible à l’usage. Le cycle de vie
logiciel inclut typiquement une phase de mûrissement, une phase d’exigences, une phase
de conception, une phase d’implémentation, une phase de test, une phase d’installation et
livraison, une phase d’opération et de maintenance, et parfois une phase de retrait.
Note : ces phases peuvent se superposer ou être exécutées de façon itérative.
Développement logiciel Agile : Un ensemble de méthodologies de développement
logiciel basées sur le développement itératif incrémental, où les exigences et les solutions
évoluent grâce à la collaboration entre des équipes pluridisciplinaires autoorganisées.
Développement piloté par les tests : Une façon de développer un logiciel dans laquelle
les cas de test sont développés, et souvent automatisés, avant que le logiciel ne soit
développé pour exécuter ces cas de test.
Termes à retenir
Manifeste Agile : Une déclaration sur les valeurs qui sous-tendent le développement
logiciel Agile. Ces valeurs sont :
Les individus et leurs interactions plus que les processus et les outils
Des logiciels opérationnels plus qu’une documentation exhaustive
La collaboration avec les clients plus que la négociation contractuelle
L’adaptation au changement plus que le suivi d’un plan
Modèle de développement incrémental : Un modèle de cycle de vie du développement
dans lequel la portée du projet est généralement déterminée au début du cycle de vie du
projet, mais les estimations de temps et de coûts sont régulièrement modifiées à mesure
que l'équipe du projet comprend mieux le produit. Le produit est développé au moyen
d'une série de cycles répétés, chacun fournissant un incrément qui ajoute successivement
à la fonctionnalité du produit.
Modèle de développement itératif : un modèle de cycle de développement où le projet
est séparé en un nombre d’itérations (souvent nombreuses). Une itération est une boucle
complète de développement résultant en une livraison (interne ou externe) d’un produit
exécutable, un sous-ensemble du produit final en développement, qui grandit d’itération
en itération pour devenir le produit fini.
Termes à retenir
Oracle de test : Source utilisée pour déterminer les résultats attendus à comparer avec
les résultats obtenus de l’application en cours de test.
User Story : Une exigence d'utilisateur ou métier de haut niveau communément utilisée
dans le développement de logiciels Agile, qui consiste généralement en une phrase dans
le langage courant ou le langage métier capturant la fonctionnalité dont un utilisateur a
besoin et la raison de ce besoin, les critères non fonctionnels, ainsi que les critères
d'acceptation.
Quiz Time !
Quelle est l'explication la plus appropriée d'une " user story " ?
Jeu de réponses :
A. Un artefact que le testeur doit examiner et approuver avant que le test puisse commencer.
B. Un artefact utilisé pour détailler uniquement les exigences fonctionnelles du système.
C. Un artefact documenté par les représentants Métier pour aider les développeurs et les testeurs
à comprendre les exigences du système.
D. Un artefact écrit en collaboration par des développeurs, des testeurs et des représentants
Métier pour capturer les exigences.
2 Principes, Pratiques, et Processus
fondamentaux Agile
2.1 Les différences des tests entre les

approches traditionnelles et Agile

2.1 Les différences des tests entre les approches traditionnelles
et Agile
Les activités de test sont liées aux activités de développement, et donc les tests varient
suivant les différents cycles de vie du logiciel.
Les testeurs doivent comprendre les différences entre tester dans un modèle de cycle de vie
traditionnel (ex: séquentiel comme le modèle en V ou itératif comme RUP) et les cycles de vie
Agile de façon à travailler efficacement et de façon efficiente.
Les modèles Agile diffèrent :
 dans la façon dont les activités de test et de développement sont intégrées,
 dans les produits d’activité des projets,
 les noms, les critères d’entrée et de sortie utilisés pour différents niveaux de test,
 l’utilisation d’outils,
 et la façon dont le test indépendant peut être utilisé efficacement.
2.1 Les différences des tests entre les approches traditionnelles
et Agile
Les organisations varient considérablement dans l’implémentation de leur cycle de vie.
Des déviations des cycles de vie Agile idéaux (voir Section 1.1) peuvent être en fait des
personnalisations intelligentes et une adaptation des pratiques.
La capacité à s’adapter au contexte d’un projet donné, en incluant les pratiques de
développement logiciel réellement suivies, est un facteur clé de succès pour les testeurs.
2.1.1 Activités de test et de développement
Spécificité des tests agiles

Une des différences principales entre les cycles de vie traditionnels et les cycles de vie Agile est
l’idée d’avoir des itérations très courtes, chaque itération résultant dans un logiciel
opérationnel qui délivre des éléments de valeur aux parties prenantes Métier.
Au début du projet, il y a la période de planification de release.

Elle est suivie par une suite séquentielle d’itérations.
Au début de chaque itération, il y a une période de planification d’itération.
Quand le périmètre de l’itération est établi, les User Story sélectionnées sont développées,
intégrées dans le système, et testées.
Ces itérations sont hautement dynamiques, avec un développement, une intégration, et des
activités de test, effectuées avec un parallélisme et des chevauchements considérables.
Les activités de test se déroulent tout au long de l’itération, et ne sont pas une activité
finale.
Rôles
Les testeurs, développeurs, et les parties prenantes Métier ont tous un rôle concernant le
test, tout comme dans les cycles de vie traditionnels.
 Les développeurs exécutent des tests unitaires au moment où ils développent les
fonctionnalités à partir des User Story.
 Les testeurs testent ensuite ces fonctionnalités.
 Les parties prenantes Métier testent également les Story pendant l’implémentation.
 Les parties prenantes Métier peuvent utiliser des cas de test écrits, mais ils peuvent
simplement expérimenter et utiliser la fonction de manière à fournir un feedback rapide à
l’équipe de développement.
Bonnes pratiques
Dans certains cas, des itérations de renforcement ou de stabilisation se font périodiquement
pour résoudre tous les défauts persistants et autres dettes techniques.
 Cependant, la meilleure pratique est qu’aucune fonctionnalité ne soit considérée comme
terminée tant qu’elle n’a pas été intégrée et testée dans le système.
Une autre bonne pratique (appelée « Corriger les bugs d’abord ») est de régler les défauts
restant de l’itération précédente au début de l’itération suivante, en tant que parties du backlog
de cette nouvelle itération.
 Même si cette pratique rend plus difficile d’estimer les fonctionnalités restantes qui pourront
être terminées dans le sprint (car les bugs du sprint précédent n’ont pas forcément encore été
analysés).
A la fin de la suite d’itérations, il peut y avoir un ensemble d’activités de déploiement pour
obtenir un logiciel prêt à être livré, bien que dans certains cas, le déploiement soit effectué à
la fin de chaque itération.
Risk-Based Testing et agilité

Quand le test basé sur les risques est utilisé comme une des stratégies de test, une analyse de
risque de haut niveau est effectuée pendant la phase de planification de release, avec les
testeurs qui conduisent souvent l’analyse.
Cependant, les risques qualité spécifiques associés à chaque itération sont identifiés et évalués
dans la planification d’itération.
Cette analyse de risque peut influencer la séquence de développement tout comme la priorité et
la profondeur de test des fonctionnalités.
Elle influence également l’estimation de l’effort de test requis pour chaque fonctionnalité. (voir
Section 3.2). Planification de la Planification de
release chaque itération
• Analyse de • Analyse détaillée

risques à haut des risques
niveau spécifiques à
l’itération
Travail en binôme
Dans certaines pratiques Agile (ex: Extreme Programming), le travail en binôme est utilisé.
 Deux testeurs
 Ou un testeur et un développeur
Le travail en binôme peut être plus difficile quand l’équipe de test est distribuée, mais les
processus et les outils le permettent.
Les testeurs peuvent également agir comme coach tests et qualité dans l’équipe, en
partageant leur connaissance des tests et en prenant en charge l’assurance qualité dans
l’équipe. Cela favorise un sentiment d’appropriation collective de la qualité du produit.
Automatisation et agilité
L’automatisation des tests à tous niveaux est très répandue dans les équipes Agile.
 Alors que les développeurs se focalisent sur la création de tests unitaires automatisés,
 Les testeurs devraient s’impliquer fortement sur la création de tests automatisés aux
niveaux intégration, système, et intégration du système.
Cela conduit à une tendance pour les équipes Agile de favoriser les testeurs qui ont un fort
background technique et d’automatisation de tests.
Parallèlement à la forte utilisation de l’automatisation des tests, les tests manuels sur les projets
Agile tendent souvent à être réalisés en utilisant les techniques de tests basés sur l’expérience ou
le défauts :
 Estimation d’erreurs,
 Tests exploratoires,
 Attaques logicielles
Automatisation et agilité
On ne peut envisager d’accélérer le cycle de développement (voire de déploiement) s’il faut à
chaque changement repasser par une longue phase de tests de non-régression manuelle.
Les tests automatisés sont le socle nécessaire pour bâtir la « pyramide des tests » équilibrée de
votre application (voir section 3.1.2) :
Changements
Un des principes de base Agile est que le changement peut arriver tout au long du projet.
 Par conséquent une documentation allégée du produit logiciel est favorisée dans les
projets Agile.
Les changements opérés sur des fonctions existantes peuvent avoir des implications concernant
les tests, particulièrement pour les tests de régression.
 L’utilisation de tests automatisés est une façon de gérer la quantité d’effort de test
associé au changement.
Bien entendu, il est important que le taux de changement n’excède pas la capacité de l’équipe
projet à gérer les risques associés à ces changements.
2.1.2 Produits d’activité des projets
Les produits d’activité (livrables) des projets qui intéressent directement les testeurs se
décomposent en trois catégories:
1. Les produits d’activité orientés Métier qui décrivent le besoin, (ex: spécifications
d’exigences) et l’utilisation (ex: Documentation utilisateur)
2. Les produits du développement qui décrivent comment le système est construit (ex:
diagrammes d’entité-relation), qui sont mis en œuvre dans le système (ex: code), ou qui évaluent
des parties de code individuelles (ex: test unitaires automatisés)
3. Les produits du test qui décrivent comment le système est testé (ex: stratégies et plans
de test), qui testent le système (ex: tests manuels et automatisés), ou qui présentent les
résultats des tests (ex: tableaux de bord des tests comme discuté dans la Section 2.2.1)
Dans un projet Agile typique, une pratique commune est d’éviter de produire de grandes
quantités de documentation.
A la place, le focus est mis sur le fait d’obtenir un logiciel opérationnel, avec des tests
automatisés qui démontrent la conformité aux exigences. Cet encouragement à réduire la
documentation s’applique seulement à la documentation qui n’apporte pas de valeur au
client.
Dans les projets Agile réussis, un équilibre est trouvé entre :
 augmenter l’efficacité en réduisant la documentation,
 et fournir une documentation suffisante pour permettre les activités des Métiers, de test, de
développement, et de maintenance.
L’équipe doit décider pendant la planification de release quels produits d’activité sont
requis et avec quel niveau de documentation.
Produits d’activité orientés Métier : les User Stories

 Les User Stories représentent les spécifications d’exigences, et décrivent comment le système
doit se comporter, par rapport à une fonctionnalité ou à une fonction unique et cohérente.
 Une User Story devrait définir une fonctionnalité suffisamment petite pour être réalisée
dans une simple itération.
 Des ensembles conséquents de fonctions connexes, ou un ensemble de sous fonctions qui
engendrent une fonctionnalité complexe, peuvent être appelés “Epics”.
 Les Epics peuvent inclure des User Stories qui concernent différentes équipes de
développement. Par exemple,
• une User Story peut décrire ce qui est requis au niveau API (middleware),
• une autre décrit ce qui est nécessaire au niveau interface utilisateur (application).
 Ces ensembles peuvent être développés dans une série de sprints.
 Chaque Epic et ses User Story devraient avoir des critères d’acceptation associés.
Produits du développement : le code et les tests

unitaires
 Les tests unitaires peuvent être créés traditionnellement
après le développement du code.
 Dans certains cas, les développeurs créent des tests de
façon incrémentale, avant d’écrire chaque portion de
code, de façon à vérifier qu’il fonctionne comme prévu
une fois le code écrit.
• Bien que cette approche soit appelée « Test First » ou «
TDD : développement piloté par les tests », en réalité les tests
sont plus une forme de spécification de conception
exécutable de bas niveau que des tests
• Le TDD aide ainsi à documenter le code en vue de travaux
de maintenance futurs.
Produits d’activité du test :
 catalogues de risques qualité,
 plans de test,
 tests manuels ou automatisés,
 rapports de défauts,
 enregistrements (logs) de résultats de test,
 métriques de test (établis à partir des rapports de défauts et des logs de résultats de test).
Ces documents sont conçus pour être les plus légers possible (ce qui est souvent également vrai
pour ces documents dans les cycles de vie traditionnels).
Cependant, pour les projets et produits réglementés, critiques pour la sécurité, distribués
ou très complexes, une formalisation plus poussée de ces produits d’activité est nécessaire :
 Par exemple, les User Story et les critères d’acceptation sont traduites en des spécifications
d’exigences plus formelles.
 Des rapports de traçabilité verticaux (des exigences vers les composants) et horizontaux (des
exigences vers les tests) peuvent être produits pour satisfaire les auditeurs, les règlements, et
autres exigences.
2.1.3 Niveaux de Test
Les niveaux de test sont les activités de test liées logiquement (et donc organisées ensemble),
souvent en fonction de la maturité ou de la complétude de l’objet en test.
Dans les modèles de cycle de vie séquentiels, les niveaux de test sont souvent définis de façon à
ce que le critère de sortie d’un niveau soit une partie du critère d’entrée du niveau
suivant.
Dans certains modèles itératifs, ces règles ne s’appliquent pas parce que les niveaux de test
se chevauchent et que les spécifications d’exigences, les spécifications de conception, et les
activités de développement peuvent se chevaucher avec les niveaux de tests.
Dans certains cycles de vie Agile, les chevauchements existent car des changements dans les
exigences, la conception, peuvent se produire à tout moment d’une itération.
Alors que Scrum, en théorie ne permet pas les changements dans les User Stories après la
planification d’itération, de tels changements surviennent parfois en pratique.
Cycle de test d’une User Story dans une itération
 Tests unitaires, typiquement faits par le développeur.
 Tests d’acceptation, qui peuvent être découpés en deux activités.
• Les tests de vérification, souvent automatisés, qui peuvent être fait par les développeurs ou les
testeurs, et impliquent que le testeur suive les critères d’acceptation.
• Les tests de validation, habituellement manuels, qui peuvent impliquer des développeurs, des testeurs
et des parties prenantes du Métier dans un travail collaboratif pour déterminer si la fonction est
adaptée à l’utilisation, pour améliorer la visibilité sur l’avancement, et pour recueillir un vrai
feedback des parties prenantes Métier.
 De plus, il y a souvent un processus parallèle de tests de régression qui se déroule tout au
long de l’itération. Cela implique de rejouer les tests unitaires automatisés et les tests de
vérification de l’itération en cours et des précédentes, habituellement par un Framework
d’intégration continue.
 Il peut également y avoir un niveau de tests système qui commence une fois que la
première User Story est prête pour un tel test. Cela implique d’exécuter des tests
fonctionnels, ou non fonctionnels (pour la performance, fiabilité, utilisabilité…), ou d’autres
types de test pertinents.
Autres formes de tests d’acceptation
Les équipes Agile peuvent utiliser différentes formes de tests d’acceptation :
 Les alpha tests (sur environnement interne) et les beta tests (sur l’environnement du client)
peuvent avoir lieu soit à la fin de chaque itération, soit après une série d’itérations.
 De même, les tests d’acceptation utilisateur, les tests d’acceptation opérationnels, les
tests d’acceptation légaux, et les tests d’acceptation contractuels peuvent également
être déroulés soit à la fin de chaque itération, soit après une série d’itérations.
2.1.4 Tests et gestion de configuration
Les projets Agile impliquent souvent un usage élevé d’outils d’automatisation pour
développer les tests, et gérer le développement logiciel.
Les développeurs utilisent les outils pour l’analyse statique, les tests unitaires et la
couverture de code.
Les développeurs vérifient continuellement leur code et les tests unitaires dans un système de
gestion de configuration en utilisant des Build automatisés et des Framework de test.
Ces frameworks permettent l’intégration continue de nouveaux logiciels dans le système, avec
l’analyse statique et les tests unitaires joués répétitivement quand le nouveau logiciel est mis
en configuration.
Il est également courant d’ajouter des tests fonctionnels aux niveaux intégration et système dans
le Framework d’intégration continue (moyennant l’utilisation éventuelle de harnais de test ou
autres outils commerciaux ou opensources).
Dans certains cas, à cause de leur durée, les tests fonctionnels sont séparés des tests
unitaires et joués moins fréquemment.
2.1.4 Tests et gestion de configuration
Un des buts des tests automatisés est de confirmer que le Build est installable et fonctionne
 Si un test automatisé est en échec, l’équipe devrait corriger le défaut sous-jacent à temps
pour le prochain check-in du code.
 Cela requiert un investissement dans le reporting des tests en temps réel pour fournir une
bonne visibilité sur les résultats de test.
 Cette approche aide, en détectant rapidement les changements qui cassent le Build ou causent
l’échec de l’installation, à réduire des cycles coûteux et inefficaces de :
« Build  installation  échec  reBuild  réinstallation »
Les tests automatisés et les outils de Build aident à gérer le risque de régression associé aux
changements fréquents qui adviennent dans les projets Agile.
Cependant, la sur-confiance dans les seuls tests unitaires automatisés pour gérer ces risques peut
être un problème, car les tests unitaires ont souvent une efficacité de détection de défauts
limitée.
C’est pourquoi les tests automatisés au niveau intégration et système sont également
souhaitables.
2.1.5 Options d’organisation avec des tests indépendants
Comme discuté dans le niveau ISTQB Testeur Fondation, les testeurs indépendants sont
souvent plus efficaces pour trouver des défauts.
Dans certaines équipes Agile,
 Les développeurs créent de nombreux tests sous la forme de tests automatisés.
 Un ou plusieurs testeurs peuvent être intégrés dans l’équipe, et réaliser des tâches de test.
 Cependant, le testeur faisant partie de l’équipe, il y a un risque de perte
d’indépendance et d’évaluation objective.
D’autres équipes Agile restent complètement indépendantes,
 Testeurs ou équipes de test séparées, affectés à la demande pendant les derniers jours de
chaque sprint.
 Cela peut préserver l’indépendance, et ces testeurs peuvent fournir une évaluation objective,
non biaisée du logiciel.
 Cependant, la pression due aux délais, les manques de compréhension dans les
nouvelles fonctionnalités du produit, et les problèmes relationnels entre les parties
prenantes Métier et les développeurs, entrainent souvent des problèmes avec cette
approche.
2.1.5 Options d’organisation avec des tests indépendants
Une troisième option est d’avoir une équipe de test indépendante et séparée où les testeurs
sont affectés aux équipes Agile sur du long terme, en début de projet, ce qui leur permet de :
 garder leur indépendance et de gagner une bonne compréhension du produit et en ayant
un relationnel fort avec les autres membres d’équipe.
 De plus, l’équipe de test indépendante peut avoir des testeurs spécialisés en dehors de
l’équipe Agile pour travailler sur du long terme et/ou des activités indépendantes des itérations,
comme :
• le développement d’outils de test automatisés,
• la prise en charge des tests non fonctionnels,
• la création et le maintien des environnements et des données de test,
• ou la prise en charge de niveaux de test qui pourraient ne pas être adaptés à un sprint (ex: test
d’intégration système).
Quiz Time !
Lesquelles des activités de test suivantes sont généralement effectuées pendant les projets agiles,
mais ne sont pas aussi courantes sur les projets traditionnels ?
Jeu de réponses :
A. Les testeurs rédigent des plans de test détaillés afin que tous les membres de l'équipe puissent
comprendre ce qui sera testé à chaque itération.
B. Les testeurs sont fortement impliqués dans la création de cas de tests automatisés qui sont
ensuite utilisés pour vérifier la mise en œuvre des exigences.
C. Les testeurs effectuent des tests exploratoires afin de trouver rapidement les défauts
importants.
D. Les testeurs collaborent avec les développeurs pour mieux comprendre ce qui doit être testé.
Quiz Time !
Considérez les activités suivantes :

i. Application stricte des critères d'entrée et de sortie au niveau des tests système.
ii. Collaboration entre le testeur, le développeur et les parties prenantes de l'entreprise pour
définir les critères d'acceptation.
iii. Tests de vérification fonctionnelle des user stories développées lors de l'itération précédente.
Laquelle des combinaisons suivantes de ces activités devrait avoir lieu dans un projet agile ?
Jeu de réponses :
A. ii seulement
B. i et ii
C. ii et iii
D. iii seulement
Quiz Time !
Quels sont les DEUX énoncés suivants qui s'appliquent aux projets agiles ?
Jeu de réponses :
A. Les testeurs doivent travailler en étroite collaboration avec les développeurs tout en conservant
une perspective objective.
B. Les Test Managers n'existent pas dans les organisations qui font du développement agile.
C. Il n'y a pas de différence entre ce que les testeurs et les développeurs font sur les projets
agiles.
D. Les développeurs devraient se fier aux testeurs pour créer les tests de régression automatisés.
E. Une sélection d'utilisateurs peut effectuer un test bêta sur le produit après une série
d'itérations.
Quiz Time !
Lequel des énoncés suivants concernant les tests indépendants sur les projets agiles est FAUX ?
Jeu de réponses :
A. Il peut y avoir un risque de perdre l'indépendance des tests pour les organisations qui
introduisent l'agilité.
B. Les testeurs indépendants trouveront plus de défauts que les développeurs, quel que soit le
niveau de test.
C. Des tests indépendants peuvent être introduits à la fin d'un sprint.
D. L'équipe de test indépendante peut faire partie d'une autre équipe.
fondamentaux Agile
2.2 Statuts du test dans les projets Agile

2.2 Statuts du test dans les projets Agile
Les changements surviennent rapidement dans les projets Agile.

Ces changements signifient que les statuts du test, l’avancement des tests, et la qualité du
produit évolue constamment, et que les testeurs doivent trouver des moyens de
transmettre l’information de façon à ce que l’équipe puisse prendre des décisions pour rester
sur la bonne voie et réussir avec succès chaque itération.
De plus, les changements peuvent affecter des fonctionnalités existantes d’itérations précédentes
et les tests automatisés et manuels doivent donc être mis à jour pour traiter efficacement
les risques de régression.
2.2.1 Communiquer les statuts du test, l’avancement, et la
qualité Produit
Les testeurs dans les équipes Agile utilisent différentes méthodes pour enregistrer la progression
et le statut des tests :
 les reporting automatisés de résultats des tests,
 la progression des stories et des tâches associées sur le tableau des tâches Agile,
 les Burndown Charts montrant la progression de l’équipe.
Cela peut alors être communiqué au reste de l’équipe en utilisant des médias comme des
tableaux de bord partagés (Wiki, JIRA, Trello…) par email, tout comme verbalement pendant les
Stand-Up Meetings.
L’utilisation d’outils générant automatiquement les reportings sur la base des résultats des tests
et de l’avancement des tâches permet également de collecter des métriques sur le processus
de test, qui peuvent être utilisées dans l’amélioration du processus.
Cette automatisation permet aux testeurs de libérer du temps pour se focaliser sur la
conception et l’exécution de cas de test supplémentaires.
qualité Produit
Un Burndown Chart
présente la quantité de
travail restant à faire par
rapport au temps alloué à
la release ou à l’itération
qualité Produit
Un diagramme de vélocité présente les quantités de travail planifiées/réalisées au fil des
itérations.
Exemples
Dynamique d’amélioration Equipe sous-staffée Mise en tension trop forte de l’équipe

continue qui stabilise la vélocité  Réviser les estimations ou ayant créé une dette technique
 Pas de changement augmenter la taille de l’équipe  Inclure des actions de réduction de la
dette et réduire la taille du backlog au
prochain Sprint
qualité Produit
Tableau des tâches
Pour fournir une représentation à un instant
donné, détaillée et visuelle du statut actuel de
l’équipe intégrée, incluant les statuts
du test, les équipes peuvent utiliser le tableau de
tâches Agile.
Les cartes des Stories, les tâches de
développement, de test, et autres tâches créées
pendant la planification d’itération (voir Section
1.2.5) sont placées sur le tableau de tâches, en
utilisant souvent des cartes de couleurs
coordonnées, pour déterminer le type de tâche.
Pendant l’itération, l’avancement est montré via le mouvement de ces tâches au travers du
tableau dans des colonnes comme à faire, en cours, vérifié, et terminé.
Les tâches de Test sur le tableau de tâches sont liées aux critères d’acceptation
définis pour les User Stories et sont déplacées dans la colonne Terminé quand les tests sont
OK.
2.2.1 Communiquer les statuts du test,
l’avancement, et la qualité Produit
Stand-up meetings
Les stand-up meetings journaliers incluent tous les membres
de l’équipe Agile en incluant les testeurs.
L’ordre du jour de chaque membre est :
 Qu’est-ce que tu as terminé depuis la dernière réunion ?
 Qu’est-ce que tu prévois de terminer pour la prochaine réunion ?
 Comment comptes-tu avancer ?
Au cours du stand-up, l’équipe intégrée passe en revue le statut des tâches pour s’assurer que
ces dernières se déplacent sur le tableau des tâches à un rythme acceptable.
Si des tâches (y compris les tâches de test) ne bougent pas ou trop lentement, l’équipe passe en
revue et s’occupe des problèmes qui peuvent bloquer la progression de ces tâches.
Tous les problèmes qui peuvent bloquer la progression des tests sont communiqués pendant les
standup meetings journaliers, comme cela, toute l’équipe est au courant des problèmes et peut
les résoudre de la bonne façon.
2.2.1 Communiquer les statuts du test,
l’avancement, et la qualité Produit
Métriques
Pour améliorer la qualité du produit complet, de nombreuses équipes Agile
font des enquêtes de satisfaction des clients pour obtenir un feedback concernant le fait que
le produit atteint les attentes.
Les équipes peuvent, pour améliorer la qualité du produit, utiliser d’autres métriques similaires à
celles utilisées dans les méthodologies de développement traditionnels, comme :
 les taux de succès/échec,  les défauts trouvés et corrigés,

 les taux de découverte des défauts,  la couverture des exigences,
 les résultats des tests de confirmation et de  la couverture des risques,
régression,  la couverture de code,
 la densité de défauts,  le taux de modification du code
Comme dans tous les cycles de vie, les métriques capturées et reportées devraient être
pertinentes et aider à la prise de décision et ne devraient pas être utilisées pour récompenser,
punir, ou isoler des membres de l’équipe.
2.2.2 Gérer les risques de régression en faisant évoluer les cas de
test manuels et automatisés
Dans un projet Agile, le produit grossit à chaque itération et accroît le périmètre des tests.
En plus de tester les changements apportés au code dans l’itération en cours, les testeurs
doivent également vérifier qu'aucune régression n'a été introduite sur les fonctionnalités qui
ont été développées et testées dans les itérations précédentes.
En plus des changements liés à l’aspect incrémental d’Agile, d’autres modifications peuvent
régulièrement survenir pour répondre aux besoins de l'entreprise (répondre au changement étant
un principe Agile clé).
Le risque d'introduire des régressions dans le développement Agile est donc
particulièrement élevé.
Bonnes pratiques
Pour maintenir la vélocité sans augmenter fortement la dette technique, il est critique :
 que l’équipe s’investisse dans l’automatisation des tests à tous les niveaux de test aussi
tôt que possible.
 que tous les tests capitalisés comme les tests automatisés, les cas de test manuels, les
données de test, et autres artefacts de test soient mis à jour à chaque itération.
Il est donc hautement recommandé que tous les test capitalisés soient maintenus dans un outil
de gestion de configuration de façon à :
 permettre le contrôle des versions, avec un accès aisé à tous les membres de l’équipe,
 de manière à faciliter la mise en œuvre des modifications requises par les changements de
fonctionnalités en conservant l’historique des tests capitalisés.
Bonnes pratiques
Les tests écrits dans les itérations précédentes pour vérifier des caractéristiques spécifiques
peuvent avoir peu de valeur dans les itérations ultérieures en raison :
 de changements de caractéristiques
 ou de nouvelles caractéristiques qui modifient le comportement des caractéristiques
antérieures.
Pour cette raison et aussi parce que la répétition complète de tous les tests est rarement possible,
en particulier dans les projets Agile à cycles courts, il est nécessaire que les testeurs consacrent
du temps à chaque itération pour :
 examiner les cas de test manuels et automatisés des itérations précédentes et actuelles, pour
 retirer ceux qui ne sont plus pertinents,
 sélectionner les cas de test qui pourraient être des candidats dans la suite de tests de
régression,
 considérer le cas échéant leur aptitude à être automatisés.
Bonnes pratiques
Il est critique que les testeurs aient la possibilité d’identifier rapidement et de mettre à jour les
cas de test des itérations précédentes et/ou des releases qui sont affectées par les changements
faits dans l’itération en cours.
Définir comment l’équipe conçoit, écrit, et stocke les cas de test devrait être fait pendant la
planification de release.
Les bonnes pratiques de conception de test et d’implémentation ont besoin d’être adoptées tôt
et toujours appliquées, en particulier dans ce contexte où les délais sont plus courts pour
tester et les changements courants.
Des tests automatisés bien écrits fournissent un document vivant du fonctionnement du
système :
 En vérifiant les tests automatisés et leurs résultats de test dans le système de gestion de
configuration, aligné avec la gestion de version des produits construits,
 les équipes Agile peuvent faire la revue des fonctionnalités testées et les résultats de
test pour tout Build à n’importe quel moment dans le temps.
Tests unitaires automatisés
Les tests unitaires automatisés doivent être exécutés avant chaque check-in du code
source dans la branche principale du système de gestion de configuration pour assurer que les
changements de code ne cassent pas le Build du logiciel construit, avec un impact sur la
progression de l’ensemble de l’équipe intégrée.
Les résultats des tests unitaires automatisés fournissent un feedback immédiat sur la
qualité du code et du Build, mais pas sur la qualité du produit.
Tests d’acceptation automatisés
Les tests d’acceptation automatisés sont exécutés régulièrement comme une partie de
l’intégration continue du système complet construit.
Ces tests sont exécutés sur un système complet construit quotidiennement, mais ne sont
généralement pas exécutés à chaque mise sous contrôle (check-in) du code car ils prennent
plus longtemps à exécuter que les tests unitaires automatisés et pourraient ralentir le check-in.
Les résultats des tests d’acceptation automatisés fournissent du feedback sur la qualité
du produit concernant la régression depuis le dernier Build, mais ils ne fournissent pas
de statut sur la qualité complète du produit.
Tests de vérification de Build
Les tests automatisés peuvent être exécutés continuellement sur le système.
Un sous ensemble de tests automatisés pour couvrir les fonctionnalités et les points d’intégration
critiques du système devrait être créé dès qu’un nouveau Build est déployé dans
l’environnement de test.
Ces tests sont communément connus comme des tests de vérification du Build.
Les résultats des tests de vérification de Build fourniront un feedback instantané sur le logiciel
après déploiement, de façon à ce que les équipes ne perdent pas de temps à tester un Build
instable.
Les tests automatisés contenus dans l'ensemble de tests de régression sont généralement
exécutés :
 comme une partie du build principal quotidien dans l'environnement d'intégration continue,
 et à nouveau quand un nouveau build est déployé dans l'environnement de test.
Dès qu'un test de régression automatisé échoue, l'équipe s'arrête et examine les raisons de
l'échec du test.
 Le test peut avoir échoué en raison de changements fonctionnels légitimes dans l'itération en
cours, auquel cas le test et/ou la user story devront peut-être être mis à jour pour refléter les
nouveaux critères d'acceptation.
 Par ailleurs, il se peut que le test doive être retiré si un autre test a été construit pour couvrir
les changements.
 Cependant, si le test échoue en raison d'un défaut, il est conseillé à l'équipe de corriger le
défaut avant de continuer l'ajout de nouvelles fonctionnalités.
En plus de l’automatisation des tests, les tâches de test suivantes peuvent également être
automatisées :
 Génération de données de test
 Chargement de données de test dans les systèmes
 Déploiement de Builds dans l’environnement de test
 Restauration d’un environnement de test (ex : la base de données ou les fichiers de données
des sites web) dans un état de référence (baseline)
 Comparaison de données de sortie
L'automatisation de ces tâches réduit la charge de travail et permet à l'équipe de passer du temps
à développer et tester de nouvelles fonctionnalités.
Quiz Time !
Dans un projet agile, lequel des éléments suivants dénoterait le mieux la qualité du produit à la
fin de l'itération 6 d'une nouvelle version de système composée de 8 itérations ?
Jeu de réponses :
A. Aucun défaut de gravité 1 ou 2 n'a été détecté lors des tests système de l'itération 6, ce qui a
permis aux équipes de passer en itération 7.
B. Les résultats d'un test bêta effectué par le client sur la version 6 du logiciel indiquent que le
système fonctionne correctement et qu'il a amélioré sa productivité.
C. L'équipe agile a suivi avec succès les estimations, avec une variance limitée apparaissant sur
les tableaux de bord pour toutes les itérations à ce jour.
D. Toutes les user stories dans le périmètre de chaque itération, jusqu'à l'itération actuelle, ont
été marquées comme "Done", mais avec une certaine dette technique encourue.
Quiz Time !
Lequel des éléments suivants est le mieux à même de montrer la progression de l'équipe par
rapport aux estimations ?
Jeu de réponses :
A. Des burndown charts
B. Des journaux d'automatisation
C. Le tableau de tâches agile montrant la progression des user stories et des tâches
D. Des outils de suivi des défauts
Quiz Time !
Au cours de la planification de l'itération 5, le métier indique qu'il faut apporter des modifications
au système livré dans l'itération 3. Parmi les activités suivantes, laquelle faudrait-il faire en
premier lieu pour minimiser le risque de régression lorsque cette fonctionnalité sera modifiée ?
Jeu de réponses :
A. Examiner et mettre à jour tous les tests manuels et automatisés touchés par ce changement
afin de répondre aux nouveaux critères d'acceptation.
B. Rédiger de nouveaux tests manuels et automatisés pour cette fonctionnalité et les ajouter à la
suite de tests de régression.
C. Automatiser tous les cas de test de l'itération précédente et les ajouter à la suite de tests de
régression automatisée.
D. Augmenter le degré d'automatisation des tests autour du système pour inclure des conditions
de test plus détaillées.
Quiz Time !
Quelles sont les DEUX raisons pour lesquelles l'automatisation est essentielle dans les projets
agiles ?
i. Pour que les équipes maintiennent ou augmentent leur vélocité.
ii. Pour éviter que l'équipe de test ne s'ennuie avec des tâches manuelles et répétitives.
iii. Pour retester tous les cas de test des itérations précédentes
iv. Éliminer la régression dans le produit due à un taux de modification élevé du code.
v. Pour s'assurer que les changements de code ne cassent pas le build du logiciel
Jeu de réponses :
A. i et iv
B. i et v
C. iii et iv
D. ii et v
fondamentaux Agile
2.3 Rôles et compétences d’un testeur dans

une équipe Agile

2.3.1 Compétences d’un testeur Agile
Les testeurs Agile devraient avoir toutes les compétences mentionnées dans le Syllabus niveau
Fondation, pour rappel :
 compétences relationnelles pour être capable de communiquer efficacement sur les défauts
et les défaillances
 connaissance des principales techniques de test boîte noire, boîte blanche et basées sur
l’expérience
 compétences métier pour la conception et l’exécution de tests fonctionnels
 compétences techniques pour la conception et l’exécution de tests boîte blanche
 ainsi que d’éventuelles compétences spécifiques selon les types de test non-
fonctionnels requis (performance, utilisabilité, sécurité…)
En plus de ces compétences, un testeur dans une équipe Agile devrait être compétent en
automatisation des tests, développement piloté par les tests (TDD), développement piloté par
les tests d’acceptation (ATDD).
Compétences relationnelles
 Être positif et orienté solution avec les membres de l’équipe et les parties prenantes
 Afficher un esprit critique, être orienté qualité, être sceptiques au sujet du produit
 Acquérir activement de l’information des parties prenantes (plutôt que de se fier entièrement
aux spécifications écrites)
 Evaluer précisément et reporter les résultats, l’avancement des tests, et la qualité produit
 Travailler efficacement pour définir des User Stories testables, spécialement les critères
d’acceptation, avec les représentants des clients et les parties prenantes
 Collaborer avec l’équipe, travailler en binôme avec les programmeurs et autres membres de
l’équipe
 Répondre au changement rapidement (modifier, ajouter ou améliorer les cas de test)
 Planifier et organiser son propre travail (équipe autoorganisée)
2.3.2 Le Rôle d’un testeur dans une équipe Agile
 Comprendre, implémenter, et mettre à jour la stratégie de test

 Mesurer et reporter la couverture de test au travers de toutes les dimensions de couverture
applicables
 Assurer une utilisation correcte des outils de test
 Configurer, utiliser, et gérer les environnements de test et les données de test
 Reporter les défauts et travailler avec l’équipe pour les résoudre
 Coacher les autres membres de l’équipe sur les aspects pertinents du test
 Assurer que les tâches de test appropriées sont planifiées pendant les planifications de
release et d’itération
 Collaborer activement avec les développeurs, les parties prenantes Métier, et les Product
Owners pour clarifier les exigences, spécialement en termes de testabilité, cohérence, et de
complétude
 Participer proactivement aux rétrospectives d’équipe, suggérer et implémenter des
améliorations
Organisations de test
Dans une équipe Agile, chaque membre de l’équipe est responsable de la qualité produit et
joue un rôle en réalisant des tâches liées aux tests.
Les organisations Agile peuvent rencontrer des risques liés aux organisations de test:
 Les testeurs travaillant très près des développeurs perdent leur mentalité propre de testeur
 Les testeurs deviennent tolérants ou silencieux au sujet du faible niveau des pratiques de
l’équipe en termes de qualité, d’efficacité ou d’efficience
 Les testeurs ne peuvent pas garder le rythme avec des changements qui arrivent dans des
itérations contraintes en délai
Pour mitiger ces risques, les organisations peuvent considérer différentes solutions pour préserver
l’indépendance discutée dans la Section 2.1.5.
Quiz Time !
Dans les projets agiles, les testeurs ont plus besoin de comprendre et de développer des scripts
d'automatisation des tests que dans les projets traditionnels. De ce qui suit, quelles sont les DEUX raisons
pour lesquelles il s'agit d'une compétence nécessaire sur les projets agiles ?
i. Les besoins changent tous les jours et doivent faire l'objet d'un test de régression. Ce changement rapide
nécessite des tests automatisés parce que les tests manuels sont trop lents.
ii. Les tests doivent permettre d'obtenir le plus tôt possible un feedback sur la qualité du produit. Ainsi, tous
les tests d'acceptation devraient être exécutés à chaque itération, idéalement lorsque des modifications sont
apportées. En pratique, cela ne peut être réalisé que par des tests automatisés.
iii. Les pratiques Test-First et d'intégration continue exigent que la suite de tests de régression soit exécutée
chaque fois que le code modifié est mis en configuration. En pratique, cela ne peut être réalisé que par des
tests automatisés.
iv. Les itérations ou sprints sont de longueur fixe. L'équipe doit garantir que tous les tests peuvent être
entièrement exécutés le dernier jour de chaque itération/sprint. En pratique, cela ne peut être réalisé que par
des tests automatisés.
v. Les projets agiles reposent sur des tests unitaires plutôt que sur des tests de systèmes. Comme les tests
unitaires ne peuvent pas être exécutés manuellement, tous les tests doivent être automatisés.
Jeu de réponses :
A. i & iii B. ii & v C. iv & v D. ii et iii
Quiz Time !
Quelles tâches sont généralement attendues d'un testeur sur un projet agile ?
i. décider de l'acceptation des utilisateurs
ii. concevoir, créer et exécuter les tests appropriés
iii. planifier les rapports de défauts pour analyse
iv. automatiser et maintenir les tests
v. améliorer la logique du programme par programmation par paires
Jeu de réponses :
A. i & iii
B. ii & iii
C. ii & iv
D. ii & v
Quiz Time !
Laquelle des tâches suivantes n'est PAS une tâche typique effectuée par le testeur au sein d'une
équipe agile ?
Jeu de réponses :
A. Automatiser les tests et les maintenir.
B. Mentorat et coaching des autres membres de l'équipe
C. Produire et mettre à jour les burndown charts.
D. Participer à des activités d'analyse de code
fondamentaux Agile
Termes à retenir

Termes à retenir
Burndown chart : Un graphique partagé qui représente l'effort réalisé par rapport au
temps dans une itération. Il montre l'état et la tendance de la complétion des tâches de
l'itération. L'axe des X représente généralement les jours du sprint, tandis que l'axe des Y
représente l'effort restant (habituellement soit en heures d'ingénierie optimales, soit en
points).
Élément de configuration : un ensemble de matériels, logiciels (ou les deux), qui fait
partie de la gestion de configuration et est traité comme une entité unitaire dans le
processus de gestion de configuration.
Synonyme : article de configuration
Gestion de configuration : une discipline appliquant une direction et surveillance
technique et administrative pour identifier et documenter les caractéristiques
fonctionnelles et physiques d’un élément de configuration, contrôler les modifications de
ces caractéristiques, enregistrer et informer des modifications et états d’implémentation,
et vérifier la conformité avec des exigences spécifiées.
Termes à retenir
Tests de vérification de Build : Un ensemble de tests automatisés qui valide l'intégrité

de chaque nouveau build et vérifie ses fonctionnalités clés/de base, sa stabilité et sa
testabilité. C'est une pratique de l'industrie lorsqu'une fréquence élevée de versions de
build se produit (par exemple, les projets Agile) et il est exécuté sur chaque nouvelle
version avant que la version soit publiée pour des tests supplémentaires.
Quiz Time !
Le terme "burndown" fait référence auquel des éléments suivants ?
Jeu de réponses :
A. Un tableau indiquant les membres de l'équipe qui travaillent le plus et qui sont susceptibles
d'être stressés.
B. Un tableau montrant l'état d'avancement de chaque user story et la date à laquelle elle sera
probablement terminée
C. Un tableau montrant la quantité de travail restant à faire, par rapport au temps alloué pour
l'itération
D. Un graphique montrant les défauts qui ont été corrigés, et quand les défauts restants sont
susceptibles d'être corrigés.
3. Méthodes, Techniques, et outils pour
les tests Agile
3.1 Méthodes de test Agile

3.1.1 Développement piloté par les tests, Développement piloté par les
tests d’Acceptation et Développement piloté par le Comportement
 TDD : Test-Driven Development : Développement piloté par les tests

 ATDD : Acceptance Test-Driven Development : Développement piloté par les tests
d’acceptation
 BDD : Behavior-Driven Development : Développement piloté par les tests de comportement
Trois techniques complémentaires utilisées dans les équipes Agile pour prendre en charge les
tests des différents niveaux de test.
Chacune de ces techniques décline un des principes fondamentaux du test :
 le bénéfice des tests et des activités de QA au plus tôt dans le cycle de développement
 i.e les tests sont définis avant que le code ne soit écrit.
Développement piloté par les tests (Test Driven Development)
Le développement piloté par les tests (TDD) est utilisé pour développer
le code en étant guidé par des cas de test automatisés.
Processus :
1. Ecrire un cas de test correspondant à une condition de test à vérifier
sur la petite partie de code que l’on veut développer
2. Exécuter le test, qui devrait être en échec, puisque le code n’existe
pas
3. Ecrire le code suffisant pour que le test passe
4. De façon itérative, recommencer les étapes 1 à 3, en vérifiant à
chaque itération que les tests précédents passent toujours
5. Remanier (voir slide suivant) le code après que tous les tests soient
passés, réexécuter les tests pour assurer qu’ils continuent de passer
après le remaniement du code
6. Répéter ce processus pour la petite partie de code suivante, en
exécutant les tests précédents tout autant que les tests ajoutés pour
cette partie
Pourquoi refactorer (remanier) le code ?

Au cours de la vie d'un logiciel, on lui ajoute souvent des fonctions, et on corrige ses bogues.
Ces modifications successives n'améliorent généralement pas la lisibilité du logiciel et ne facilitent
pas sa maintenance ultérieure.
Les techniques de programmation agile, où évolution et mise à disposition se font en quasi-
continu, rendent cette exigence encore plus fondamentale.
Pour toujours conserver un code aussi simple que possible, on :
 s'assure que toute l'information nécessaire est disponible ;
 supprime toute information redondante ou duplication de code ;
 simplifie lorsque c'est possible l'algorithmique des méthodes ;
 limite la complexité de chaque classe ;
 limite le nombre de classes.
Développement piloté par les tests (Test Driven Development)

Les tests écrits en TDD sont principalement de niveau unitaire et focalisés sur le code, bien que
les tests puissent également être écrits au niveau intégration ou système.
Le développeur se focalise sur des résultats attendus clairement définis.
Les tests sont automatisés et sont utilisés en intégration continue jusqu’à la release du produit.
Le développement piloté par les tests a gagné sa popularité par l’Extreme Programming, mais est
également utilisé dans d’autres méthodologies Agile et parfois dans les cycles de vie séquentiels.
Exemple : le compteur de mots
Développement piloté par les tests d’acceptation (Acceptance Test Driven

Development)
Le développement piloté par les tests d’acceptation (ATDD) est une approche collaborative qui
permet à chaque partie prenante de comprendre comment le composant logiciel doit se
comporter et ce dont les développeurs, les testeurs, et les représentants Métier ont besoin pour
assurer ce comportement.
 Les critères d’acceptation sont définis pendant la création des User Story (voir Section
1.2.2).
 Les tests sont réutilisables pour les tests de régression.
Le processus de développement piloté par les tests d’acceptation est expliqué en Section 3.3.2.
Développement piloté par les tests de comportement (Behavior Driven Development)

Le développement piloté par les tests de comportement permet à un développeur de se
concentrer sur le test du code en cours de développement en se focalisant sur le comportement
attendu du logiciel, de façon à rendre les tests plus faciles à comprendre par les autres
membres de l’équipe et les parties prenantes.
Des Frameworks spécifiques de développement piloté par les tests de comportement peuvent
être utilisés pour définir des critères d’acceptation basés sur le format :
Given (Etant donné) / When (quand) / Then (alors):
 Etant donné un contexte initial,
 Quand un évènement intervient,
 Alors cela entraîne des résultats.
A partir de ces exigences, le Framework de développement piloté par le comportement génère
du code (classes de test) qui peut être utilisé par les développeurs pour créer des cas de test.
Le développement piloté par le comportement aide le développeur à collaborer avec les autres
parties prenantes, en incluant les testeurs, pour définir des tests unitaires focalisés sur les
besoins Métier.
3.1.2 La Pyramide des tests
Un système logiciel peut être testé à différents niveaux

(composants ou unitaires, intégration, système, et
acceptation)
La pyramide des tests préconise un nombre important
de tests aux niveaux les plus bas (de la pyramide) et,
plus le développement avance vers les niveaux hauts, plus
le nombre de tests décroit (haut de la pyramide).
Habituellement les tests des niveaux unitaires et
intégration sont automatisés et créés en utilisant des
outils basés sur des API.
Aux niveaux système et acceptation, les tests automatisés
sont créés en utilisant des outils basés sur les IHM.
Le concept de la pyramide des tests est basé sur le
principe de la qualité logicielle et des tests au plus tôt
(i.e., permettant d’éliminer les défauts aussi tôt que
possible dans le cycle de vie).
3.1.3 Quadrants de Test, Niveaux de Test et Types de Test
Les quadrants des tests

permettent de décrire et
localiser les différents types
de test (dynamiques) afin
d’indiquer à toutes les parties
prenantes :
 le niveau de test auxquels ils
sont effectués
Niveau système ou
 leur objectif : Niveau système acceptation utilisateur
Niveau unitaire Niveau système ou
• aider l’équipe à intégrer la acceptation opérationnelle
qualité au plus tôt ou,
• critiquer (vérifier, valider) le
produit
 leur orientation (technologie
ou métier)
 le degré d’automatisation ou
d’utilisation d’outils
3.1.4 Le Rôle d’un Testeur dans une équipe Scrum
Un travail d’équipe
 Agile met en avant l’approche de l’équipe intégrée constituée de développeurs, testeurs, et des
représentants Métier qui travaillent ensemble.
Meilleures pratiques organisationnelles et comportementales des équipes Scrum:
 Transversalité : chacun apporte ses  Transparents : l’avancement est visible sur le
compétences tableau des tâches
 Auto-organisation : avec au moins un testeur  Crédibles : sur l’implémentation et l’exécution
 Co-location de la stratégie de tests, en fournissant des
informations pertinentes aux parties
 Collaboration : au sein de l’équipe et avec les
prenantes
parties prenantes
 Ouverts au feedback notamment via les
 Habilités : les décisions techniques
rétrospectives
concernant la conception et les tests sont
prises par l’équipe  Résistants : capable de répondre aux
changements
 Engagés : le testeur s’engage à tester le
produit dans le (strict) respect des attentes et
besoins du client et des utilisateurs
Le sprint Zéro
Le Sprint zéro est la première itération du projet dans laquelle de nombreuses activités de
préparation ont lieu (voir Section 1.2.5). Le testeur collabore avec l’équipe sur les activités
suivantes durant cette itération :
 Identifier le périmètre du projet (ex: le backlog de produit)
 Créer une architecture initiale du système et des prototypes de haut niveau
 Planifier, acquérir, et installer les outils nécessaires (ex: pour la gestion des tests, la gestion des
défauts, l’automatisation des tests, et l’intégration continue)
 Créer une stratégie de test initiale pour tous les niveaux de test concernant le périmètre des
tests (entre autres sujets): les risques techniques, les types de test (voir Section 3.1.3), et les
objectifs de couverture
 Faire une analyse initiale de risques qualité (voir Section 3.2.1)
 Définir les métriques de test (avancement, qualité)
 Spécifier la définition de “terminé” (DoD) dont les critères de sortie des tests
 Créer le Task Board ou tableau des tâches (voir Section 2.2.1)
Le sprint zéro définit ce que les tests doivent accomplir et comment, tout au long des
sprints.
Intégration
Dans les projets Agile, l’objectif est de délivrer au client de la valeur sur une base continue (de
préférence à chaque sprint).
Pour le permettre, la stratégie d’intégration devrait considérer à la fois la conception et le
test et identifier toutes les dépendances entre fonctionnalités et fonctions sous-jacentes.
Planification des tests

Puisque les tests sont complètement intégrés dans l’équipe Agile, la planification des tests devrait
commencer pendant la session de planification de release et être mise à jour pendant chaque
sprint (voir Section 1.2.5).
La planification de sprint résulte en un ensemble de tâches à mettre dans le tableau des tâches,
où chaque tâche devrait avoir une durée de un à deux jours.
De plus, tout problème de test doit être suivi pour maintenir un flux de tests régulier.
Pratiques de Test Agile

 Travail en binôme : Deux membres de l'équipe (p. ex. un testeur et un développeur, deux
testeurs ou un testeur et un product owner) se réunissent sur un poste de travail pour effectuer
un test ou une autre tâche du sprint.
 Conception incrémentale des tests : Les cas de test et les chartes sont progressivement
construits à partir des user stories et d'autres bases de test, en commençant par des tests
simples et en allant vers des tests plus complexes.
 Mind mapping : Les testeurs peuvent utiliser le mind mapping pour identifier les sessions de
test à effectuer, pour présenter les stratégies de test, et pour décrire les données de test.
Quiz Time !
Lequel des énoncés suivants sur le développement piloté par les tests (TDD) est FAUX ?
Jeu de réponses :
A. TDD est une approche "test first" pour développer des tests automatisés réutilisables.
B. Le cycle TDD est utilisé en continu jusqu’à la release du produit logiciel.
C. Le TDD aide à documenter le code en vue de travaux de maintenance futurs.
D. Le résultat de TDD sont des classes de test utilisées par le développeur pour développer des
cas de test.
Quiz Time !
A quoi le terme 'Pyramide de test' fait-il référence et illustre des situations où ?
Jeu de réponses :
A. La charge de travail de l'équipe augmente d'un sprint à l'autre.
B. La taille du backlog, et donc le nombre de tests, diminue
C. Le nombre de tests unitaires automatisés est plus élevé que le nombre de tests automatisés
pour des niveaux de test plus élevés.
D. Le nombre de tests automatisés en place augmente d'un sprint à l'autre
Quiz Time !
Lequel des éléments suivants démontre une utilisation efficace des quadrants de test ?
Jeu de réponses :
A. Quand il communique des idées de test, le testeur peut se référer au quadrant de test
correspondant, afin que le reste de l'équipe puisse mieux comprendre le but du test.
B. Le testeur peut utiliser les types de tests décrits dans les quadrants de test comme mesure de
couverture, plus il y a de tests couverts dans chaque quadrant, plus la couverture de test est
élevée.
C. L'équipe devrait choisir un certain nombre de tests attendus de chaque quadrant, et le
vérificateur devrait concevoir et exécuter ces tests pour s'assurer que tous les niveaux et types de
tests ont été exécutés.
D. Le testeur peut utiliser les quadrants de test pendant l'analyse des risques ; avec les quadrants
de niveau inférieur représentant un risque moindre pour le client.
Quiz Time !
Compte tenu des user stories suivantes :
"En tant que caissier de banque, je peux facilement naviguer dans le menu et les liens du
système, et trouver l'information que je cherche"
"Pour tous les utilisateurs, le système doit afficher toutes les requêtes en moins de 2 secondes,
90% du temps."
Et les cas de test associés :
TC1 : Connectez-vous en tant que caissier de banque. Saisissez l'ID client. Vérifiez que
l'historique des transactions du client est facile à trouver et que la navigation dans les menus est
intuitive.
TC2 : Connectez-vous en tant que caissier de banque : Saisissez le nom du client. Vérifiez que les
comptes clients sont faciles à trouver et que la navigation dans les menus est intuitive.
TC3 : Simuler le trafic attendu sur le système et valider que le temps d'affichage de l'historique
des transactions client est inférieur à 2 secondes.
De quels DEUX quadrants de test les cas de test ci-dessus feraient partie ?
Jeu de réponses :
A. Q1 & Q2 B. Q2 & Q3 C. Q3 & Q4 D. Q2 & Q4
Quiz Time !
Au début de la 5ème itération d'un projet, une nouvelle exigence a été introduite pour supporter
un nouveau type de navigateur. Le testeur se rend compte que le framework d'automatisation de
test existant et les scripts ne supporteront pas le nouveau type de navigateur. Quelle est la
meilleure ligne de conduite pour le testeur de cette équipe ?
Jeu de réponses :
A. Le testeur doit informer l'équipe qu'il prévoit de travailler des heures supplémentaires au cours
des deux prochains sprints afin de mettre à jour le framework et les scripts existants pour
supporter le nouveau type de navigateur afin de ne pas perturber le plan existant du sprint.
B. Le testeur informera l'équipe du problème. Une analyse de risque est effectuée et l'équipe
décide que des tests de régression doivent être effectués sur le nouveau type de navigateur en
plus des autres navigateurs supportés. Le testeur mettra à jour le plan de sprint en ajoutant des
tâches pour modifier le framework et les scripts pour supporter le nouveau type de navigateur.
C. Le testeur fait quelques recherches et conclut que le risque est faible que de nouveaux défauts
soient introduits dans le nouveau type de navigateur qui n'ont pas déjà été trouvés dans d'autres
navigateurs supportés. Le testeur continue avec le plan de sprint existant et n'apporte aucun
changement au cadre d'automatisation des tests ou aux scripts.
D. Le testeur arrêtera ce qu'il fait, concevra des tests spécifiques pour tester la compatibilité du
nouveau type de navigateur, et communiquera avec l'équipe que tout autre travail de test pour le
sprint devra être reporté à la prochaine itération.
les tests Agile
3.2 Evaluer les risques Qualité et estimer

l’effort de Test

3.2 Evaluer les risques Qualité et estimer l’effort de Test
Un objectif typique de test de tous projets, Agiles ou traditionnels, est de réduire le risque de
problème de qualité Produit à un niveau acceptable avant de faire la release.
Les testeurs dans les projets Agile peuvent utiliser les mêmes types de techniques utilisées sur
les projets traditionnels pour identifier les risques qualité (ou risques Produit), évaluer les
niveaux de risque associés, estimer l’effort requis pour réduire suffisamment ces risques, et alors
mitiger ces risques au travers de la conception, l’implémentation et l’exécution des tests.
Cependant, étant donné les itérations courtes et le taux de changement dans les projets
Agile, quelques adaptations à ces techniques sont requises.
3.2.1 Evaluer les risques de qualité sur les Projets Agile
Rappels
Un de nombreux enjeux dans les tests est la sélection, l’affectation, et la priorisation correcte des
conditions de test.
 Déterminer la quantité appropriée d’effort à allouer de façon à couvrir chaque condition avec
des tests
 Séquencer les tests qui en résultent de façon à optimiser l’efficacité et l’efficience des tests à
faire.
Le risque est la possibilité d’un résultat ou d’un évènement négatif ou non désiré.
Le niveau de risque est déterminé en évaluant la probabilité de l’occurrence du risque et son
impact.
Quand l’effet principal du problème potentiel est sur la qualité du produit, les problèmes
potentiels sont appelés risques qualité ou risques produit.
Quand l’effet principal du problème potentiel concerne le succès du projet, les problèmes
potentiels sont appelés risques projet ou risques de planification.
Exemples de risques qualité ?
Dans les projets Agile, l’analyse des risques qualité se fait à deux moments.
Planification de release :
 Les représentants Métier qui connaissent les fonctionnalités de la release fournissent une vue
générale des risques de haut niveau, et l’équipe complète, incluant le testeur(s), peut participer
à l’identification et l’évaluation des risques.
Planification d’itération :
 L’équipe intégrée identifie et évalue les risques qualité.
 Une itération commence avec la planification d’itération, qui aboutit à l’estimation des tâches
sur le tableau de tâches.
 Ces tâches peuvent être priorisées en partie en se basant sur le niveau de risque qualité
associé à la tâche.
 Les tâches associées avec un risque plus élevé devraient commencer tôt et impliquer le
plus d’effort de test.
Processus (exemple)
1. Rassembler les membres de l’équipe Agile, incluant le(s) testeur(s)
2. Lister tous les éléments du backlog pour l’itération en cours (ex., sur un tableau de tâches)
3. Identifier les risques qualité associés à chaque élément, en considérant toutes les
caractéristiques qualités pertinentes
4. Evaluer chaque risque identifié, ce qui inclut deux activités: catégoriser le risque
(caractéristique qualité concernée) et déterminer son niveau de risque basé sur l’impact et la
probabilité de défaut
5. Déterminer l’intensité du test proportionnellement au niveau de risque
6. Sélectionner le(s) technique(s) de test appropriée(s) pour mitiger chaque risque, en se basant
sur le risque, le niveau de risque, et les caractéristiques qualité pertinentes.
Le testeur ensuite conçoit, implémente, et exécute des tests pour mitiger les risques.
Cela inclut la totalité des caractéristiques, comportements, caractéristiques qualité, et
attributs qui affectent la satisfaction du client, de l’utilisateur, et des parties prenantes.
Rappels
Au cours du projet, l’équipe devrait rester à l’écoute de nouvelles informations qui peuvent
changer l’ensemble des risques et/ou le niveau de risque associé aux risques qualité connus.
Un ajustement périodique de l’analyse du risque produit, qui résulte en ajustements pour les
tests, devrait se faire.
 Identifier les nouveaux risques
 Réévaluer les niveaux de risque existants
 Evaluer la productivité des activités de mitigation des risques.
Les risques Qualité peuvent être également mitigés avant que l’exécution des tests ne
commence.
 Par exemple, si des problèmes avec les User Story sont trouvés pendant l’identification des
risques, l’équipe projet peut revoir en profondeur les User Story comme actions de mitigation
des risques.
3.2.2 Estimer l’effort de test basé sur le contenu et les risques
Planning Poker
Durant la planification de release, l’équipe Agile estime l’effort requis pour traiter la release.
L’estimation concerne également l’effort de test.
Une technique d’estimation commune utilisée dans les projets Agile est le planning Poker, une
technique basée sur le consensus.
 Le Product Owner ou le client lit une User Story aux évaluateurs.
 Chaque évaluateur a un jeu de cartes avec des valeurs similaires à la suite de Fibonacci (EX
0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89…) ou toute autre choix de progression (Ex: XS, S, M, L, XL).
 Les valeurs représentent le nombre de points de Story (story points), de jours d’effort, ou
d’autres unités que l’équipe utilise pour estimer.
 La suite de Fibonacci est recommandée car les nombres de la suite reflètent l’incertitude qui
augmente proportionnellement avec la taille de la story.
 Une estimation haute signifie habituellement que la Story n’est pas bien comprise ou devrait
être divisée en plusieurs Stories plus petites.
 Les évaluateurs discutent de la fonctionnalité, et posent des questions au Product Owner tant
qu’il y en a besoin.
3.2.2 Estimer l’effort de test basé sur le contenu et les risques
Planning Poker (suite)

 Les aspects comme le développement et l’effort de test, la complexité de la Story, et le
périmètre du test jouent un rôle dans l’estimation.
 Donc il est conseillé d’inclure le niveau de risque d’un élément du backlog, en complément
de la priorité spécifiée par le Product Owner avant que la session de planning poker ne soit
initialisée.
 Quand la fonctionnalité a été complètement discutée, chaque évaluateur choisit une carte, sans
révéler son choix, pour représenter son estimation.
 Toutes les cartes sont ensuite révélées en même temps.
 Si tous les évaluateurs sélectionnent la même valeur, cela devient l’estimation.
 Si non, les évaluateurs discutent les différences entre les estimations après quoi la session de
poker est répétée jusqu’à ce qu’un accord soit atteint, soit par consensus, ou en appliquant
des règles (ex: utiliser la valeur médiane ou le score le plus haut) pour limiter le nombre de
sessions.
Ces discussions assurent une estimation fiable de l’effort nécessaire pour réaliser les éléments du
backlog produit requis par le Product Owner et aide à améliorer la connaissance collective de
ce qui doit être fait.
Quiz Time !
Compte tenu des résultats suivants d'une analyse du risque produit effectuée au début d'une itération :
- User story 1 (Performance) : probabilité : élevée, impact : fort
- User story 2 (Sécurité) : probabilité : élevée, impact : fort
- User story 3 (Fonctionnel) : probabilité : moyenne, impact : fort
- User story 4 (Fonctionnel) : probabilité : élevée, impact : moyen
- User story 5 (Compatibilité) : probabilité : basse, impact : faible
- User story 6 (Recouvrabilité) : probabilité : basse, impact : faible
Lequel des DEUX éléments suivants décrit le mieux ce que l'équipe devrait faire avec ces informations ?
Jeu de réponses :
A. Passez à une session de planning poker afin d'estimer l'effort pour les user stories et déterminer ce qui
peut se faire dans l'itération en cours et ce qui doit être ajouté au backlog.
B. Supprimez les user stories 5 et 6 de l'itération en cours et passez à une itération ultérieure.
C. En raison du nombre élevé de risques à impact et probabilité élevés prévus pour cette itération, l'équipe n'a
pas d'autre choix que de prolonger la durée de l'itération de 2 semaines.
D. L'équipe devrait collaborer à la recherche de moyens efficaces d'atténuer les risques d'impact et de
probabilité élevés.
E. L'équipe devrait prévoir de prendre en charge toutes les stories dans le sprint en cours, mais en conservant
les stories à faible risque pour la fin du sprint, et ne tester ces éléments que s'il reste du temps.
Quiz Time !
Compte tenu de la user story suivante : "En tant que président, les données que je télécharge ne
devraient être consultables par aucun autre utilisateur du système."
Au cours de la première session de planning poker, les story points suivants ont été donnés en
fonction du risque, de l'effort, de la complexité et de l'intensité appropriée des tests :
Clients : 5
Développeurs : 5
Testeurs : 20
Quel est le meilleur résultat après cette séance de planification ?
Jeu de réponses :
A. Comme les estimations des clients et des développeurs correspondent, l'équipe peut être
certaine que cette estimation est bonne et qu'elle devrait passer à la prochaine user story.
B. L'équipe devrait débattre pour comprendre pourquoi les testeurs ont estimé que cette user
story représentait beaucoup plus de travail. Un autre tour de planning poker devrait avoir lieu
après cette discussion.
C. Étant donné que le client est propriétaire du système au bout du compte, les estimations du
client doivent être considérées comme correctes en cas de conflit.
D. Les sessions de planning poker doivent se poursuivre jusqu'à ce que tous les story points
estimés correspondent exactement entre les clients, les développeurs et les testeurs.
les tests Agile
3.3 Techniques dans les projets Agile

3.3.1 Critères d’acceptation, adéquation de la couverture, et
autres informations pour les Tests
De nombreuses techniques et niveaux de test qui s’appliquent aux projets traditionnels peuvent
également être appliqués aux projets Agile.
Cependant, pour les projets Agile, il faut considérer des différences dans les techniques de test,
terminologies, et documentation qui devraient être pris en considération.
Base de test sous forme d’exigences
 Les projets Agile précisent les exigences initiales, comme les User Stories, dans un backlog
priorisé en début de projet.
 Les exigences initiales sont courtes et suivent habituellement un format prédéfini (Story Card
voir Section 1.2.2).
 Les exigences non-fonctionnelles, comme l’utilisabilité, la performance, sont également
importantes et peuvent être spécifiées comme des User Stories indépendantes ou liées aux
autres user stories fonctionnelles.
 Les exigences non-fonctionnelles peuvent être catégorisées selon une norme (ex: ISO25000) ou
un standard spécifique.
Autres bases de test
 L’expérience de projets précédents
 Les fonctions existantes, fonctionnalités, et caractéristiques qualité du système
 Le code, l’architecture et la conception
 Les profils utilisateur (contexte, configuration système, et comportement de l’utilisateur)
 L’information sur les défauts de projets existants ou passés
 Une catégorisation des défauts dans une taxonomie des défauts
 Les standards applicables (ex., [DO-178B] pour les logiciels avioniques)
 Les risques Qualité (voir Section 3.2.1)
Critères d’acceptation
Durant chaque itération, les développeurs créent le code qui implémente les fonctions et les
fonctionnalités décrites dans les User Stories, avec les caractéristiques qualité pertinentes, et ce
code est vérifié et validé via les tests d’acceptation.
Pour être testables, les critères d’acceptation doivent adresser les éléments suivants (s’ils sont
pertinents dans le contexte) :
 Comportement Fonctionnel: Le comportement observable de l’extérieur selon les actions
utilisateur comme entrées, sous certaines configurations.
 Caractéristiques Qualité: Comment le système réalise le comportement spécifié. Les
caractéristiques peuvent également être nommées attributs qualité ou exigences non
fonctionnelles.
Les caractéristiques qualités courantes sont la performance, la fiabilité, l’utilisabilité, etc.
 Scénarios (ou cas d’utilisation): Une séquence d’actions entre un acteur externe (souvent
un utilisateur) et le système, de façon à atteindre un but spécifique ou accomplir une tâche
Métier.
Critères d’acceptation (suite des éléments à adresser)
 Règles Métier: Activités qui ne peuvent être réalisées avec le système que sous certaines
conditions définies par des procédures et des contraintes externes (ex., procédures utilisées par
une compagnie d’assurance pour traiter les demandes d’assurance).
 Interfaces externes: Description des connexions entre le système à développer et le monde
extérieur.
Les interfaces externes peuvent être divisées en différents types (interface utilisateur, interfaces
vers d’autres systèmes, etc.).
 Contraintes: Toute contrainte de conception et d’implémentation qui va restreindre les
options pour le développeur.
Les composants avec logiciel embarqué doivent souvent respecter des contraintes physiques
comme la taille, le poids, et les interfaces de connexion.
 Définitions de données: Les clients peuvent décrire le format, les types de données, les
valeurs autorisées, et les valeurs par défaut pour une donnée attribut d’une structure complexe
de données Métier (ex., le code postal d’une adresse postale).
Autres informations
En plus des User Stories et de leurs critères d’acceptation associés, d’autres informations sont
pertinentes pour le testeur :
 Comment le système est supposé fonctionner et être utilisé
 Les interfaces systèmes qui peuvent être utilisées/accédées pour tester le système
 Si l’aide apportée par les outils actuels est suffisante
 Si le testeur a suffisamment de connaissances et de compétences pour réaliser les tests
Les testeurs vont souvent découvrir un besoin d’informations supplémentaires (ex: La couverture
de code) au travers des itérations et devraient travailler collaborativement avec le reste de
l’équipe Agile pour obtenir cette information.
La pertinence de ces informations joue un rôle pour savoir si une activité particulière peut être
considérée comme terminée.
Ce concept de définition de “terminé” (DoD) est critique dans les projets Agile, et s’applique de
différentes façons comme cela est discuté dans les sous-sections suivantes.
DoD Niveaux de test
Chaque niveau de test a sa propre définition de “terminé”. Par exemple,
 Tests unitaires
• % de couverture des décisions
• % d’Analyse Statique du code effectué et pas de dette technique connue et inacceptable restante
• % de tests unitaires automatisés
 Tests d’intégration
• % d’interfaces entre les composants testées
• % de tests d’intégration automatisés
 Tests système
• % d’exigences testées, par criticité
• % de risques Qualité couverts, par niveau de risque
• % de tests de bout en bout effectués
• % de tests de régression automatisés
DoD User Stories
La définition de “Terminé” pour les User Story peut être déterminée par les critères suivants :
 Les User Stories sélectionnées pour l’itération ont été revues, comprises par l’équipe, et ont des
critères d’acceptation détaillés et testables
 Les tâches nécessaires pour implémenter et tester les User Story sélectionnées ont été
identifiées et estimées par l’équipe
 Les tests d’acceptation des User Stories sont passés et OK
DoD Features (fonctionnalités, caractéristiques)
La définition de “Terminé” des fonctionnalités, qui peuvent être décomposées en de multiples User
Stories ou EPIC peut inclure:
 Toutes les User Story constituantes, avec des critères d’acceptation, sont définies et approuvées
par le client
 La conception est terminée, sans dette technique inacceptable connue
 Le codage est terminé, sans dette technique inacceptable connue ni refactoring non fini
 Les tests unitaires ont été réalisés et ont atteint le niveau défini de couverture
 Les tests d’Intégration et les tests systèmes pour la feature ont été réalisés en accord avec les
critères de couverture définis
 Aucun défaut majeur ne reste à corriger
 La documentation fonctionnelle est complète, ce qui peut inclure les notes de release, les
manuels utilisateurs, et les fonctions d’aide en ligne
DoD Itération
 La définition de “Terminé” pour l'itération peut inclure ce qui suit :
 Toutes les user stories de l'itération ont passé leurs tests d'acceptation ou ont été replacées
dans le backlog produit
 Tout défaut non critique qui ne peut être corrigé dans les limites de l'itération a été rajouté au
backlog produit et priorisé.
 Intégration de toutes les fonctionnalités pour l'itération terminée et testée
 Documentation écrite, revue et approuvée
A ce stade, le logiciel est potentiellement livrable parce que l'itération a été achevée avec succès,
mais toutes les itérations n'aboutissent pas à une déploiement.
DoD Release
La définition de “Terminé” pour une release, qui peut être divisée en de multiples itérations peut
inclure:
 Couverture
• Tous les éléments de base des tests pertinents pour tous les contenus de la release ont été couverts par
des tests avec l’intensité convenue
 Qualité
• L’intensité des défauts (Ex: combien de défauts sont trouvés par jour ou par transaction),
• La densité de défauts (Ex: le nombre de défauts trouvés comparé au nombre de User Story, l’effort, et/ou
aux attributs Qualité), et le nombre estimé de défauts potentiellement restant étant dans des
limites acceptables,
• Les conséquences des défauts non corrigés sont compris et acceptables en termes de priorité et de
sévérité,
• Les niveaux de risques résiduels associés avec chaque risque qualité identifié sont compris et acceptables.
DoD Release (suite)
 Délai
• Si la date de livraison prédéterminée est atteinte, décider de mettre en production ou pas en fonction des
considérations Métier.
 Coûts
• Les coûts estimés du cycle de vie devraient être utilisés pour calculer le retour sur investissement du
système délivré (i.e., les coûts calculés du développement et de la maintenance devraient être
considérablement plus bas que le total du bénéfice espéré avec le produit).
• La part la plus importante des coûts du cycle de vie provient souvent de la maintenance une fois le
produit releasé, du fait du nombre de défauts laissés en production.
3.3.2 Appliquer le Développement piloté par les tests
d’acceptation (ATDD)
Le développement piloté par les tests d’acceptation est une approche « test first ».
Les cas de test sont créés avant d’implémenter la User Story.
Les cas de test sont créés par l’équipe Agile incluant les développeurs, les testeurs, et les
représentants Métier et peuvent être manuels ou automatisés.
Etape 1 : atelier de spécification
 Chaque User Story est analysée, discutée et écrite par les développeurs, testeurs, et
représentants Métier.
 Toute incomplétude, ambigüité, ou erreur dans la User Story est corrigée durant ce processus.
Etape 2 : création des tests
 Cela peut être fait par l’ensemble de l’équipe ou individuellement par le testeur. Dans
tous les cas, une personne indépendante comme un représentant Métier valide les
tests. Les tests sont des exemples qui décrivent les caractéristiques des User Story (les
deux termes sont utilisés)
 Ces exemples (à commencer par des exemples basiques et des questions ouvertes) vont aider
l’équipe à implémenter correctement la User Story.
3.3.2 Appliquer le Développement piloté par les tests
d’acceptation (ATDD)
En général, les premiers tests sont les tests des chemins positifs (cas passants) sans
exception ou condition d’erreur, comprenant la séquence d’activités exécutée telle que souhaitée.
Une fois les chemins positifs testés, l’équipe devrait également
 écrire des tests des chemins négatifs et
 couvrir des attributs non-fonctionnels (ex: performance, utilisabilité).
Afin que chaque partie prenante soit capable de les comprendre, les tests sont exprimés en
langage naturel et décrivent :
 les préconditions
 les données d’entrées
 les résultats associés attendus.
Les exemples doivent couvrir toutes les caractéristiques de la User Story et ne pas rajouter des
éléments à la Story.
 Pas d’exemple décrivant un aspect de la User Story non documenté dans la Story elle-
même.
 Chaque caractéristique de User Story n’est décrite que par un seul exemple.
3.3.3 Conception des tests boîte noire Fonctionnels et Non-
Fonctionnels
Dans les tests Agile, de nombreux tests sont créés par les testeurs en parallèle des activités de
programmation.
Tout comme les développeurs programment en se basant sur les User Story et les critères
d’acceptation, les testeurs créent les tests sur cette même base. (Certains tests, comme les
tests exploratoires et d’autres tests basés sur l’expérience, sont créés ultérieurement, pendant
l’exécution des tests, comme expliqué dans la Section 3.3.4).
Les testeurs peuvent appliquer les techniques de conception des tests boîte noire
traditionnelles, comme les partitions d’équivalence, l’analyse des valeurs limites, les tables de
décision, et les tests de transition d’état pour créer ces tests.
Les exigences non-fonctionnelles peuvent être documentées comme des User Stories
indépendantes ou à l’intérieur de user stories fonctionnelles.
Pour rappel, les techniques de conception boîte noire peuvent également être utilisées pour créer
des tests pour des caractéristiques non-fonctionnelles.
3.3.4 Les tests exploratoires et les tests Agile
Les tests exploratoires sont importants en Agile, en raison des limites de temps disponibles
pour l’analyse des tests et le niveau limité de détails dans les User Story.
De façon à obtenir les meilleurs résultats, les tests exploratoires devraient être combinés
avec
 d’autres techniques basées sur l’expérience faisant partie de la stratégie de test réactive,
 ou d’autres stratégies de test comme
• les tests analytiques basés sur les risques,
• les tests analytiques basés sur les exigences,
• les tests basés sur les modèles,
• et les tests de non régression.
Les stratégies de test et les stratégies de test combinées sont discutées dans le syllabus niveau
fondation.
Tests exploratoires (rappel)

Dans les tests exploratoires, la conception des tests et l’exécution des tests se font au même
moment, guidés par une charte de test préparée.
Une charte de test fournit les conditions de test à couvrir pendant une session limitée dans le
temps.
Pendant les tests exploratoires, les résultats des tests les plus récents guident les suivants.
Cette conception dynamique ou réactive des tests n’exclut pas d’utiliser les techniques boite
blanche et boite noire.
Une charte de tests peut inclure les éléments suivant:
 Acteur: Utilisateur attendu du système
 Sujet: Le thème de la charte incluant quel objectif particulier l’acteur veut réaliser, par exemple
les conditions de test
 Setup: Ce qui doit être mis en place pour commencer l’exécution des tests
 Priorité: Importance relative de la charte, basée sur la priorité des User Story associées ou du
niveau de risque
 Référence: Spécifications (Ex: User Story), risques, ou autres sources d’information
 Data: Tous les data nécessaires pour prendre en charge la charte
 Activités: Une liste d’idées de ce que l’acteur peut vouloir faire avec le système (Ex: “Log sur
le système comme “super utilisateur”) et ce qu’il serait intéressant de tester (à la fois les tests
positifs et négatifs)
 Notes d’oracle: Comment évaluer le produit pour déterminer des résultats corrects (Ex pour
capturer ce qui survient sur l’écran et le comparer à ce qui est écrit dans le manuel utilisateur)
 Variations: Actions alternatives et évaluations pour compléter les idées décrites derrière les
activités.
Pour gérer les tests exploratoires, une méthode appelée gestion par des sessions de test peut
être utilisée.
Une session est définie comme un période ininterrompue de test qui peut prendre de 60 à 120
minutes.
Les sessions de test incluent les éléments suivants:
 Session d’enquête (pour apprendre comment il fonctionne)
 Session d’analyse (évaluation de la fonctionnalité ou des caractéristiques)
 Profondeur de couverture (cas exotiques, scenarios, interactions)
La qualité des tests dépend de la capacité du testeur à poser les questions pertinentes sur
ce qu’il teste :
 Qu’est ce qui est le plus important à découvrir concernant le système?
 De quelle façon le système peut-il tomber en échec ?
 Qu’est ce qui se passe si.....?
 Qu’est ce qui se passera quand.....?
 Est-ce que les besoins utilisateur, exigences, et souhaits sont satisfaits ?
 Est-ce qu’il est possible d’installer le système (et de le supprimer si nécessaire) dans tous les
scénarios de mise à jour supportés?
Durant l’exécution des tests, le testeur utilise sa créativité, son intuition, ses facultés
cognitives et ses compétences des testeurs pour trouver des défauts possibles dans le
produit.
Les testeurs ont également besoin d’avoir une bonne connaissance et une bonne
compréhension du logiciel en test, du domaine Métier, de comment le logiciel est utilisé, et de
comment déterminer quand le système tombe en échec.
Un ensemble d’heuristiques peuvent être appliquées lors des tests.
Une heuristique peut guider le testeur sur comment réaliser les tests et évaluer les résultats.
Les exemples incluent:
 Les limites
 CRUD : Créer (Create), Lire (Read), Mettre à jour (Update), Effacer (Delete))
 Les variations de configuration
 Les interruptions (ex., se déconnecter, éteindre, ou rebooter)
Il est important que le testeur documente le processus autant que possible:
 Couverture de Test : Quelles données d’entrée ont été utilisées, combien a été couvert, et
combien reste à tester
 Notes d’évaluation : observations, stabilité du système, défauts trouvés, compléments de
tests proposés pour l’étape suivante en fonction des observations et toute autre liste d’idées.
 Listes de Risques/Stratégie : Quels risques ont été couverts et quels risques parmi les plus
importants restent à couvrir, est-ce que la stratégie initiale a été suivie, est-ce qu’elle a besoin
de changements
 Points en suspens, questions, et anomalies : tout comportement non attendu, toutes
question concernant l’efficacité de l’approche, toute doute au sujet des idées/tentatives de test,
environnements de test, données de test, non compréhension de la fonction, du script de test
ou du système en test
 Comportement observé : enregistrer les preuves/traces du comportement réel du système
(vidéo, captures d’écran, fichiers de données de sortie)
Les outils disponibles (ex: outils de gestion des tests, outils de gestion des tâches, le tableau des
tâches), doivent être utilisés de façon à ce qu’il soit facile aux parties prenantes de comprendre le
statut en cours pour tous les tests qui ont été réalisés.
Quiz Time !
Une équipe agile est affectée à un projet de mise à jour d'un dispositif médical existant vers de
nouvelles technologies. Depuis la dernière version du dispositif médical existant, une nouvelle
version de la norme relative aux dispositifs médicaux a été publiée. L'accès des utilisateurs à
l'appareil est en train de changer et sera documenté dans des user stories.
Sur la base de ces informations, et en plus des user stories, lequel des éléments suivants
fournirait le mieux des informations pertinentes à l'appui de vos activités de test ?
i. Version mise à jour du document de normes pour le système médical.

ii. Défauts existants ou zones de défauts typiques dans le système existant.
iii. Les cas de test et résultats de tests d'accès des utilisateurs obsolètes pour les applications
existantes.
iv. Mesures de performance pour les applications existantes.
v. Défauts constatés lors d'autres projets de conversion similaires pour des dispositifs médicaux.
Jeu de réponses :
A. i, ii, iii, iv B. ii, iv, v C. i, ii, v D. Toutes ces réponses
Quiz Time !
Quelle est la MEILLEURE description de l'arrêt des tests (critères de release) dans un projet
agile ?
Jeu de réponses :
A. Tous les cas de test ont été exécutés.
B. La probabilité des défauts restants a été réduite à un niveau acceptable pour le client.
C. La couverture de test obtenue est considérée comme suffisante. La limite de couverture est
justifiée par la complexité de la fonctionnalité incluse, son implémentation, et les risques
encourus
D. L'itération/sprint est terminée
Quiz Time !
Parmi les énoncés suivants, quels sont les DEUX exemples de critères d'acceptation vérifiables
pour les activités liées aux tests ?
Jeu de réponses :
A. Tests basés sur la structure : Des tests Boîte blanche en plus des tests Boîte noire sont utilisés.
B. Tests système : Au moins 80 % des tests de régression fonctionnelle sont automatisés.
C. Tests de sécurité : Une analyse des risques de menace est effectuée sans qu'aucune anomalie
ne soit décelée.
D. Tests de performance : L'application répond dans un délai raisonnable avec 5000 utilisateurs.
E. Tests de compatibilité : L'application fonctionne sur tous les principaux navigateurs.
Quiz Time !
Compte tenu de la user story suivante : "En tant que caissier de banque, j'aimerais pouvoir
visualiser à l'écran toutes les transactions bancaires de mon client, afin de pouvoir répondre à ses
questions.
Lequel des cas suivants peut être considéré comme un cas de test d'acceptation pertinent ?
i. Connectez-vous en tant que caissier de banque, obtenez le solde du compte du client pour tous
les comptes ouverts.
ii. Connectez-vous en tant que caissier de banque, entrez un ID de compte client, obtenez
l'historique de ses transactions à l'écran.
iii. Connectez-vous en tant que caissier de banque, demandez l'ID de compte du client en utilisant
des abréviations de nom, et obtenez l'historique de ses transactions à l'écran.
iv. Connectez-vous en tant que caissier de banque, saisissez un IBAN client (numéro de compte
bancaire international), obtenez l'historique de ses transactions à l'écran.
v. Connectez-vous en tant que banquier, entrez un numéro de compte client, obtenez l'historique
des transactions en moins de 3 secondes à l'écran.
Jeu de réponses :
A. i, ii, iv B. i, iii, iv C. ii, iv, v D. ii, iii, iv
Quiz Time !
Compte tenu de la user story suivante : "Une application en ligne facture les clients pour
l'expédition des articles achetés, en fonction des critères suivants :
- Frais d'expédition standard pour moins de 6 articles
- Les frais d'expédition sont de 5 $ pour 6 à 10 articles.
- La livraison est gratuite pour plus de 10 articles.
Laquelle des techniques suivantes est la meilleure technique de conception de test de boîte noire
pour la user story ?
Jeu de réponses :
A. Tests de transition d'état : Testez les états suivants : navigation, connexion, sélection, achat,
confirmation et sortie.
B. Tables de décision : Tester les conditions suivantes - Utilisateur connecté ; Au moins 1 article
dans le panier ; Achat confirmé ; Financement approuvé ; avec l'action résultante de - Expédier
l'article.
C. Analyse des valeurs limites : Tester les entrées suivantes - 0,5,6,10,11,max.
D. Tests de cas d'utilisation : Acteur=client ; Prérequis = client se connecte, sélectionne et achète
des articles ; Postconditions = les articles sont envoyés.
Quiz Time !
Parmi les énoncés suivants, lesquels sont VRAIS en ce qui concerne les tests exploratoires ?
1. Les tests exploratoires englobent simultanément l'apprentissage, la conception et l'exécution
des tests.
2. Les tests exploratoires sont effectués par les développeurs.
3. Les cas de tests exploratoires devraient être automatisés pour un maximum de bénéfice.
4. Les testeurs exploratoires doivent avoir une connaissance préalable du système testé.
Jeu de réponses :
A. 1 et 4
B. 1 et 2
C. 2 et 4
D. 1 et 3
Quiz Time !
Lequel des énoncés suivants est FAUX en ce qui concerne les tests exploratoires ?
Jeu de réponses :
A. Les tests exploratoires englobent l'apprentissage simultané, la conception et l'exécution des
tests.
B. Les tests exploratoires éliminent le besoin pour les testeurs de préparer des idées de tests
avant l'exécution des tests.
C. Les meilleurs résultats sont obtenus lorsque les tests exploratoires sont combinés à d'autres
stratégies de tests.
D. Les testeurs exploratoires doivent avoir une bonne compréhension du système testé.
les tests Agile
3.4 Outils dans les projets Agile

3.4.1 Outils de gestion des tâches et de suivi
Finalités :
 Enregistrer les Story et les tâches de développement et de test associées, pour assurer que
rien n’est perdu durant un sprint
 Capturer les estimations des membres de l’équipe sur leurs tâches et calculer l’effort requis
pour implémenter une Story, pour rendre efficace une session de planification
 Associer les tâches de développement et les tâches de test à la même story, afin de
fournir une image complète de l'effort de l'équipe nécessaire à sa mise en œuvre
 Agréger les mises à jour des développeurs et des testeurs sur le statut de leurs tâches, fournir
automatiquement un instantané calculé du statut de chaque Story, de l’itération, et de la
release entière
 En fournir une représentation visuelle (via des métriques, graphiques et tableaux de bord),
permettant à toutes les parties prenantes, incluant les membres des équipes distribuées
géographiquement, de vérifier rapidement les statuts
 S’intégrer avec des outils de gestion de configuration, afin d’automatiser les mises à jour
des statuts des tâches en fonction des check-in et des builds
3.4.2 Outils de communication et de partage d’information
Les Wikis permettent à l’équipe de construire et de partager une base de connaissance en
ligne :
 Diagrammes de fonctionnalités Produit, discussions sur les fonctionnalités, diagrammes de
prototypes, photos de discussions sur tableau blanc…
 Outils et/ou techniques pour développer et tester identifiées comme utiles par les autres
membres de l’équipe
 Métriques, graphiques, et tableaux de bord des statuts du produit, particulièrement utiles quand
le wiki est intégré avec d’autres outils comme le serveur de Build et le système de gestion de
tâches
Les messageries instantanées, téléconférences audio, et outils de chat vidéo apportent
les bénéfices suivants :
 Permettre une communication directe en temps réel entre les membres de l’équipe, en
particulier les équipes distribuées
 Impliquer les équipes distribuées dans les stand up meetings
 Réduire les notes de téléphone en utilisant la technologie VOIP, supprimer les contraintes
financières qui pourraient réduire la communication des membres de l’équipe dans des
situations distribuées
Les outils de partages d’écran et de capture fournissent les bénéfices suivants :
 Dans les équipes distribuées, des démonstrations du produit, des revues de code, et même le
travail en binôme peuvent avoir lieu.
 Capturer les démonstrations du produit à la fin de chaque itération, qui peuvent être placées sur
les wikis des équipes
3.4.3&4 Outils de build, de distribution et de gestion de
configuration
3.4.5 Outils de conception, d’implémentation, et d’exécution des
tests
 Outils de conception de test : mind-maps
 Outils de gestion des cas de test : en Agile peut être une partie de l’outil de gestion du cycle
de vie de l’application de l’équipe intégrée ou l’outil de gestion des tâches (Jira/Zephyr ou XRay)
 Outils de préparation et génération des données de test : outils qui génèrent les données
qui peuplent une base de données applicative.
• Ces outils peuvent également aider à redéfinir la structure de la base de données en cas de changement
ou de refactoring. Cela permet une mise à jour rapide des données de test quand des changements
surviennent.
• Certains outils de préparation des données de test utilisent des sources de données de production comme
matière première, et utilisent des scripts pour supprimer ou anonymiser des données sensibles.
• D’autres outils de préparation des données de test peuvent aider en validant des données d’entrées et de
résultats de grandes tailles.
3.4.5 Outils de conception, d’implémentation, et d’exécution des
tests
 Outils de chargement de données de test : L’entrée manuelle de données est souvent
chronophage et facteur d’erreurs, de nombreux outils de génération de données incluent un
composant de chargement de données intégré.
 Outils d’exécution de tests automatisés: Ce sont les outils d’exécution de tests qui sont les
plus en phase avec les tests Agile. Des outils spécifiques sont disponibles sous forme
commerciale ou open source qui supportent les approches « test en premier » comme le TDD
ou l’ATDD
 Outils de tests exploratoires : Les outils qui capturent et enregistrent les activités réalisées
sur une application pendant les sessions de tests exploratoires enregistrent les actions
effectuées et :
• facilitent le cas échéant la reproduction de la défaillance par le développeur
• accélère l’automatisation si le test est finalement inclus dans les suites de tests de régression automatisés
3.4.6 Outils de Cloud Computing et de virtualisation
La virtualisation permet à une simple ressource physique (serveur) d’opérer comme de

nombreuses ressources plus petites et séparées.
Quand des machines virtuelles ou des instances de cloud sont utilisées, les équipes ont un plus
grand nombre de serveurs disponibles pour eux pour le développement et les tests. Cela peut
aider à supprimer les délais associés avec l’attente de serveurs physiques.
Provisionner un nouveau serveur ou en restaurer un est plus efficace grâce aux capacités de
snapshot intégrées dans la plupart des outils de virtualisation.
 Faire un snapshot des serveurs au moment où une défaillance est détectée permet aux testeurs
de partager ce snapshot avec les développeurs pour investiguer les défaillances.
Quiz Time !
Lequel des éléments suivants est l'un des objectifs d'un outil de gestion du cycle de vie des
applications (ALM) sur un projet agile ?
Jeu de réponses :
A. Un outil ALM permet aux équipes de constituer une base de connaissances sur les outils et les
techniques pour activités de développement et de test
B. Un outil ALM fournit une réponse rapide sur la qualité de construction et des détails sur les
changements de code.
C. Un outil ALM fournit une visibilité sur l'état actuel de l'application, en particulier avec des
équipes distribuées
D. Un outil ALM génère et charge d'importants volumes et combinaisons de données à utiliser
pour les tests.
les tests Agile
Termes à retenir

Termes à retenir
Automatisation des tests : utilisation de logiciels pour exécuter ou supporter des

activités de tests, p.ex. gestion des tests, conception des tests, exécution des tests ou
vérification des résultats.
Outil de gestion des tests : Outil d’assistance à la gestion des tests et de contrôle
partiel du processus de test. Il offre souvent de nombreuses fonctionnalités telles que la
gestion du testware, la planification des tests, la traçabilité des résultats, le suivi
d’avancement, la gestion des incidents et le Reporting.
Outil de tests de performances : Outil de test qui génère une charge pour un élément
de test désigné et qui mesure et enregistre sa performance pendant l'exécution du test.
Outil d'exécution des tests : Un outil de test qui exécute des tests par rapport à un
élément de test donné et évalue les résultats par rapport aux résultats attendus et aux
postconditions.
Test piloté par les données : une technique de script qui sauvegarde les entrées de
tests et les résultats attendus dans une table ou un tableur, de façon à ce qu’un simple
script de contrôle puisse exécuter tous les tests de la table. Les tests déterminés par les
données sont souvent utilisés pour assister l’utilisation d'outils de tests automatisés tels
ceux de capture/rejeu.
Termes à retenir
Tests dirigés par mots-clé : une technique de script utilisant des fichiers de données
qui contiennent non seulement des données de test et des résultats attendus, mais aussi
des mots clé liés à l’application à tester. Les mots clé sont interprétés par des scripts de
support spécifiques, appelés par le script de contrôle du test.
Synonyme : Tests dirigés par mots d’actions
And now…
About Sogeti
Sogeti is a leading provider of technology and engineering services. Sogeti delivers
solutions that enable digital transformation and offers cutting-edge expertise in Cloud,
Cybersecurity, Digital Manufacturing, Digital Assurance & Testing, and emerging
technologies. Sogeti combines agility and speed of implementation with strong technology
supplier partnerships, world class methodologies and its global delivery model,
Rightshore®. Sogeti brings together more than 25,000 professionals in 15 countries,
based in over 100 locations in Europe, USA and India. Sogeti is a wholly-owned subsidiary
of Capgemini SE, listed on the Paris Stock Exchange.
Learn more about us at

www.sogeti.com
This message contains information that may be privileged or

confidential and is the property of the Capgemini Group.
Copyright© 2018 Sogeti. All rights reserved.

ISTQB Testeur Agile Niveau Fondation - Cours V1.03

Transféré par

Droits d'auteur :

Formats disponibles

ISTQB Testeur Agile Niveau Fondation - Cours V1.03

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

ISTQB Testeur Agile Niveau Fondation - Cours V1.03

Transféré par

Droits d'auteur :

Formats disponibles

Support de formation

Version 1.03 Novembre 2019

© 2019 Sogeti. All rights reserved. 2

La certification au Niveau Fondation de l’ISTQB® est un prérequis

A l’issue de la formation, les participants sauront :

1.1 Les fondamentaux

© 2019 Sogeti. All rights reserved. 6

Les Individus et leurs interactions

 Le développement Agile est axé sur les individus.

Des logiciels opérationnels

La collaboration avec les clients

 Les changements sont inévitables dans les projets logiciels.

 Impliquer chaque personne qui a les connaissances et les compétences nécessaires

Quels DEUX énoncés sont vrais parmi les suivants ?

1.2 Aspects des approches Agile

© 2019 Sogeti. All rights reserved. 24

Les pratiques courantes des organisations Agile comprennent :

Extreme Programming (introduit par Kent Beck en 2004)

 5 valeurs pour guider le développement

Extreme Programming : Valeurs Nous prendrons chaque engagement

Chacun donne et reçoit le respect Nous ferons ce qui est nécessaire et

“In software development, ‘perfect’ is a verb,

 Opportunité : Les problèmes doivent être considérés comme une opportunité de

 Stories : les fonctionnalités du système sont décrites à l'aide de stories, de brèves

 S'asseoir ensemble : les équipes de développement doivent travailler dans un espace

 Build en 10 minutes : L'objectif du Build en 10 minutes est de construire

“if it hurts, do it more often”

 Conception incrémentale : XP s'oppose à la production d'un design complet dès le

 Scrum divise un projet en courtes itérations (appelées sprints) de longueur fixe

Scrum (contrairement à XP) ne dicte pas de technique de développement spécifique (ex :

Scrum définit trois rôles (≠ des 3 amigos)

Kanban utilise trois instruments principaux :

Le processus d’intégration continue inclut les activités automatisées suivantes:

Contrôle et assurance qualité

La planification de release et d’itération est globale et devrait adresser la planification des

Planification d’itération (1/2)

Planification d’itération (2/2)

Challenges des tests Agile

Lequel des énoncés suivants N'EST PAS un principe de l'intégration continue ?

Laquelle des activités suivantes un testeur effectuerait-il au cours de la planification de la

© 2019 Sogeti. All rights reserved. 70

Automatisation des tests : utilisation de logiciels pour exécuter ou supporter des

2.1 Les différences des tests entre les

© 2019 Sogeti. All rights reserved. 75

Spécificité des tests agiles

Au début du projet, il y a la période de planification de release.

Risk-Based Testing et agilité

• Analyse de • Analyse détaillée

Produits d’activité orientés Métier : les User Stories

Produits du développement : le code et les tests

Considérez les activités suivantes :

2.2 Statuts du test dans les projets Agile

© 2019 Sogeti. All rights reserved. 102

Les changements surviennent rapidement dans les projets Agile.

Dynamique d’amélioration Equipe sous-staffée Mise en tension trop forte de l’équipe

 les taux de succès/échec,  les défauts trouvés et corrigés,

2.3 Rôles et compétences d’un testeur dans

© 2019 Sogeti. All rights reserved. 123

 Comprendre, implémenter, et mettre à jour la stratégie de test