Syllabus ISTQB Testeur Agile

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

Un de nombreux enjeux dans les tests est la sélection, l’affectation, et la priorisation correcte des conditions de test. Cela inclut déterminer la quantité appropriée d’effort à allouer de façon à couvrir chaque condition avec des tests, et en séquençant les tests qui en résultent de façon à optimiser l’efficacité et l’efficience des tests à faire. L’identification, l’analyse et les stratégies de mitigation des risques, peuvent être utilisées par les testeurs des équipes Agile pour aider à déterminer un nombre de cas de tests acceptable à exécuter, bien que des contraintes et des variables qui interagissent peuvent requérir des compromis.

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 trouvé en évaluant la probabilité de l’occurrence du risque et de 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.

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
• Planification d’itération: l’équipe intégrée identifie et évalue les risques qualité.

Des exemples de risques qualité pour un système incluent:

• Les calculs incorrects dans des rapports (un risque fonctionnel lié à la précision)
• Des réponses lentes aux entrées utilisateur (un risque non-fonctionnel lié à l’efficience et aux temps de réponse)
• Des difficultés à comprendre les écrans et les champs (un risque non fonctionnel relatif à la capacité d’utilisation et à la capacité de compréhension)

Comme mentionné plus tôt, 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 qualité du risque 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. Les tâches associées avec des risques plus faibles devraient commencer plus tard et impliquer moins d’effort de test.

Un exemple de comment le processus d’analyse des risques qualité dans un projet Agile peut se dérouler pendant la planification d’itération est décrit dans les étapes suivantes:

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 et déterminer son niveau de risque basé sur l’impact et la probabilité de défaut
5. Déterminer la portée du test proportionnellement au niveau de risque
6. Sélectionner le(s) technique(s) de test appropriées) pour mitiger chaque risque, en se basant sur le risque, le niveau de risque, et les caractéristiques qualité

Le testeur conçoit ainsi, 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.

Au travers 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. Les ajustements incluent d’identifier les nouveaux risques, de réévaluer les niveaux de risque existants, et d’évaluer 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.1    Estimer l’effort de test basé sur le contenu et les risques

Durant la planification de release, l’équipe Agile estime l’effort requis pour terminer 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 séquence de Fibonacci (EX 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89…) ou toute autre choix de progression. (Ex: Les tailles de T-shirt allant de extra-petit à extra-large). Les valeurs représentent le nombre de points de Story, de jours d’effort, ou d’autres unités que l’équipe utilise pour estimer. La séquence de Fibonacci est recommandée car les nombres de la séquence reflètent l’incertitude qui augmente proportionnellement avec la taille de l’histoire. Une estimation haute signifie habituellement que la Story n’est pas bien comprise ou devrait être divisée dans de multiples Story plus petites.

Les évaluateurs discutent de la fonctionnalité, et posent des questions au Product Owner tant qu’il y en a besoin. 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 addition à 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.

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.

3.3.1    Critères d’acceptation, adéquation de la couverture, et autres informations pour les Tests

Les projets Agile précisent les exigences initiales, comme les User Story, dans un backlog priorisé en début de projet. Les exigences initiales sont courtes et suivent habituellement un format prédéfini (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 Story uniques ou connectées aux autres user Story fonctionnelles. Les exigences Non-fonctionnelles peuvent suivre un format prédéfini ou standard, comme [ISO25000], ou un standard industriel spécifique.

Les User Story sont utilisées comme des premières bases de test importantes. D’autres bases de test possibles incluent:

• 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., pour les logiciels avioniques)
• Les risques Qualité (voir Section 2.1)

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 Story, 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 quand pertinent :

