Qu’est-ce que les tests agiles ?

Les tests agiles sont une pratique de test logiciel qui suit les principes de méthodologie agile. Contrairement à la méthodologie en cascade, qui pousse les tests à la fin du cycle de vie du développement logiciel , Agile rassemble l’équipe de développement et de test pour construire et expédier des produits de qualité par sprints à un rythme plus rapide. L’agilité crée un environnement qui encourage une collaboration accrue entre les développeurs, les testeurs et les analystes métier pour tester l’application et fournir un retour continu sur la qualité et corriger les défauts dans la même itération.

Le manifeste agile a répertorié des points pour le développement logiciel qui conviennent également aux équipes de test :

• Individus et interactions sur les processus et les outils : les testeurs doivent s’aligner sur le reste de l’équipe de développement, c’est-à-dire les développeurs, les parties prenantes du produit et les utilisateurs finaux. La boucle de rétroaction continue entre ces équipes aidera les testeurs à mieux comprendre le produit en cours de développement/testé et les différentes approches pour améliorer la qualité du produit.
• Un logiciel fonctionnel sur une documentation complète : les testeurs dans l’environnement agile doivent être ouverts pour s’adapter à l’évolution des exigences. Contrairement à Waterfall, où il existe une documentation complète sur les exigences que les testeurs testeront, les testeurs agiles ne suivent pas une documentation stricte. Ils doivent être en communication constante avec le reste de l’équipe et être informés de l’évolution/des nouvelles exigences et définir ensemble les critères d’acceptation.
• Collaboration client sur la négociation de contrat : les testeurs n’ont généralement pas de contact direct avec les clients. Cependant, les principes agiles encouragent les testeurs à comprendre les exigences du point de vue du client et à se concentrer davantage sur celles-ci.
• Répondre au changement plutôt qu’en suivant un plan : Pour être vraiment en mesure de réussir Tests agiles, les testeurs doivent réagir au changement, être prêts à redéfinir leurs priorités pour leurs tests, ce qui permettra respectivement de minimiser les risques et d’atteindre l’objectif.

Il existe deux types de méthodologie agile

1. Mêlée
2. Kanban

La méthodologie Scrum est la méthodologie agile la plus populaire et la plus utilisée. L’équipe Scrum aura

un. Parties prenantes de l’entreprise
b. Propriétaire du produit
c. Maître de mêlée
ré. Développeurs
e. Testeurs
F. Ingénieurs en automatisation

Le cadre Scrum est basé sur l’apprentissage continu et l’amélioration continue. Il adopte une approche itérative et aide les équipes à s’adapter aux exigences changeantes des utilisateurs, à redéfinir les priorités des tests et à minimiser les risques, ce qui se traduit par une amélioration et un apprentissage continus.

Scrum commence par identifier les artefacts. Trois artefacts Scrum courants sont,

une. Carnet de produit
b. Carnet de sprint
c. Objectif de sprint/Terminé/Incréments

Chacun des membres impliqués dans Scrum supervisera ces artefacts et pilotera tout le sprint.

une. Carnet de produit

Le propriétaire du produit tient à jour le backlog du produit, qui est une liste des tâches qui doivent être effectuées par l’équipe. La liste contient une liste d’exigences, de fonctionnalités, de bogues à corriger, etc., qui servira d’entrée pour le Sprint Backlog/Tâches.

b. Planification des sprints

Toute l’équipe dirigée par le scrum master (peut être un développeur/testeur) qui planifie les tâches à effectuer pour le sprint en cours est appelée planification de sprint. Lors de cette réunion, les équipes choisiront les éléments du backlog de produit, appelés backlogs de sprint, sur lesquels elles prévoient de travailler pour le sprint en cours. Après la planification du sprint, chaque membre doit être clair sur les objectifs du sprint et sur la manière de les atteindre.

c. Sprint

