Qu’est-ce que les tests agiles ? Processus et cycle de vie

Qu'est-ce que le test agile?

Test agile est une pratique de test qui suit les règles et principes du développement logiciel agile. Contrairement à la méthode Waterfall, les tests agiles peuvent commencer dès le début du projet avec une intégration continue entre le développement et les tests. La méthodologie des tests agiles n'est pas séquentielle (dans le sens où elle est exécutée uniquement après la phase de codage) mais continue.

Principes des tests agiles

Voici les principes essentiels des tests agiles :

• Dans ce modèle de test Agile, le logiciel fonctionnel est la principale mesure des progrès.
• Le meilleur résultat peut être obtenu par les équipes auto-organisées.
• Fournir des logiciels précieux de manière précoce et continue est notre priorité absolue.
• Les développeurs de logiciels doivent agir pour se rassembler quotidiennement tout au long du projet.
• Améliorer l’agilité grâce à une amélioration technique continue et une bonne conception.
• Agile Testing garantit que le produit final répond aux attentes de l'entreprise en fournissant un feedback continu.
• Dans le processus de test Agile, nous devons exécuter le processus de test pendant la mise en œuvre, ce qui réduit le temps de développement.
• Le processus de test en Agile doit fonctionner à un rythme de développement cohérent
• Proposez des réflexions régulières sur la manière de devenir plus efficace.
• Les meilleures architectures, exigences et conceptions émergent d’équipes auto-organisées.
• Chaque fois que l’équipe se réunit, elle revoit et ajuste son comportement afin de devenir plus efficace.
• La conversation en face-à-face avec l'équipe de développement est la méthode la plus efficace et la plus efficiente pour transmettre des informations au sein de l'équipe.

Les tests agiles comprennent divers principes qui nous aident à augmenter la productivité du logiciel.

Cycle de vie des tests agiles

Le cycle de vie des tests agiles se déroule en cinq phases différentes, comme nous pouvons le voir dans l'image suivante :

Voici les étapes de test du processus Agile :

Phase 1 : Évaluation d’impact : Dans cette phase initiale, nous recueillons les contributions des parties prenantes et des utilisateurs. Cette phase est également appelée phase de feedback, car elle aide les ingénieurs de test à fixer les objectifs pour le prochain cycle de vie.

Phase 2 : Planification des tests agiles : Il s'agit de la deuxième phase du cycle de vie des tests Agile, au cours de laquelle toutes les parties prenantes se réunissent pour planifier le calendrier du processus de test et les livrables.

Phase 3 : Préparation à la publication : À ce stade, nous examinons les fonctionnalités qui ont été développées/implémentées et sont prêtes à être mises en ligne ou non. À ce stade, il est également décidé lequel doit revenir à la phase de développement précédente.

Phase 4 : Mêlées quotidiennes : Cette étape comprend chaque réunion matinale debout pour se tenir au courant de l'état des tests et fixer l'objectif pour toute la journée.

Phase 5 : Tester l'agilité Revie : La dernière phase du cycle de vie Agile est l'Agilité Revvoir la réunion. Cela implique des réunions hebdomadaires avec les parties prenantes pour évaluer régulièrement les progrès par rapport aux objectifs.

Plan de tests agiles

Plan de tests agiles inclut les types de tests effectués dans cette itération, comme les exigences en matière de données de test, l'infrastructure, environnements de test, et les résultats des tests. Contrairement au modèle en cascade, dans un modèle agile, un plan de test est rédigé et mis à jour pour chaque version. Les plans de test typiques en agile incluent

• Portée des tests
• De nouvelles fonctionnalités en cours de test
• Niveau ou types de tests en fonction de la complexité des fonctionnalités
• Test de charge et de performance
• Considération relative aux infrastructures
• Plan d’atténuation ou des risques
• Le ressourcement
• Livrables et jalons

Stratégies de tests agiles

Le cycle de vie des tests agiles s'étend sur quatre étapes

Iteration 0