• Comportement Fonctionnel: Le comportement observable de l’extérieur avec les actions utilisateur comme entrées de ce qui est fait avec 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 communes sont la performance, la fiabilité, la capacité d’utilisation, etc.
• Scénarios (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.
• Règles Métier: Activités qui peuvent seulement être réalisées dans le système sous certaines conditions définies par des procédures externes et des contraintes (ex., Les 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 dans la composition d’une structure complexe de données Métier (ex., le code postal d’un adresse postale).

En plus des User Story et de leurs critères d’acceptation associés, d’autres informations sont pertinentes pour le testeur, incluant:

• 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 nécessaires

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 des informations fait partie de la détermination pour savoir si une activité particulière peut être considérée comme terminée. Ce concept de définition de “terminé” est critique dans les projets Agile, et s’applique de différentes façons comme cela est discuté dans les sous-sections suivantes.

Niveaux de Test

Chaque niveau de test a sa propre définition de “terminé”. La liste suivante donne des exemples qui peuvent être pertinents pour les différents niveaux de test..

• Test unitaires
  • 100% de couverture des décisions quand c’est possible, avec des revues soignées des chemins infaisables
  • Analyses Statiques effectuées sur tout le code
  • Aucun défaut majeur non résolu
  • Pas de dette technique connue et inacceptable restant dans la conception et le code
  • Tout le code, les tests unitaires, et les résultats de tests unitaires revus
  • Tous les tests unitaires automatisés
  • Les caractéristiques importantes sont dans les limites acceptées (ex., performance)
• Tests d’intégration
  • Toutes les exigences fonctionnelles testées, incluant des tests positifs et négatifs, avec le nombre de tests basé sur la taille, la complexité et les risques
  • Toutes les interfaces entre les composants testées
  • Tous les risques Qualité couverts en accord avec la portée des tests
  • Tous les défauts trouvés sont rapportés
  • Pas de défaut majeur non résolu (priorisés en fonction des risques et de l’importance)
  • Tous les tests de régression automatisés, quand c’est possible, avec tous les tests automatisés stockés dans un entrepôt commun
• Tests Systèmes
  • Tests de bout en bout des User Story, des fonctionnalités et des fonctions
  • Profils utilisateurs couverts
  • Les caractéristiques qualité les plus importantes couvertes (Ex: performance, robustesse, sécurité)
  • Tests effectués dans de(s) environnement(s) iso production, incluant tous les matériels et logiciels pour les configurations supportées, dans la mesure du possible
  • Tous les risques qualité couverts en accord avec l’étendue des tests
  • Tous les tests de régression automatisés, quand possible, avec tous les tests automatisés stockés dans le même entrepôt commun
  • Tous les défauts reportés
  • Pas de défauts majeurs non résolus (priorisés en fonction des risques et de l’importance)

User Story

La définition de “Terminé” pour les User Story peut être déterminée par les critères suivant:

• Les User Story sélectionnées pour l’itération sont complètes en accord avec le thème du produit, comprises par l’équipe, et ont des critères d’acceptation détaillés et testables
• Tous les éléments de la User Story sont spécifiés et revus, incluant la réalisation des tests d’acceptation des User Story
• 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

Fonctionnalité

La définition de “Terminé” des fonctionnalités, qui peuvent être décomposées en de multiples User Story 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 complète, sans dette technique connue
• Le code est complet, sans dette technique connue ou de raffinement 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 fonctionnalité 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

Itération

Le niveau suivant de critère concerne l’itération (sprint), dont voici ci-dessous un exemple:

• Toutes les fonctionnalités de l’itération sont prêtes et testées individuellement conformément au niveau de critère fonctionnel
• L’intégration de toutes les fonctionnalités et caractéristiques pour l’itération complétées et testées
• La documentation écrite, revue et approuvée

A ce point, le logiciel est potentiellement livrable car l’itération a été complétée avec succès, mais toutes les itérations ne donnent pas une release comme résultat.

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
  • L’adéquation de la couverture est déterminée par ce qui est nouveau ou changé, sa complexité et taille, et les risques de défaut associés.
• 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 restant étant dans des limites acceptables.
  • Les conséquences des défauts corrigés et résiduels (ex., la sévérité et la priorité) sont compris et acceptables.
  • Les niveaux de risques résiduels associés avec chaque risque qualité identifié sont compris et acceptables.
  • La tendance des défauts et le nombre estimé de défauts restants dans le système

• Temps – Si la date de livraison prédéterminée est atteinte, considérer le fait d’être releasé 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 des ventes espéré du 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 en premier ». 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 [Adzic09] et peuvent être manuels ou automatisés.

La première étape est un atelier de spécification, ou la User Story est analysée, discutée et écrite par les développeurs, testeurs, et représentants Métier. Toute incomplétude, ambiguïté, ou erreur dans la User Story sont corrigées durant ce processus.

La prochaine étape est de créer les 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. Ces exemples vont aider l’équipe à implémenter correctement la User Story. Puisque les exemples et les tests sont les mêmes, ces termes sont souvent interchangeables. Le travail commence avec des exemples basiques et des questions ouvertes.

Typiquement, les premiers tests sont les tests des chemins positifs confirmant le comportement correct 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é). Les tests sont exprimés de façon à ce que chaque partie prenante soit capable de comprendre, contenant des séquences en langage naturel impliquant la précondition nécessaire, et s’il y en a, les données d’entrées et les résultats associés.

Les exemples doivent couvrir toutes les caractéristiques de la User Story et ne pas rajouter des éléments à la Story. Cela signifie qu’il ne devrait pas exister d’exemple qui décrit un aspect de la User Story non documenté dans la Story elle-même. De plus deux exemples ne devraient pas décrire les mêmes caractéristiques de la User Story.

3.3.3    Conception des tests boite 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. Lorsque les développeurs programment en se basant sur les User Story et les critères d’acceptation, les développeurs créent les tests, basés sur les User Story et leurs critères d’acceptation. (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 boite 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.

Par exemple, l’analyse des valeurs limites peut être utilisée pour sélectionner les valeurs de test quand le client est limité en nombre d’élément qui peuvent être sélectionnés pour acheter.

Dans de nombreuses situations, les exigences non-fonctionnelles peuvent être documentées comme des User Stories. Les techniques de conception boite noire (comme l’analyse des valeurs limites) peuvent également être utilisées pour créer des tests pour des caractéristiques non-fonctionnelles. La User Story peut contenir des exigences de performance ou de fiabilité. Par exemple, une exécution donnée ne peut pas excéder une limite de temps ou un nombre d’opérations peut être en échec avant un certain nombre de fois.

Pour plus d’information sur l’utilisation des techniques de conception des tests boite noire, voir le syllabus niveau fondation et le syllabus analyste de test au niveau avancé.

3.3.4    Les tests exploratoires et les tests Agile

Les tests exploratoires sont importants en Agile, dus aux limites de temps disponibles pour l’analyse des tests et le niveau limité des 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 comme faisant partie de la stratégie de test réactive, mélangée avec d’autres stratégies de test comme les tests analytiques basés sur les risques, tests analytiques basés sur les exigences, test basés sur les modèles, et 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.

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. Les mêmes techniques boite blanche et boite noire utilisées pour concevoir les tests préconçus, peuvent être utilisées pour concevoir les tests.

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, base sur la priorité des User Story associées ou du niveau de risqué
• 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, scénarios, interactions)

La qualité des tests dépend de la capacité du testeur à poser les questions pertinentes sur ce qu’il teste. Les exemples incluent les suivants:

• 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 comblés ?
• Est-ce qu’il est possible d’installer les systèmes (et de le supprimer si nécessaire) dans tous les circuits de mise à jour supportés ?

Durant l’exécution des tests, le testeur utilise la créativité, l’intuition, les facultés cognitives et les 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 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 [Hendrickson]. Les exemples incluent:

• Les limites
• CRUD (Créer (Create), Lire(Read), Mettre à jour(Update), Effacer(Delete))
• Variations de configuration
• Interruptions (ex., se déconnecter, éteindre, ou rebooter)

Il est important que le testeur documente le processus autant que possible. Autrement, il serait difficile de revenir en arrière et montrer comment un problème a été découvert. La liste suivante fournit des exemples d’information qui peuvent être utiles pour documenter:

• Couverture de Test: Quelles données d’entrée ont été utilisées, combien a été couvert, et combien reste à tester
• Notes d’évaluation: Les observations durant les tests faisant que le système et les fonctionnalités en test semblent être stables, est-ce que tous les défauts ont été trouvés, qu’est ce qui est planifié à l’étape suivante en accord avec les observations courantes et toute autre liste d’idées.
• Listes de Risques/Stratégie: Quels risques ont été couverts et lesquels restent parmi les plus importants, 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 préoccupation au sujet des idées /tentatives de test, environnements de test, données de test, non compréhensions de la fonction, script de test ou le système en test
• Comportement actuel: enregistrer le comportement réel du système qui a besoin d’être sauvé (vidéo, captures d’écran, fichiers de données de sortie)

L’information enregistrée devrait être capturée et/ou résumée sous la forme d’outils de gestion des statuts (ex: outils de gestion des tests, outils de gestion des tâches, le tableau des tâches), 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.

Les outils décrits dans le Syllabus niveau Fondation sont pertinents et utilisés par les testeurs des équipes Agiles. Tous les outils ne sont pas utilisés de la même façon et certains outils sont plus pertinents pour les projets Agile qu’ils ne le sont dans les projets traditionnels.

Par exemple, alors que les outils de gestion des tests, outils de gestion des exigences, outils de gestion des incidents (outils de suivi des défauts) peuvent être utilisés par les équipes Agiles, des équipes Agile optent pour un outil tout en un (ex: gestion du cycle de vie de l’application ou gestion de tâches) qui fournit des fonctionnalités pertinentes pour le développement Agile, comme les tableaux de tâches, les Burndown Charts, et les User Story. Les outils de gestion de configuration sont importants pour les testeurs des équipes Agile à cause du nombre élevé de tests automatisés à tous les niveaux et le besoin de stocker et de gérer les artéfacts de test automatisés associés.

En plus des outils décrits dans le Syllabus niveau Fondation, les testeurs sur les projets Agile peuvent utiliser également les outils décrits dans les sous-sections suivantes. Ces outils sont utilisés par l’équipe intégrée pour assurer la collaboration d’équipe et le partage d’informations, qui sont des pratiques clés des pratiques Agile.

3.4.1    Outils de gestion des tâches et de suivi

Dans certains cas, les équipes Agile utilisent des tableaux physiques pour les Story et les tâches (ex., tableaux blancs, tableau en liège) pour gérer et suivre les User Story, les tests, et autres tâches au travers de chaque sprint. D’autres équipes utiliseront des applications de gestion du cycle de vie et des logiciels de gestion de tâches, incluant les tableaux de bord électroniques. Ces outils sont utilisés pour ce qui suit:

• Enregistrer les Story et leurs tâches de développement et de test, pour assurer que rien n’est perdu durant un sprint
• Capturer les estimations des membres de l’équipe sur leurs tâches et automatiquement calculer l’effort requis pour implémenter une Story, pour rendre efficace une session de planification
• Les tâches de développement associées et les tâches de test pour une même Story, pour fournir une vue complète de l’effort de l’équipe pour implémenter la Story
• Agréger les mises à jour des développeurs et des testeurs sur le statut de la tâche quand ils finissent leur travail, fournir automatiquement un instantané calculé du statut de chaque Story, de l’itération, et de la release entière
• Fournir une représentation visuelle (via des métriques, graphiques et tableaux de bord) de l’état en cours de chaque User Story, itération, et release, permettant à toutes les parties prenantes, incluant les membres des équipes distribuées géographiquement, de vérifier rapidement les statuts
• Intégrer avec des outils de gestion de configuration, qui peuvent permettre des mises sous contrôle automatisées du code et des Builds, et, dans certains cas, les mises à jour des statuts automatisés des tâches

3.4.2    Outils de communication et de partage d’information

En plus des e-mails, des documents, et de la communication verbale, les équipes Agiles utilisent souvent trois types d’outils additionnels pour la communication et le partage de l’information: wikis, messageries instantanées, et partage d’écran.

Les Wikis permettent à l’équipe de construire et de partager une base de connaissance en ligne concernant des aspects variés du projet, incluant les éléments suivant:

• Diagrammes de fonctionnalités Produit, discussion sur les fonctionnalités, diagrammes de prototypes, photos de discussions sur tableau blanc, et autres informations
• 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, qui sont 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, puisque l’outil peut mettre à jour les statuts du produit automatiquement
• 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 coûts des contraintes 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

Ces outils devraient être utilisés en complément et renforcer, pas remplacer, la communication en face à face dans les Équipe Agiles.

3.4.3    Build de logiciel et outils de distribution

Comme discuté plus tôt dans ce syllabus, les Builds et les déploiements journaliers de logiciels sont une pratique clé dans les équipes Agiles. Cela requiert l’utilisation d’outils d’intégration continue et des outils de distribution.

L’utilisation, les bénéfices, et les risques de ces outils a été décrite plus tôt dans la section 1.2.4.

3.4.4    Outils de gestion de configuration

Dans les équipes Agile, les outils de gestion de configuration peuvent être utilisés pour ne pas seulement stocker le code source et les tests automatisés, mais les tests manuels et les autres produits des tests sont souvent stockés dans le même entrepôt que le code source du produit. Cela donne de la traçabilité sur quelles versions du logiciels ont été testées avec quelles versions particulières des tests, et permettent des changements rapides sans perdre l’historique. Les types principaux de systèmes de contrôle de version incluent les systèmes de contrôle centralisés de sources et les systèmes de contrôle de version distribués. La taille de l’équipe, sa structure sa localisation, et les exigences d’intégration avec d’autres outils détermineront quel système de contrôle de version est le bon pour un projet Agile en particulier.

3.4.5    Outils de conception, d’implémentation, et d’exécution des tests

• Certains outils sont utiles aux testeurs Agile à des points particuliers du processus de test logiciel. Alors que dans leur majorité, ces outils ne sont pas nouveaux ou spécifiques à l’Agile, ils fournissent des capacités importantes étant donné les changements rapides des projets Agile.
• Outils de conception de test: L’utilisation d’outils comme les mind-maps est devenue plus populaire pour concevoir rapidement et définir les tests d’une nouvelle fonctionnalité.
• Outils de gestion des cas de test: Ce type d’outil utilisé 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.
• Données de test, préparation et génération des données: Les outils qui génèrent les données qui peuplent une base de données applicative sont très bénéfiques quand beaucoup de données et de combinaisons de données sont nécessaires pour tester l’application. Ces outils peuvent également aider à redéfinir la structure de la base de données alors que le produit subit des changements pendant un projet Agile et raffine les scripts pour générer les données. 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 les 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.
• Outils de chargement de données de test: Une fois les données générées pour le test, elles ont besoin d’être chargées dans l’application. L’entrée manuelle de données est souvent chronophage et facteur d’erreurs, mais les outils de chargement de données existent pour rendre le processus fiable et efficace. En fait, de nombreux outils de génération de données incluent un composant de chargement de données intégré. Autrement, le chargement en vrac à partir d’un système de gestion de base de données est également possible.
• 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 Des outils spécifiques sont disponibles sous forme commerciale ou open source qui supportent les approches « test en premier », comme le développement piloté par le comportement, le développement piloté par les tests d’acceptation. Ces outils permettent aux testeurs et aux équipes Métier d’exprimer le comportement du système attendu dans des tableaux ou en langage naturel utilisant des mots clé.
• 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 sont bénéfiques pour le testeur et le développeur, puisqu’ils enregistrent les actions prises. Cela est utile quand un défaut est détecté, puisque les actions faites avant la défaillance ont été capturées et peuvent être utilisées pour rapporter le défaut aux développeurs. L’enregistrement des étapes effectuées lors d’une session de tests exploratoires montre un bénéfice quand 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 à annuler 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 à faire un instantané de la plupart des outils de virtualisation. Certains outils de gestion des tests utilisent maintenant les technologies de virtualisation pour faire des instantanés des serveurs au moment où une faute est détectée, ce qui permet aux testeurs de partager l’instantané avec les développeurs pour investiguer les fautes.