Un sprint est une période réelle pendant laquelle les équipes travailleront ensemble et atteindront les objectifs. Bien qu’une période de sprint typique puisse varier entre 1 et 4 semaines, la plupart des équipes préfèrent un sprint de 2 semaines. Tous les événements, de la planification à la livraison, se déroulent en un sprint. Pendant cette période, le responsable du développement et du produit peut discuter de la portée et peut réitérer si nécessaire. Une fois le temps fixé pour un sprint, il doit être cohérent tout au long de la période de développement.

ré. Réunion Scrum quotidienne

Les réunions quotidiennes de mêlée, également appelées stand-up quotidiens, sont des réunions rapides de 15 minutes. L’objectif de cette réunion est de s’assurer que tous les membres de l’équipe sont sur la même page en ce qui concerne les objectifs et de planifier une feuille de route pour les prochaines 24 heures.

e. Revue/Démo

Tous les membres de l’équipe se réunissent à la fin d’un sprint pour un examen ou une démonstration des objectifs du sprint. L’équipe de développement présente les tâches “Terminé/Incrémenté” aux parties prenantes et aux coéquipiers pour examen. Une fois que le propriétaire du produit a donné son feu vert, l’incrément est libéré.

Kanban est une autre pratique agile largement suivie dérivée des industries manufacturières. L’adoption réussie de ce cadre nécessite une communication en temps réel et une transparence au travail. Dans Kanban, les éléments de travail/exigences sont généralement présentés dans un tableau Kanban avec une liste « To Do, Doing, Done ». À tout moment, lorsque le développeur est prêt, il peut extraire les backlogs de la liste de tâches et commencer à travailler dessus.

L’équipe Kanban aura

• Propriétaire du produit
• Développeurs
• Testeurs
• Chef de projet
• Ingénieurs en automatisation

L’équipe aura moins de réunions de planification par rapport à Scrum. Par conséquent, les membres de l’équipe doivent être raisonnablement flexibles et communiquer étroitement. Le tableau Kanban virtuel permet aux membres de l’équipe de suivre le travail en cours pour chaque élément et les détails associés tels que qui est responsable de cette tâche, la description du poste et un calendrier. Il convient mieux aux petites équipes qui travaillent uniquement sur la base de la priorité et non sur des versions fixes et ponctuelles.

Les équipes de test agiles, quelle que soit la méthodologie agile qu’elles suivent, doivent créer un plan de test approprié. Il peut être communiqué aux membres de l’équipe par le biais d’un document ou à l’aide d’une matrice de test. Ce plan décrira les histoires d’utilisateurs ou les critères d’acceptation, les cas de test requis, la portée des tests et les méthodes d’exécution du test, c’est-à-dire manuelles ou automatisées.
Un plan et une gestion de test appropriés aideront les testeurs agiles à améliorer la qualité du produit et à raccourcir les cycles de publication.

1. Développement piloté par les tests (TDD)

TDD, comme son nom l’indique, commence par les tests. Ce type de développement commence par écrire un test unitaire – user story – écrire du code jusqu’à ce que le test réussisse. TDD est applicable pour les tests unitaires et de composants. Il garantit que les fonctionnalités fonctionnent comme prévu. Les autres types de TDD sont le développement piloté par les tests d’acceptation (ATDD) et le développement piloté par le comportement (BDD).

2. Tests exploratoires

Les tests exploratoires ne nécessitent pas de script de test prédéfini. Cela commence par des testeurs suivant leur intuition et teste le fonctionnement du logiciel en imitant les comportements des utilisateurs. Cela aide à découvrir les bogues qui ont échappé aux tests de fonctionnalité ainsi que les bogues potentiels à haut risque qui pourraient casser le logiciel. L’ensemble du processus est enregistré et sauvegardé en tant que test.

3. Tests basés sur la session

Les tests basés sur la session diffèrent très peu des tests exploratoires en termes de processus de test plus structuré. L’objectif de ces tests est tout de même : trouver des bugs critiques qui pourraient casser le logiciel

• Une meilleure compréhension du produit car toutes les équipes travaillent ensemble
• Détection plus précoce des défauts, gain de temps et d’argent
• Rétroaction continue menant à l’amélioration continue de la qualité du produit
• Facile à gérer le logiciel