Qu'est-ce que le test agile?
AGILE TESTING 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 au début du projet avec une intégration continue entre le développement et les tests. La méthodologie de test agile n'est pas séquentielle (dans le sens où elle n'est exécutée qu'après la phase de codage) mais continue.
Dans cet article, nous discuterons
- Plan de test Agile.
- Stratégies de tests agiles.
- Le quadrant des tests agiles.
- Défis QA avec le développement logiciel agile.
- Risque d'automatisation dans les processus agiles.
Plan de test agile
Le plan de test Agile comprend des types de tests effectués dans cette itération, tels que les exigences en matière de données de test, l'infrastructure, les 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 écrit et mis à jour pour chaque version. Les plans de test typiques dans Agile incluent
- Portée du test
- Nouvelles fonctionnalités en cours de test
- Niveau ou types de tests basés sur la complexité des fonctionnalités
- Test de charge et de performance
- Considération d'infrastructure
- Plan d'atténuation ou de risques
- Ressourcement
- Livrables et jalons
Stratégies de test agile
Le cycle de vie des tests agiles s'étend sur quatre étapes
(a) Itération 0
Au cours de la première étape ou itération 0, vous effectuez les tâches de configuration initiales. Il comprend l'identification des personnes à tester, l'installation d'outils de test, la planification des ressources (laboratoire de test d'utilisabilité), etc.
a) Établir une analyse de rentabilisation pour le projet
b) Établir les conditions aux limites et la portée du projet
c) Décrivez les principales exigences et les cas d'utilisation qui conduiront aux compromis de conception
d) Décrire une ou plusieurs architectures candidates
e) Identifier le risque
f) Estimation des coûts et préparation d'un avant-projet
(b) Itérations de construction
La deuxième phase de la méthodologie de test agile est les itérations de construction, la majorité des tests se déroulant 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 à partir de XP, Scrum, de la modélisation Agile, des données agiles, etc.
Dans l'itération de construction, l'équipe agile suit la pratique des exigences prioritaires: à 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. Les tests de confirmation se concentrent sur la vérification que le système répond à l'intention des parties prenantes telle que décrite à l'équipe à ce jour, et est effectuée par l'équipe. Alors que le test d'investigation détecte 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 / contrainte et les tests de sécurité.
Encore une fois, pour les tests de confirmation, il existe deux aspects: les tests des développeurs et les 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 Agile sont une combinaison de tests fonctionnels traditionnels et de tests d'acceptation traditionnels alors 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 du développeur vérifient à la fois le code de l'application et le schéma de la base de données.
(c) Fin du jeu 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 comprennent dans cette phase la formation des utilisateurs finaux, des personnes de soutien et des opérationnels. En outre, cela comprend 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 phase de test finale sans aucun obstacle, vous devriez avoir à tester le produit plus rigoureusement pendant les itérations de construction. Pendant la fin du jeu, les testeurs travailleront sur ses histoires de défauts.
(d) Production
Après la phase de sortie, le produit passera à la phase de production.
Les quadrants de test Agile
Les quadrants de test agile séparent l'ensemble du processus en quatre quadrants et aident à comprendre comment les tests agiles sont effectués.
a) Quadrant Agile I - La qualité du code interne est le principal objectif de ce quadrant, et il se compose de cas de test qui sont axés sur la technologie et sont mis en œuvre pour soutenir l'équipe, il comprend
1. Tests unitaires
2. tests des composants
b) Agile Quadrant II - Il contient des cas de test axés sur l'entreprise et mis en œuvre pour soutenir l'équipe. Ce quadrant se concentre sur les exigences. Le type de test effectué dans cette phase est
1. Test d'exemples de scénarios et de flux de travail possibles
2. Test de l'expérience utilisateur tels que les prototypes
3. Test de paires
c) Quadrant Agile III - Ce quadrant fournit une rétroaction 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 d'examens d'itérations sont effectuées, ce qui renforce la confiance dans le produit. Le type de test effectué dans ce quadrant est
1. Test d'utilisabilité
2. Essais exploratoires
3. Associez les tests avec les clients
4. Tests collaboratifs
5. Test d'acceptation par les utilisateurs
d) Quadrant Agile IV - Ce quadrant se concentre sur les exigences non fonctionnelles telles que la performance, la sécurité, la stabilité, etc. Avec l'aide de ce quadrant, l'application est faite pour fournir les qualités non fonctionnelles et la valeur attendue.
1. Tests non fonctionnels tels que les tests de résistance et de performance
2. Tests de sécurité concernant l' authentification et le piratage
3. Essais d'infrastructure
4. Test de migration des données
5. Test d'évolutivité
6. Test de charge
Défis QA avec le développement logiciel agile
a) Les risques d'erreur sont plus agiles, car la documentation est moins prioritaire, ce qui met finalement plus de pression sur l'équipe d'assurance qualité
b) De nouvelles fonctionnalités sont introduites rapidement, ce qui réduit le temps disponible pour les équipes de test pour déterminer si les dernières fonctionnalités sont conformes aux exigences et si elles répondent vraiment aux affaires
c) Les testeurs sont souvent tenus de jouer un rôle de semi-développeur
d) Les cycles d'exécution des tests sont fortement compressés
e) Très moins de temps pour préparer le plan de test
f) Pour les tests de régression, ils auront un timing minimal
g) Changement de leur rôle de gardien de la qualité à celui de partenaire de qualité
h) Les changements d'exigences et les mises à jour sont inhérents à une méthode agile, devenant le plus grand défi pour l'assurance qualité
Risque d'automatisation dans les processus agiles
- L'interface utilisateur automatisée offre un niveau de confiance élevé, mais elles sont lentes à exécuter, fragiles à entretenir et coûteuses à construire. L'automatisation peut ne pas améliorer de manière significative la productivité des tests à moins que les testeurs ne sachent comment tester
- Les tests non fiables sont une préoccupation majeure dans les tests automatisés. La correction des tests qui échouent et la résolution des problèmes liés aux tests fragiles doivent ê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 peuvent donc entraîner l'échec des tests.
- Les tests automatisés ne remplacent pas un test manuel exploratoire. Pour obtenir la qualité attendue du produit, un mélange de types de tests et de niveaux 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 des cas de test 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
- Une configuration de test et des procédures de démontage sont généralement manquées pendant l'automatisation des tests, tandis que l'exécution de tests manuels, une configuration de test et des procédures de démontage semblent transparentes
- Les mesures de productivité telles qu'un certain nombre de cas de test créés ou exécutés par jour peuvent être terriblement trompeuses et pourraient 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 sont à court de problèmes importants à résoudre et se transforment donc en problèmes sans importance.
Conclusion
La méthodologie agile des tests logiciels implique des tests le plus tôt possible dans le cycle de vie du développement logiciel. Il exige une forte implication des clients et un code de test dès qu'il est disponible. Le code doit être suffisamment stable pour être soumis aux tests du 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 !!!