Méthodologie agile dans les tests de logiciels
Qu’est-ce que la méthodologie Agile dans les tests ?
Méthodologie Agile, c'est-à-dire une pratique qui favorise itération continue de développement et de tests tout au long du cycle de vie de développement logiciel du projet. Dans le modèle Agile de test logiciel, les activités de développement et de test sont simultanées, contrairement au modèle Waterfall.

Qu'est-ce que le développement logiciel agile ?
La Développement logiciel agile La méthodologie est l’un des processus les plus simples et les plus efficaces pour transformer une vision d’un besoin commercial en solutions logicielles. Agile est un terme utilisé pour décrire les approches de développement logiciel qui font appel à une planification continue, à l'apprentissage, à l'amélioration, à la collaboration en équipe, au développement évolutif et à une livraison précoce. Cela encourage des réponses flexibles au changement.
Le développement logiciel agile met l'accent sur quatre valeurs fondamentales.
- Interactions individuelles et d'équipe sur les processus et les outils
- Logiciel de travail sur une documentation complète
- Collaboration client plutôt que négociation de contrat
- Répondre au changement au sujet d'un plan
Modèle Agile vs modèle en cascade
Les modèles Agile et Waterfall sont deux méthodes différentes pour le processus de développement logiciel. Bien qu’elles diffèrent dans leur approche, les deux méthodes sont parfois utiles, selon les besoins et le type de projet.
Modèle agile | Modèle de cascade |
---|---|
Méthodologie agile dans la définition des tests logiciels : les méthodologies agiles proposent une approche incrémentale et itérative de la conception de logiciels | Modèle en cascade : le développement du logiciel se déroule séquentiellement du point de départ au point final. |
La Processus agile dans les tests logiciels est divisé en modèles individuels sur lesquels les concepteurs travaillent | Le processus de conception n'est pas divisé en modèles individuels |
Le client a des opportunités précoces et fréquentes d'examiner le produit et de prendre des décisions et des modifications au projet. | Le client ne peut voir le produit qu'à la fin du projet |
Le modèle agile lors des tests est considéré comme non structuré par rapport au modèle en cascade | Les modèles en cascade sont plus sécurisés car ils sont tellement orientés vers un plan |
Les petits projets peuvent être mis en œuvre très rapidement. Pour les grands projets, il est difficile d'estimer le temps de développement. | Toutes sortes de projets peuvent être estimés et réalisés. |
L'erreur peut être corrigée au milieu du projet. | Ce n'est qu'à la fin que l'ensemble du produit est testé. Si une erreur d'exigence est trouvée ou si des modifications doivent être apportées, le projet doit recommencer depuis le début. |
Le processus de développement est itératif et le projet est exécuté en itérations courtes (2 à 4) semaines. La planification est très moindre. | Le processus de développement se déroule par étapes, et la phase est bien plus grande qu'une itération. Chaque phase se termine par la description détaillée de la phase suivante. |
La documentation est moins prioritaire que développement de logiciels | La documentation est une priorité absolue et peut même être utilisée pour former le personnel et mettre à niveau le logiciel avec une autre équipe |
Chaque itération a sa propre phase de test. Il permet de mettre en œuvre des tests de régression à chaque fois que de nouvelles fonctions ou logiques sont publiées. | Ce n'est qu'après la phase de développement que la phase de test est exécutée, car certaines parties ne sont pas entièrement fonctionnelles. |
Dans les tests agiles, à la fin d'une itération, les fonctionnalités livrables du produit sont fournies au client. Les nouvelles fonctionnalités sont utilisables juste après expédition. C’est utile lorsque vous avez un bon contact avec les clients. | Toutes les fonctionnalités développées sont livrées en même temps après la longue phase de mise en œuvre. |
Les testeurs et les développeurs travaillent ensemble | Les testeurs travaillent séparément des développeurs |
A la fin de chaque sprint, l'acceptation des utilisateurs est effectuée | L'acceptation de l'utilisateur est effectué à la fin du projet. |
Cela nécessite une communication étroite avec les développeurs et une analyse conjointe des exigences et de la planification. | Le développeur n'implique pas le processus d'exigence et de planification. Habituellement, les délais entre les tests et le codage |
Vérifiez également: - Agile Vs Waterfall : connaître la différence entre les méthodologies
Processus agile
Vérifiez ci-dessous Méthodologie agile processus pour fournir rapidement des systèmes performants.
Il existe divers Méthodes agiles présents dans les tests agiles, et ceux-ci sont répertoriés ci-dessous :
Scrum
SCRUM est une méthode de développement agile qui se concentre spécifiquement sur la façon de gérer les tâches dans un environnement de développement en équipe. Fondamentalement, Scrum est dérivé d'une activité qui se produit lors d'un match de rugby. Scrum croit en l'autonomisation de l'équipe de développement et préconise de travailler en petites équipes (disons 7 à 9 membres). Agile et Scrum se composent de trois rôles, et leurs responsabilités sont expliquées comme suit :
-
Scrum Master
- Scrum Master est responsable de la mise en place de l'équipe, des réunions de sprint et supprime les obstacles à la progression
-
Propriétaire du produit
-
Le Product Owner crée le backlog du produit, priorise le backlog et est responsable de la livraison de la fonctionnalité à chaque itération.
-
-
Équipe Scrum
-
L'équipe gère son propre travail et organise le travail pour terminer le sprint ou le cycle
-
Backlog de produit
Il s'agit d'un référentiel où les exigences sont suivies avec des détails sur le nombre d'exigences (user stories) à remplir pour chaque version. Il doit être maintenu et hiérarchisé par le Product Owner, et il doit être distribué à l'équipe Scrum. L'équipe peut également demander l'ajout, la modification ou la suppression d'une nouvelle exigence.
Pratiques Scrum
Les pratiques sont décrites en détail :
Flux de processus des méthodologies Scrum :
Flux de processus de test Scrum est comme suit:
- Chaque itération d'une mêlée est connue sous le nom de Sprint
- Le backlog de produit est une liste dans laquelle tous les détails sont saisis pour obtenir le produit final.
- Durant chaque Sprint, les meilleures user stories du Product backlog sont sélectionnées et transformées en Sprint arriéré
- L'équipe travaille sur le backlog de sprint défini
- L'équipe vérifie le travail quotidien
- À la fin du sprint, l'équipe fournit les fonctionnalités du produit
Programmation extrême (XP)
La technique de programmation extrême est très utile lorsque les demandes ou les exigences des clients changent constamment ou lorsqu'ils ne sont pas sûrs de la fonctionnalité du système. Il préconise des « versions » fréquentes du produit dans des cycles de développement courts, ce qui améliore intrinsèquement la productivité du système et introduit également un point de contrôle où toutes les exigences du client peuvent être facilement mises en œuvre. Le XP développe des logiciels gardant le client dans la cible.
Les besoins métiers sont rassemblés en termes d’histoires. Toutes ces histoires sont stockées dans un endroit appelé le parking.
Dans ce type de méthodologie, les versions sont basées sur des cycles plus courts appelés itérations d'une durée de 14 jours. Chaque itération comprend des phases telles que le codage, les tests unitaires et les tests système où, à chaque phase, des fonctionnalités mineures ou majeures seront créées dans l'application.
Phases de programmation eXtreme :
Il y a 6 phases disponibles dans la méthode Agile XP, et celles-ci sont expliquées comme suit :
Planification
-
Identification des parties prenantes et des sponsors
-
Exigences en matière d'infrastructures
-
Sécurité informations et collecte connexes
-
Accords de niveau de service et leurs conditions
Analyse
-
Capture d'histoires dans un parking
-
Prioriser les histoires dans le parking
-
Nettoyage des histoires pour estimation
-
Définir l'itération SPAN (Time)
-
Planification des ressources pour les équipes de développement et d'assurance qualité
Design
-
Découpage des tâches
-
Préparation du scénario de test pour chaque tâche
-
Cadre d'automatisation de la régression
Internationaux
-
Codage
-
Exécution de scénarios de tests manuels
-
Génération de rapport de défauts
-
Conversion de cas de tests de régression manuels en automatisation
-
Examen à mi-itération
-
Examen de fin d’itération
Emballage
-
Petites versions
-
Démos et critiques
-
Développer de nouvelles histoires en fonction des besoins
-
Améliorations des processus basées sur les commentaires de révision de fin d'itération
Fermeture
-
Lancement pilote
-
Formation
-
Lancement de la production
-
Garantie SLA
-
Revvoir la stratégie SOA
-
Support de production
Deux storyboards sont disponibles pour suivre le travail au quotidien, et ceux-ci sont répertoriés ci-dessous à titre de référence.
-
Carton d’histoire
-
Il s'agit d'une manière traditionnelle de rassembler toutes les histoires sur un tableau sous forme de notes bâton pour suivre les activités XP quotidiennes. Comme cette activité manuelle demande plus d’efforts et de temps, mieux vaut passer à un formulaire en ligne.
-
-
Storyboard en ligne
-
L'outil en ligne Storyboard peut être utilisé pour stocker les histoires. Plusieurs équipes peuvent l'utiliser à des fins différentes.
-
Méthodologies Crystal
La méthodologie Crystal est basée sur trois concepts
-
Affrètement: Diverses activités impliquées dans cette phase consistent à créer une équipe de développement, à effectuer une analyse de faisabilité préliminaire, à élaborer un plan initial et à affiner la méthodologie de développement.
-
Livraison cyclique : La phase principale de développement consiste en deux ou plusieurs cycles de livraison, au cours desquels le
- L'équipe met à jour et affine le plan de publication
- Implémente un sous-ensemble des exigences via une ou plusieurs itérations d'intégration de tests de programme
- Le produit intégré est livré aux utilisateurs réels
- Revvue du plan du projet et de la méthodologie de développement adoptée
- Emballer: Les activités réalisées au cours de cette phase sont le déploiement dans l'environnement utilisateur, des examens et des réflexions post-déploiement sont effectués.
Méthode de développement logiciel dynamique (DSDM)
DSDM est un Développement rapide d'applications (RAD) du développement de logiciels et fournit un cadre de livraison de projet agile. L’aspect important de DSDM est que les utilisateurs doivent s’impliquer activement et que les équipes ont le pouvoir de prendre des décisions. La livraison fréquente du produit devient l’objectif actif de DSDM. Les techniques utilisées dans DSDM sont
- Heure Boxfaire respecter
- Règles du MoSCoW
- Prototypage
Le projet DSDM se compose de 7 phases
- Avant-projet
- Étude de faisabilité
- Étude commerciale
- Itération du modèle fonctionnel
- Concevoir et construire une itération
- Mise en œuvre
- Post-projet
Développement basé sur les fonctionnalités (FDD)
Cette méthode est axée sur les fonctionnalités de « conception et construction ». Contrairement à d'autres méthodes Agile en génie logiciel, FDD décrit des phases de travail très spécifiques et courtes qui doivent être accomplies séparément par fonctionnalité. Il comprend une présentation du domaine, une inspection de la conception, la promotion de la construction, une inspection du code et une conception. FDD développe des produits en suivant les objectifs
- Modélisation d'objet de domaine
- Développement par fonctionnalité
- Propriété des composants/classes
- Équipes de fonctionnalité
- Des inspections
- Configuration Management
- Constructions régulières
- Visibilité des progrès et des résultats
Développement de logiciels Lean
La méthode de développement logiciel Lean est basée sur le principe de « production juste à temps ». Il vise à accélérer le développement de logiciels et à réduire les coûts. Le développement Lean peut être résumé en sept étapes.
- Éliminer les déchets
- Amplifier l’apprentissage
- Différer l’engagement (décider le plus tard possible)
- Livraison anticipée
- Donner du pouvoir à l'équipe
- Développement Integrity
- Optimiser l'ensemble
Kanban
Kanban est à l'origine un mot japonais qui signifie une carte contenant toutes les informations nécessaires sur le produit à chaque étape de son cheminement jusqu'à son achèvement. Ce cadre ou méthode est assez adopté dans la méthode de test de logiciels, en particulier dans les concepts Agile.
Scrum contre Kanban
Scrum | Kanban |
---|---|
Dans la technique Scrum, les tests doivent être décomposés afin de pouvoir être complétés en un seul sprint. | Aucune taille d'article particulière n'est prescrite |
Prescrit un backlog de produit hiérarchisé | La priorisation est facultative |
L'équipe Scrum s'engage à une quantité de travail particulière pour l'itération | L'engagement est facultatif |
Un burndown chart est prescrit | Aucune taille d'article particulière n'est prescrite |
Entre chaque sprint, un scrum board est réinitialisé | Un tableau Kanban est persistant. Il limite le nombre d'éléments en état de workflow |
Il ne peut pas ajouter d'éléments à l'itération en cours | Il peut ajouter des éléments chaque fois que la capacité est disponible |
En-cours limités indirectement | WIP limité directement |
Itérations temporelles prescrites | Itérations temporelles facultatives |
Vérifiez également: - Kanban contre. Scrum : quelle est la différence ?
Métriques agiles
Les métriques qui peuvent être collectées pour une utilisation efficace d’Agile sont :
-
Facteur de traînée
-
Effort en heures qui ne contribuent pas à l'objectif du sprint
-
Le facteur de traînée peut être amélioré en réduisant le nombre de ressources partagées, réduisant ainsi la quantité de travail non contributif
-
Les nouvelles estimations peuvent être augmentées en pourcentage du facteur de traînée -Nouvelle estimation = (ancienne estimation + facteur de traînée)
-
-
Vitesse
-
Montant du backlog (user stories) converti en fonctionnalités livrables du sprint
-
-
Nombre de tests unitaires ajoutés
-
Intervalle de temps nécessaire pour terminer la construction quotidienne
-
Bugs détectés dans une itération ou dans les itérations précédentes
-
Fuite de défaut de production