Agile Testing Process – Principles, Methods & Advantages

Si vous êtes développeur ou testeur, le mot Agile ne vous est pas étranger. Mais si vous êtes nouveau dans ce domaine et vous demandez ce qu’est le test Agile et ce qu’il signifie en pratique, vous n’aurez plus aucune question après avoir lu cet article.

Qu’est-ce que le test Agile ?

Le test Agile est une partie indissociable de la méthodologie de développement logiciel Agile. En Agile, les tests sont effectués en continu, en parallèle du développement lui-même. Il s’agit d’un effort conjoint des développeurs, des testeurs, des chefs de projet et des clients pour adapter le produit aux besoins du client.

Contrairement à la méthodologie en cascade, où les tests constituent une étape distincte qui intervient après la phase de développement, la méthodologie de test Agile implique que les tests commencent dès le début du projet et progressent main dans la main avec le développement, fournissant un retour continu au processus de développement.

Les testeurs ne sont plus une unité distincte. Ils font partie de l’équipe de développement logiciel Agile et collaborent étroitement avec les développeurs tout au long du cycle de vie du développement logiciel Agile, ce qui permet :

  • De gagner du temps et de l’argent
  • Une documentation moins volumineuse
  • Un retour régulier
  • D’identifier les problèmes en amont

Alors, quelles sont les raisons de choisir ou non le processus Agile ? La meilleure façon de répondre est d’établir une liste des avantages et des inconvénients.

Avantages de la méthodologie Agile

  • Flexibilité
  • Productivité
  • Transparence
  • Haute qualité
  • Adaptation régulière aux circonstances changeantes
  • Plus grande implication et satisfaction du client

Inconvénients de la méthodologie Agile

  • Ne convient pas à tous les projets
  • Difficile à mettre en œuvre lorsque les clients suivent des processus ou méthodes rigides
  • Difficile d’estimer l’effort nécessaire au début du cycle de vie du développement logiciel
  • Le manque d’accent mis sur la conception et la documentation nécessaires
  • Seuls les développeurs expérimentés peuvent prendre les décisions requises pendant le processus de développement

Si vous décidez d’adopter le test Agile, vous devrez également connaître ses principes fondamentaux.

Principes du test Agile

  • Le test n’est pas une phase distincte mais un processus permanent
  • Le test améliore le produit grâce à un retour constant
  • Le test peut impliquer non seulement les testeurs mais aussi les développeurs
  • Le test se déroule selon une liste de contrôle réutilisable, et non selon une documentation détaillée
  • Le test se déroule au sein d’équipes auto-organisées

Tout cela vise à :

  • Accueillir les exigences évolutives, même tardivement dans les tests
  • Livrer un produit logiciel de haute qualité dans un délai court
  • Satisfaire le client par une livraison rapide d’un produit de haute qualité

Mais avant de vous engager dans l’une de ces approches, vous devrez choisir le framework de test Agile qui fonctionnera le mieux au sein de vos processus et de vos méthodes de test. Les plus utilisés sont Scrum et Kanban.

Scrum et Kanban : quelle est la différence ?

Scrum est une approche dans laquelle une équipe universelle de spécialistes travaille sur chaque projet. Elle implique également un product owner et un scrum master :

  • Le product owner relie l’équipe au client et supervise l’évolution du projet.
  • Le scrum master aide le product owner à organiser le processus métier : il anime les réunions générales, résout les problèmes quotidiens, motive l’équipe et veille au respect de l’approche Scrum.

L’approche Scrum divise le flux de travail en sprints égaux. Ce sont des périodes allant d’une semaine à un mois, selon le projet et l’équipe. Une fois le sprint terminé, les tâches achevées sont envoyées en production, les autres sont reportées au sprint suivant.
Les tâches réalisées pendant le sprint ne changent généralement pas : ce qui a été fixé pour mise en œuvre au début du sprint doit être réalisé à tout prix avant la fin du sprint. Les sprints sont très faciles à comparer, ce qui permet de gérer l’efficacité du travail.
L’approche Kanban consiste à équilibrer le travail des différents spécialistes au sein de l’équipe et à éviter les situations où les designers travaillent à plein régime tandis que les développeurs se plaignent du manque de nouvelles tâches.
En Kanban, l’équipe entière est une seule unité. Pas de product owner ni de scrum master ici. Le processus métier n’est pas divisé en sprints universels, mais en étapes d’exécution de tâches spécifiques :

  • À faire
  • Développement
  • Test
  • Déploiement

