Test Agile - Scrum

Les défenseurs de Scrum Whole Team Approach, en ce sens que chaque membre de l'équipe doit participer à chaque activité du projet. L'équipe Scrum s'auto-organise et est responsable des livrables du projet. La prise de décision est laissée à l'équipe qui se traduit par des mesures appropriées prises au bon moment sans aucun retard. Cette approche encourage également l'utilisation appropriée des talents de l'équipe au lieu de se limiter à une seule activité. Les testeurs participent également à toutes les activités de projet et de développement en apportant leur expertise dans les tests.

Toute l'équipe travaille ensemble sur la stratégie de test, la planification des tests, la spécification des tests, l'exécution des tests, l'évaluation des tests et le rapport des résultats des tests.

Création de user story collaborative

Les testeurs participent à la création de User Story. Les testeurs apportent leurs idées sur le comportement possible du système. Cela aide le client et / ou l'utilisateur final à comprendre le système dans l'environnement réel et à obtenir ainsi la clarté sur ce qu'ils veulent réellement comme résultat. Cela se traduit par un gel plus rapide des exigences et réduit également la probabilité de modifications ultérieures des exigences.

Les testeurs proposent également les critères d'acceptation pour chaque scénario convenu par le client.

Les testeurs contribuent à la création de user stories testables.

Planification des versions

La planification des versions est effectuée pour l'ensemble du projet. Cependant, le framework Scrum implique une prise de décision itérative car plus d'informations sont obtenues au cours de l'exécution des sprints. Par conséquent, la session de planification de la version au début du projet n'a pas besoin de produire un plan de lancement détaillé pour l'ensemble du projet. Il peut être mis à jour en permanence, à mesure que des informations pertinentes sont disponibles.

Chaque fin de sprint n'a pas besoin d'avoir une version. Une version peut être après un groupe de sprints. Le principal critère d'une version est de fournir une valeur commerciale au client. L'équipe décide de la durée du sprint avec la planification des versions comme entrée.

La planification de la version est la base de l'approche de test et du plan de test pour la publication. Les testeurs estiment l'effort de test et planifient les tests pour la version. Lorsque les plans de version changent, les testeurs doivent gérer les changements, obtenir une base de test adéquate en tenant compte du contexte de publication plus large. Les testeurs fournissent également l'effort de test requis à la fin de tous les sprints.

Planification de sprint

La planification de sprint est effectuée au début de chaque sprint. Le backlog de sprint est créé avec les user stories extraites du backlog de produit pour l'implémentation dans ce sprint particulier.

Les testeurs devraient -

Déterminer la testabilité des user stories sélectionnées pour le sprint
Créer des tests d'acceptation
Définir les niveaux de test
Identifier l'automatisation des tests

Les testeurs mettent à jour le plan de test avec les estimations de l'effort de test et des durées dans le sprint. Cela garantit la fourniture de temps pour les tests requis pendant les sprints temporisés et la responsabilité de l'effort de test.

Analyse des tests

Lorsqu'un sprint commence, alors que les développeurs poursuivent l'analyse de l'histoire pour la conception et l'implémentation, les testeurs effectuent une analyse de test pour les histoires dans le backlog de sprint. Le testeur crée les cas de test requis - des tests manuels et automatisés.

Essai

Tous les membres de l'équipe Scrum doivent participer aux tests.

Les développeurs exécutent les tests unitaires au fur et à mesure qu'ils développent du code pour les user stories. Les tests unitaires sont créés à chaque sprint, avant l'écriture du code. Les cas de test unitaires sont dérivés de spécifications de conception de bas niveau.
Les testeurs exécutent des fonctionnalités fonctionnelles et non fonctionnelles des user stories.
Les testeurs encadrent les autres membres de l'équipe Scrum avec leur expertise dans les tests afin que toute l'équipe ait une responsabilité collective pour la qualité du produit.
À la fin du sprint, le client et / ou les utilisateurs finaux effectuent des tests d'acceptation des utilisateurs et fournissent des commentaires à l'équipe Scrum. Cela constitue une entrée pour le prochain sprint.
Les résultats des tests sont collectés et conservés.

Test d'automatisation

