Modèle d'exemple de stratégie de test agile



Stratégie de test agile

Dans un environnement agile, où nous travaillons en sprints courts ou en itérations, chaque sprint est concentré sur seulement quelques exigences ou user stories, il est donc naturel que la documentation ne soit pas aussi complète, en termes de nombre et de contenu.

Le but du document de stratégie de test agile est de répertorier les meilleures pratiques et une forme de structure que les équipes peuvent suivre. Rappelez-vous, agile ne veut pas dire non structuré.

Ici, nous examinons un exemple de stratégie de test Agile et ce qu'il faut inclure dans le document.


Une stratégie de test a généralement un énoncé de mission qui pourrait être lié aux buts et objectifs commerciaux plus larges.

Un énoncé de mission typique pourrait être:


Pour fournir en permanence des logiciels fonctionnels qui répondent aux exigences du client _ au moyen de _Fournir un retour rapide _et _ de la prévention des défauts, plutôt que de la détection des défauts.

Supporté par:


  • Aucun code ne peut être écrit pour une histoire jusqu'à ce que nous définissions d'abord ses critères / tests d'acceptation

  • Une histoire peut ne pas être considérée comme terminée tant que tous ses tests d'acceptation n'ont pas réussi

Dans le document de stratégie de test Agile, j'inclurais également un rappel à tous sur l'assurance qualité


  • L'assurance qualité est un ensemble d'activités visant à garantir que les produits répondent aux exigences des clients de manière systématique et fiable.



  • Dans SCRUM (agile) QA est la responsabilité de chacun, pas seulement des testeurs. L'assurance qualité est l'ensemble des activités que nous faisons pour garantir une qualité correcte lors du développement de nouveaux produits.



Niveaux de test

Test unitaire

POURQUOI: Pour s'assurer que le code est développé correctement

QUI: Développeurs / Architectes techniques


QUELLE: Tout nouveau code + refactorisation du code hérité ainsi que les tests unitaires Javascript

LORSQUE: Dès qu'un nouveau code est écrit

OÙ: Local Dev + CI (partie de la construction)

COMMENT: Automatisé, Junit, TestNG, PHPUnit




Test API / Service

POURQUOI: Pour assurer la communication entre les composants fonctionnent

QUI: Développeurs / Architectes techniques

QUELLE: Nouveaux services Web, composants, contrôleurs, etc.

LORSQUE: Dès qu'une nouvelle API est développée et prête


OÙ: Local Dev + CI (partie de la construction)

COMMENT: Automatisé, interface utilisateur de savon, client de repos



Test d'acceptation

POURQUOI: Pour s'assurer que les attentes du client sont satisfaites

QUI: Développeur / SDET / QA manuel

QUELLE: Vérification des tests d'acceptation sur les stories, vérification des fonctionnalités

LORSQUE: Lorsque la fonction est prête et l'unité testée

OÙ:  CI / Test Environment

COMMENT: Automatisé (concombre)



Test du système / Test de régression / UAT

POURQUOI: Pour s'assurer que l'ensemble du système fonctionne une fois intégré

QUI: SDET / Manual QA / Business Analyst / Product Owner

QUELLE: Test de scénario, flux d'utilisateurs et parcours utilisateur typiques, tests de performances et de sécurité

LORSQUE: Lorsque le test d'acceptation est terminé

OÙ: Environnement de mise en scène

COMMENT: Tests exploratoires automatisés (Webdriver)



Backlog produit

La cause la plus courante d'échec du développement logiciel est due à des exigences peu claires et à une interprétation différente des exigences par les différents membres de l'équipe.

Les user stories doivent être simples, concises et sans ambiguïté. À titre indicatif, il est préférable de suivre le modèle INVEST pour rédiger des user stories.

Une bonne user story devrait être:

je ndépendant (de tous les autres)

N égoïste (pas un contrat spécifique pour les fonctionnalités)

V utilisable (ou verticale )

EST stimulable (à une bonne approximation)