Au cours de la première étape ou itération 0, vous effectuez les tâches de configuration initiale. Cela comprend l'identification des personnes à tester, l'installation des outils de test, la planification des ressources (laboratoire de tests d'utilisabilité), etc. Les étapes suivantes doivent être réalisées dans l'itération 0.

• Établir un business case pour le projet
• Établir les conditions limites et la portée du projet
• Décrire les exigences clés et les cas d'utilisation qui détermineront les compromis de conception
• Décrire une ou plusieurs architectures candidates
• Identifier le risque
• Estimation des coûts et préparation d'un avant-projet

Itérations de construction

La deuxième phase de la méthodologie de test agile est celle des itérations de construction, la majorité des tests ont lieu au cours de cette phase. Cette phase est observée comme un ensemble d'itérations pour construire un incrément de la solution. Pour ce faire, à chaque itération, l'équipe met en œuvre un hybride de pratiques de XP, Scrum, de modélisation Agile et de données agiles, etc.

Dans l'itération de construction, l'équipe agile suit la pratique des exigences hiérarchisées : à chaque itération, elle prend les exigences les plus essentielles restantes de la pile d'éléments de travail et les met en œuvre.

L'itération de construction est classée en deux : les tests de confirmation et les tests d'investigation. Concentrés de tests de confirmation sur la vérification que le système répond à l'intention des parties prenantes telle que décrite à l'équipe à ce jour et qu'il est exécuté par l'équipe. Tandis que les tests d'investigation détectent le problème que l'équipe de confirmation a ignoré ou ignoré. Dans les tests d'investigation, le testeur détermine les problèmes potentiels sous la forme d'histoires de défauts. Les tests d'investigation traitent de problèmes courants tels que les tests d'intégration, les tests de charge/stress et les tests de sécurité.

Encore une fois, pour les tests de confirmation, il y a deux aspects tests des développeurs et tests d'acceptation agiles. Les deux sont automatisés pour permettre des tests de régression continus tout au long du cycle de vie. Les tests de confirmation sont l’équivalent agile des tests conformes aux spécifications.

Les tests d'acceptation agiles sont une combinaison de tests fonctionnels traditionnels et de tests d'acceptation traditionnels tandis que l'équipe de développement et les parties prenantes le font ensemble. Alors que les tests des développeurs sont un mélange de tests unitaires traditionnels et de tests d'intégration de services traditionnels. Les tests des développeurs vérifient à la fois le code de l'application et le schéma de la base de données.

Sortie de fin de partie ou phase de transition

L’objectif de « Release, End Game » est de déployer avec succès votre système en production. Les activités incluses dans cette phase sont la formation des utilisateurs finaux, des personnes de support et des personnes opérationnelles. Cela comprend également la commercialisation de la version du produit, la sauvegarde et la restauration, la finalisation du système et la documentation utilisateur.

La dernière étape de test de la méthodologie agile comprend les tests complets du système et les tests d'acceptation. Afin de terminer votre étape de test finale sans aucun obstacle, vous devriez devoir tester le produit plus rigoureusement pendant qu'il est en itérations de construction. Pendant la fin du jeu, les testeurs travailleront sur ses histoires de défauts.

Production

Après la phase de lancement, le produit passera à la phase de production.

Les quadrants des tests agiles

Les quadrants des tests agiles séparent l'ensemble du processus en quatre quadrants et aident à comprendre comment les tests agiles sont effectués.

Quadrant Agile I

La qualité du code interne est l'objectif principal de ce quadrant. Il se compose de cas de test axés sur la technologie et mis en œuvre pour soutenir l'équipe.

• Tests unitaires
• Tests de composants

Quadrant Agile II

Il contient des cas de test axés sur l'activité et mis en œuvre pour soutenir l'équipe. Ce quadrant se concentre sur les exigences. Le type de test effectué dans cette phase est

• Test d'exemples de scénarios et de flux de travail possibles
• Tests de l'expérience utilisateur tels que des prototypes
• Test de paire

Quadrant Agile III

Ce quadrant fournit des commentaires aux quadrants un et deux. Les cas de test peuvent être utilisés comme base pour effectuer des tests d'automatisation. Dans ce quadrant, de nombreuses séries de revues itératives sont effectuées, ce qui renforce la confiance dans le produit. Le type de test effectué dans ce quadrant est

• Tests d'utilisabilité
• Essais exploratoires
• Tests en binôme avec les clients
• Tests collaboratifs
• Test d'acceptation des utilisateurs

Quadrant Agile IV

Ce quadrant se concentre sur les exigences non fonctionnelles telles que les performances, la sécurité, la stabilité, etc. Avec l'aide de ce quadrant, l'application est conçue pour fournir les qualités non fonctionnelles et la valeur attendue.

• Tests non fonctionnels tels que les tests de stress et de performances
• Tests de sécurité en ce qui concerne protocoles d'authentification et piratage
• Tests d'infrastructures
• Tests de migration de données
• Test d'évolutivité
• Test de charge

Défis d’assurance qualité avec le développement de logiciels agiles

• Les risques d'erreur sont plus élevés en mode agile, car la documentation est moins prioritaire, ce qui finit par mettre plus de pression sur l'équipe d'assurance qualité.
• Les nouvelles fonctionnalités sont introduites rapidement, ce qui réduit le temps dont disposent les équipes de test pour déterminer si les dernières fonctionnalités sont conformes aux exigences et si elles répondent réellement aux besoins commerciaux.
• Les testeurs sont souvent amenés à jouer un rôle de semi-développeur
• Les cycles d’exécution des tests sont fortement compressés
• Très moins de temps pour préparer le plan de test
• Pour les tests de régression, ils auront un timing minimal
• Changement de leur rôle de gardien de la qualité à celui de partenaire de la qualité
• Les changements et mises à jour des exigences sont inhérents à une méthode agile, devenant ainsi le plus grand défi pour l'assurance qualité.

Risque d'automatisation dans les processus agiles

• L’interface utilisateur automatisée offre un haut niveau de confiance, mais elle est lente à exécuter, fragile à entretenir et coûteuse à construire. L'automatisation ne peut pas améliorer de manière significative la productivité des tests à moins que les testeurs sachent comment tester
• Les tests peu fiables sont une préoccupation majeure dans les tests automatisés. Corriger les tests défaillants et résoudre les problèmes liés aux tests fragiles devrait être une priorité absolue afin d'éviter les faux positifs.
• Si les tests automatisés sont lancés manuellement plutôt que via CI (intégration continue), il existe un risque qu'ils ne soient pas exécutés régulièrement et puissent donc entraîner l'échec des tests.
• Les tests automatisés ne remplacent pas les tests manuels exploratoires. Pour obtenir la qualité attendue du produit, un mélange de types et de niveaux de tests est nécessaire
• De nombreux outils d'automatisation disponibles dans le commerce offrent des fonctionnalités simples telles que l'automatisation de la capture et de la relecture de cas de tests manuels. Un tel outil encourage les tests via l’interface utilisateur et conduit à des tests intrinsèquement fragiles et difficiles à maintenir. De plus, le stockage des cas de test en dehors du système de contrôle de version crée une complexité inutile.
• Afin de gagner du temps, le plan de test d'automatisation est souvent mal planifié ou non planifié, ce qui entraîne l'échec du test.
• Les procédures de configuration et de démontage des tests sont généralement manquées lors de l'automatisation des tests, tandis que l'exécution de tests manuels, les procédures de configuration et de démontage des tests semblent transparentes.
• Les mesures de productivité telles que le nombre de cas de test créés ou exécutés par jour peuvent être terriblement trompeuses et conduire à un investissement important dans l'exécution de tests inutiles.
• Les membres de l'équipe d'automatisation agile doivent être des consultants efficaces : accessibles, coopératifs et ingénieux, sinon ce système échouera rapidement.
• L'automatisation peut proposer et fournir des solutions de test qui nécessitent trop de maintenance continue par rapport à la valeur fournie
• Les tests automatisés peuvent manquer de l'expertise nécessaire pour concevoir et fournir des solutions efficaces
• Les tests automatisés peuvent être si efficaces qu’ils se retrouvent à court de problèmes importants à résoudre et se tournent ainsi vers des problèmes sans importance.

Conclusion

La méthodologie agile dans les tests logiciels implique de tester le plus tôt possible dans le cycle de vie du développement logiciel. Cela nécessite une forte implication du client et un test du code dès qu'il est disponible. Le code doit être suffisamment stable pour pouvoir être testé sur le système. Des tests de régression approfondis peuvent être effectués pour s'assurer que les bogues sont corrigés et testés. Principalement, la communication entre les équipes fait le succès des tests de modèles agiles !!!