Les tests d'automatisation sont très importants dans les équipes Scrum. Les testeurs consacrent du temps à la création, à l'exécution, à la surveillance et à la maintenance des tests et des résultats automatisés. Comme des changements peuvent survenir à tout moment dans les projets Scrum, les testeurs doivent s'adapter aux tests des fonctionnalités modifiées ainsi qu'aux tests de régression impliqués. Les tests d'automatisation facilitent la gestion des efforts de test associés aux changements. Des tests automatisés à tous les niveaux facilitent la réalisation d'une intégration continue. Les tests automatisés s'exécutent beaucoup plus rapidement que les tests manuels sans effort supplémentaire.

Les tests manuels se concentrent davantage sur les tests exploratoires, la vulnérabilité du produit, la prévision des défauts.

Automatisation des activités de test

L'automatisation des activités de test réduit le fardeau des travaux répétés et entraîne des économies de coûts. Automatiser

Génération de données de test
Chargement des données de test
Générer le déploiement dans l'environnement de test
Gestion de l'environnement de test
Comparaison des sorties de données

Les tests de régression

Dans un sprint, les testeurs testent le code qui est nouveau / modifié dans ce sprint. Cependant, les testeurs doivent également s'assurer que le code développé et testé dans les sprints précédents fonctionne également avec le nouveau code. Par conséquent, les tests de régression ont une importance particulière en mêlée. Les tests de régression automatisés sont exécutés en intégration continue.

Gestion de la configuration

Un système de gestion de configuration qui utilise des frameworks de construction et de test automatisés est utilisé dans les projets Scrum. Cela permet d'exécuter des analyses statiques et des tests unitaires à plusieurs reprises à mesure que le nouveau code est archivé dans le système de gestion de la configuration. Il gère également l'intégration continue du nouveau code avec le système. Les tests de régression automatisés sont exécutés pendant l'intégration continue.

Les cas de test manuels, les tests automatisés, les données de test, les plans de test, la stratégie de test et les autres artefacts de test doivent être contrôlés en version et nécessitent des autorisations d'accès appropriées. Cela peut être accompli en conservant les artefacts de test dans le système de gestion de configuration.

Pratiques de tests agiles

Les testeurs d'une équipe Scrum peuvent suivre les pratiques Agile suivantes -

Pairing- Deux membres de l'équipe s'assoient ensemble et travaillent en collaboration. Les deux personnes peuvent être deux testeurs ou un testeur et un développeur.
Incremental Test Design - Les cas de test sont développés au fur et à mesure que les sprints progressent et que les histoires d'utilisateurs sont ajoutées.

Métriques agiles

Au cours du développement du logiciel, la collecte et l'analyse des mesures aident à améliorer le processus et à atteindre ainsi une meilleure productivité, des livrables de qualité et la satisfaction du client. Dans le développement basé sur Scrum, cela est possible et les testeurs doivent prêter attention aux métriques dont ils ont besoin.

Plusieurs métriques sont suggérées pour le développement Scrum. Les paramètres significatifs sont -

Ratio of Successful Sprints - (Number of successful Sprints / Total number of Sprints) * 100. Un Sprint réussi est celui dans lequel l'équipe pourrait respecter son engagement.
Velocity- La vélocité d'une équipe est basée sur le nombre de Story Points qu'une équipe a gagnés au cours d'un sprint. Les Story Points sont la mesure des User Stories comptées lors de l'estimation.
Focus Factor - (Velocity / Team’s Work Capacity) / 100. Le facteur de focalisation est le pourcentage de l'effort de l'équipe qui aboutit à des histoires finies.
Estimation Accuracy - (Estimated effort / Actual effort) / 100. La précision de l'estimation est la capacité de l'équipe à estimer l'effort avec précision.
Sprint Burndown- Travail (en Story Points ou en heures) qui reste Vs. Travail qui doit rester idéalement (selon l'estimation).
- Si c'est plus, cela signifie que l'équipe a effectué plus de travail qu'elle ne peut en faire.
- Si c'est moins, cela signifie que l'équipe n'a pas estimé avec précision.
Defect Count- Nombre de défauts dans un Sprint. Le nombre de défauts est la quantité de défauts du logiciel par rapport à l'arriéré.
Severity of Defects- Les défauts peuvent être classés comme mineurs, majeurs et critiques selon leur gravité. Les testeurs peuvent définir la catégorisation.

Rétrospectives de sprint

Dans Sprint Retrospectives, tous les membres de l'équipe participeront. Ils partagent -

Les choses qui se sont bien passées
Metrics
La portée des améliorations
Actions à appliquer