S centre commercial (de manière à s'insérer dans une itération)

T estable (en principe, même s'il n'y a pas encore de test pour cela)

Le format suivant doit être utilisé pour écrire des user stories

As a [role] I want [feature] So that [benefit]

Il est important de ne pas oublier la partie «Bénéfice», car chacun doit être conscient de la valeur qu'il ajoute en développant l'histoire.

Critères d'acceptation

Chacune des User stories doit contenir des critères d'acceptation. C'est peut-être l'élément le plus important qui encourage la communication avec les différents membres de l'équipe.

Les critères d'acceptation doivent être écrits en même temps que la user story est créée et doivent être intégrés dans le corps de l'histoire. Tous les critères d'acceptation doivent pouvoir être testés.

Chaque critère d'acceptation doit comporter un certain nombre de tests d'acceptation présentés sous forme de scénarios écrits au format Gherkin, par ex.

Scenario 1: Title Given [context] And [some more context]... When  [event] Then  [outcome] And [another outcome]...

Ateliers d'histoire / Planification de sprint

Dans chaque atelier d'histoire, tout le monde dans l'équipe apprend les détails des histoires afin que les développeurs et le contrôle qualité connaissent la portée du travail. Tout le monde devrait avoir la même compréhension de ce qu'est l'histoire.

Les développeurs doivent avoir une bonne compréhension des détails techniques impliqués dans la livraison de l'histoire, et le contrôle qualité doit savoir comment l'histoire sera testée et s'il existe des obstacles pour tester les histoires.

Prévention des défauts

Dans les ateliers d'histoire, PO, BA, Dev et QA doivent être impliqués.

Les scénarios (valides, invalides et limites) doivent être pris en compte (l'assurance qualité peut ajouter une valeur considérable ici en pensant de manière abstraite à l'histoire) et écrits dans des fichiers de fonctionnalités.

Il est important de noter que ce sont les scénarios (plus que toute autre chose) qui révéleront des défauts lors du test du produit, donc plus d'efforts et de temps consacrés à cette activité, les meilleurs résultats à la fin.

Étant donné que la majorité des défauts sont dus à des exigences peu claires et vagues, cette activité aidera également à empêcher la mise en œuvre d'un comportement incorrect, car tout le monde devrait avoir la même compréhension de l'histoire.

De même, dans les réunions de planification de sprint, les estimations données pour une histoire devraient également inclure l'effort de test et pas seulement l'effort de codage. L'assurance qualité (manuelle et automatisée) doit également être présente dans les réunions de planification de sprint pour fournir une estimation pour tester l'histoire.



Développement

Lorsque le développement commence, le nouveau code de production et / ou la modification du code hérité doivent être soutenus par tests unitaires écrits par les développeurs et évalué par des pairs par un autre développeur ou un SDET qualifié.

Toute validation dans le référentiel de code doit déclencher une exécution des tests unitaires à partir du serveur CI. Cela fournit un mécanisme de rétroaction rapide à l'équipe de développement.

Les tests unitaires garantissent que le système fonctionne au niveau technique et qu'il n'y a pas d'erreurs dans la logique.



Test des développeurs

En tant que développeur, agissez comme si vous n’aviez aucun contrôle qualité au sein de l’équipe ou de l’organisation. Il est vrai que les AQ ont un état d'esprit différent, mais vous devriez tester au mieux de vos capacités.

Vous pensez gagner du temps en passant rapidement à l'histoire suivante, mais en réalité, lorsqu'un défaut est trouvé et signalé, il faut plus de temps pour corriger le problème que de passer quelques minutes à s'assurer que la fonctionnalité fonctionne bien.

Tout nouveau code et / ou refactorisation du code hérité doit avoir des tests unitaires appropriés qui feront partie du test de régression unitaire.



Tests d'acceptation automatisés et tests non fonctionnels

Les tests d'acceptation automatisés comprennent des tests d'intégration et des tests de service et des tests d'interface utilisateur qui visent à prouver que le logiciel fonctionne à un niveau fonctionnel et qu'il répond aux exigences et spécifications de l'utilisateur.

Les tests d'acceptation automatisés sont généralement rédigés en langage Gherkin et exécutés à l'aide d'un outil BDD tel que le concombre.

Rappelles toi : Tous les tests n'ont pas besoin d'être automatisés!

Étant donné que ces tests nécessitent généralement une communication via HTTP, ils doivent être exécutés sur une application déployée, plutôt que dans le cadre de la génération.

Tests non fonctionnels tels que les tests de performance et de sécurité sont aussi importants que les tests fonctionnels, ils doivent donc être exécutés à chaque déploiement.

Les tests de performances doivent vérifier les métriques de performances à chaque déploiement pour garantir l'absence de dégradation des performances.

Les tests de sécurité doivent rechercher les vulnérabilités de sécurité de base dérivées de OWASP

Il est essentiel qu'il s'agisse d'un processus entièrement automatisé avec très peu de maintenance pour tirer le meilleur parti des déploiements automatisés. Cela signifie qu'il ne doit pas y avoir d'échecs de test intermittents, de problèmes de script de test et d'environnement cassé.

Les échecs ne doivent être dus qu'à des défauts de code authentiques plutôt qu'à des problèmes de script.Par conséquent, tout test défaillant qui n'est pas dû à de véritables échecs doit être corrigé immédiatement ou supprimé du pack d'automatisation, pour pouvoir obtenir des résultats cohérents.



Les tests de régression

Ne m'attendant pas à trouver de nombreux défauts. Leur objectif est uniquement de fournir des commentaires indiquant que nous n'avons pas interrompu les fonctionnalités principales. Il devrait y avoir très peu de tests de régression manuels.

Pack de fumée - Ne devrait pas durer plus de 15 minutes

Ce pack ne contient que des fonctionnalités de haut niveau pour s'assurer que l'application est suffisamment stable pour un développement ou des tests ultérieurs.

Par exemple, pour un site Web de commerce électronique, les tests inclus dans ce pack peuvent être:

  • Recherche de produit,
  • Évaluation du produit
  • Acheter un article
  • Création de compte / Connexion au compte

Pack de régression complet - ne devrait pas durer plus d'une heure

Ce pack contient la suite complète de tests de régression et contient tout le reste qui n'est pas inclus dans le pack de fumée.

Ici, l'objectif est d'obtenir un retour rapide avec un plus grand nombre de tests. Si la rétroaction prend plus d'une heure, elle n'est pas rapide. Réduisez le nombre de tests en utilisant une technique de test par paires, créez des packs de tests basés sur le risque ou exécutez les tests en parallèle.



UAT et tests exploratoires

Il n'y a aucune raison pour laquelle l'UAT et les tests exploratoires ne peuvent pas s'exécuter en parallèle avec les tests d'acceptation automatisés. Après tout, ce sont des activités différentes et visent à trouver des problèmes différents. Le but d'UAT est de s'assurer que les fonctionnalités développées ont un sens commercial et sont utiles aux clients.

PO (Product Owner) doit exécuter des tests d'acceptation par l'utilisateur ou des tests d'acceptation commerciale pour confirmer que le produit construit correspond à ce qui était attendu et qu'il répond aux attentes de l'utilisateur.

Les tests exploratoires doivent se concentrer sur les scénarios utilisateur et trouver des bogues que l'automatisation manque. Les tests exploratoires ne doivent pas trouver de bogues triviaux, mais plutôt des problèmes subtils.



Critères terminés

Une fois que toutes les activités ci-dessus sont terminées et qu'aucun problème n'a été trouvé, l'histoire est Fait!

Voici quelques lignes directrices sur ce qui peut être inclus dans un document de stratégie de test Agile. Évidemment, cela doit être adapté aux besoins de votre organisation, mais nous espérons que ce modèle vous aidera à créer votre propre document de stratégie de test Agile.