Méthodologie agile dans les tests de logiciels

Méthodologie agile

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.

Méthodologie agile
Méthodologie agile

Qu'est-ce que le développement logiciel agile ?

Le 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.

  1. Interactions individuelles et d'équipe sur les processus et les outils
  2. Logiciel de travail sur une documentation complète
  3. Collaboration client plutôt que négociation de contrat
  4. Répondre au changementwing 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.
Le 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.

Modèle de processus agile
Modèle de processus agile

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 :

Méthode Scrum
Méthode Scrum
  • 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 details sur le nombre d'exigences(user stories) à compléter pour chaque release. 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 :

Pratiques Scrum
Pratiques Scrum

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 où tous les details sont saisis pour obtenir le produit final
  • Au cours de chaque Sprint, les principales user stories du Product backlog sont sélectionnées et transformées en Sprint backlog
  • 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.

Programmation extrême
Programmation extrême

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 :

PRÉPRODUCTION

  • 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

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

Conception

  • 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
  • Revoir 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

  1. 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.
  2. Livraison cyclique : La phase principale de développement consiste en deux ou plusieurs cycles de livraison, au cours desquels le
    1. L'équipe met à jour et affine le plan de publication
    2. Implémente un sous-ensemble des exigences via une ou plusieurs itérations d'intégration de tests de programme
    3. Le produit intégré est livré aux utilisateurs réels
    4. Examen du plan du projet et de la méthodologie de développement adoptée
  3. 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

  1. Time Freak Boxing
  2. Règles du MoSCoW
  3. Prototypage

Le projet DSDM se compose de 7 phases

  1. Avant-projet
  2. Étude de faisabilité
  3. Étude commerciale
  4. Itération du modèle fonctionnel
  5. Concevoir et construire une itération
  6. Implémentation
  7. 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 le suivi de la conservation des produitswing choses dans la cible

  1. Modélisation d'objet de domaine
  2. Développement par fonctionnalité
  3. Propriété des composants/classes
  4. Équipes de fonctionnalité
  5. Des inspections
  6. Configuration Management
  7. Constructions régulières
  8. 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.

  1. Éliminer les déchets
  2. Amplifier l’apprentissage
  3. Différer l’engagement (décider le plus tard possible)
  4. Livraison anticipée
  5. Donner du pouvoir à l'équipe
  6. Construire l'intégrité
  7. 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
Time Freakboxitérations ed prescrites Time Freakboxitérations ed 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