Le principal indicateur d’efficacité en Kanban est le temps moyen nécessaire pour accomplir une tâche. La tâche passe rapidement : l’équipe travaille de manière productive et harmonieuse. La tâche traîne : il faut réfléchir à quelle étape et pourquoi il y a eu des retards, et déterminer dont le travail doit être optimisé.
Kanban vous offre plus de flexibilité, ce qui se traduit par la fréquence de changement des priorités. Si le développeur livre la tâche terminée et reçoit un retour indiquant qu’elle ne fonctionne pas comme prévu, il reçoit de nouvelles exigences à traiter. Ces nouvelles tâches montent en priorité et le programmeur les traite en premier.
Pour former un sprint en Scrum, les tâches doivent être évaluées en story points ou en heures. Sans une telle évaluation, il sera impossible de former un sprint, car vous devez savoir si vous parviendrez à terminer les tâches dans un délai donné. Une fois ce délai écoulé, vous obtenez les statistiques sur les heures ou story points que l’équipe a pu réaliser pendant le sprint. Cela permet de mesurer la vélocité de l’équipe sur un sprint. Sachant cela, le Scrum master peut prédire où l’équipe se trouvera lors du sprint suivant.
Kanban ne nécessite pas d’évaluation. La notion de « vitesse de travail en équipe » n’existe pas : seul le temps moyen nécessaire pour accomplir une unité de travail est pris en compte.
Ainsi, en Scrum, l’objectif est de terminer le sprint ; en Kanban, c’est de terminer la tâche.
Pour garder le tout en ordre et sous contrôle, Scrum et Kanban utilisent tous deux des tableaux qui visualisent les tâches et l’étape à laquelle elles se trouvent.
Kanban vs Scrum
Les tâches sur les tableaux sont divisées selon le principe :

  • À faire
  • En cours
  • Terminé

La seule différence est que le tableau Scrum divise les tâches en sprints, et toutes les tâches d’un sprint donné doivent être « Terminées » à la fin de ce sprint.
Faisons un récapitulatif maintenant ?
Structure Kanban et Scrum
Pour que vous puissiez voir comment cela fonctionne en pratique, voyons quelques exemples.

Le test Agile chez QAwerk

En tant que société de tests logiciels, nous pouvons illustrer par nos propres exemples l’impact de la méthodologie Agile sur le déroulement d’un projet particulier.

Unfold

Unfold est une application iOS et Android qui permet de créer des stories avec des photos et des vidéos en utilisant différents modèles.
Sur ce projet, le développement est mené côté client. Le travail est organisé de telle sorte que des mises à jour de version sortent en permanence, à la fois sur iOS et Android : modifications mineures, changements de design, ajout de fonctionnalités d’abonnement, ajout de nouvelles collections de modèles, souvent en collaboration avec des stars (Miley Cyrus), des films (The Sun is Also a Star), de grands événements (Billboard Music Awards), des marques de vêtements (Tommy Hilfiger).
Le client ne partage pas avec nous ses plans de développement ni sa documentation. Mais voici ce que le processus de test Agile nous permet de faire dans le cadre de ce projet :

  • Nous sommes toujours prêts à tester la nouvelle version sur tous les types d’appareils dont nous disposons
  • Nous communiquons avec les développeurs, effectuons de fréquentes régressions de bugs qui seront corrigés dans la version actuelle jusqu’à ce qu’elle soit prête à passer en production
  • Nous travaillons également avec les avis des utilisateurs sur les magasins d’applications (Google, Apple) et recueillons les retours des utilisateurs pour reproduire les bugs, ouvrir des rapports et communiquer avec les développeurs
  • Une fois, nous avons travaillé en équipe pendant le week-end pour aider à tester une mise à jour majeure – l’ajout des abonnements à l’application

En conclusion

Quelle que soit la méthodologie de test Agile utilisée, elles permettent toutes deux la détection précoce des bugs, ce qui réduit le coût de leur correction. C’est également une approche centrée sur le client qui permet de fournir un produit de haute qualité dans un délai relativement court.