Pourquoi et comment rédiger une stratégie de test sur un projet Agile ?

Vous découvrirez dans cet article pourquoi nous avons besoin d’une stratégie de test agile de haut niveau servant de ligne directrice aux équipes agiles. Le document de stratégie de test dans la méthode agile a pour objectif de répertorier les meilleures pratiques et représente une forme de structure que les équipes peuvent suivre. Pour rappel, être agile ne signifie pas être non structuré.

Nous vous donnerons ici un exemple de comment rédiger une stratégie de test dans la méthode agile et ce qu’il convient d’inclure dans ce document.

1. Du plan de test à la stratégie de test / stratégie de recette

Dans un environnement agile nous travaillons dans de brefs sprints ou itérations. Chaque sprint ne se concentre que sur quelques exigences ou « user story ». Il est donc évident que la documentation ne soit pas très complète. En raison de contraintes de temps il n’est peut-être pas nécessaire de disposer d’un plan de test exhaustif pour chaque sprint. Pour savoir comment rédiger un bon plan de test vous pouvez consulter cet article. Cependant, une stratégie de test (stratégie de recette) est primordiale pour définir l’ensemble des niveaux de test et leurs critères.

Généralement, une stratégie de test comporte un énoncé de mission qui pourrait être lié aux objectifs commerciaux plus larges.

Exemple d’une stratégie de test et d’une mission typique

Livrer en permanence un logiciel (application) fonctionnel qui répond aux exigences du client, en fournissant un feedback rapide et la prévention des défauts, plutôt que la détection des défauts.

Cette mission pourrait être définie par ce genre de critères :

  • Aucun code ne peut être écrit pour une « user story » jusqu’à ce que nous définissions d’abord ses critères d’acceptation / tests.
  • Une « user story » peut ne pas être considérée complète tant que tous les tests d’acceptation ne sont pas validés (voir DoD, définition of done)

Dans le document sur la stratégie de test agile, il faudrait mettre également un rappel de l’assurance qualité à tout le monde.

  • Selon la norme ISO 9000 l’assurance qualité est un ensemble d’activités destinées à garantir que les produits répondent aux besoins des clients de manière systématique et fiable.
  • Dans la méthode agile SCRUM, le contrôle qualité est la responsabilité de tous, pas seulement des testeurs. Le contrôle qualité concerne toutes les activités que nous réalisons pour garantir une qualité correcte lors du développement de nouveaux produits.

Niveaux de test

Stratégie de test et stratégie de recette

Matrice des tests agiles de Brian Marick

Tests unitaires

Quoi :  Tout nouveau code + refactorisation du code hérité ainsi que des tests unitaires Javascript

Qui :   Développeurs / Architectes techniques

Où :  Dev local + CI (Intégration de contenu) – partie de la construction

Quand :  dès que le nouveau code est écrit

Comment :  outils  de type Automated, Junit, TestNG, PHPUnit

Pourquoi :  Pour s’assurer que le code est développé correctement

Test API / Service

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

Qui :   Développeurs / Architectes technique, voir Test analyst technique

Où :  Dev local + CI (Intégration de contenu) – partie de la construction

Quand :  Dès que la nouvelle API est développée et prête

Comment :  Automated, Soap UI, Rest Client, Soap UI pro …

Pourquoi :  Pour assurer que la communication entre les composants fonctionne

Test d’acceptance

Quoi:  Vérification des tests d’acceptation sur les récits, vérification des caractéristiques

Qui:   Développeur / SDET / mais de préférence un Test Analyst Manuel

Où:  CI / Environnement de test

Quand:  Lorsque la fonctionnalité est prête et que l’unité est testée

Comment:  test manuel ou automatisé

Pourquoi:  s’assurer que les attentes du client sont satisfaites

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

Quoi :  Test de scénario, flux d’utilisateurs et voyages types, tests de performances et de sécurité

Qui :   SDET / Manuel QA / BA / PO

Où :  environnement de transfert

Quand :  une fois le test d’acceptance terminé

Comment :  Tests manuel  automatisés (outils de type Selenium Webdriver, Agilitest, Cloudnetcare, Test Complete, UFT …)

Pourquoi :  Pour que tout le système fonctionne, une fois intégré

2. Le Backlog du produit

La cause la plus fréquente d’échec du développement logiciel est due à des exigences peu claires, et à une différence d’interprétation des exigences par les différents membres de l’équipe.

Les « user story » doivent être simples, concises et sans ambiguïté. En règle générale, il est préférable de suivre le modèle INVEST pour écrire des « user story ».

Les critères d’une bonne « user story » :

Indépendante (de toutes les autres)

Négociable (initialement)

Verticale (valeur)

Estimable (bonne approximation)

Suffisamment petite (afin de s’insérer dans une itération)

Testable (en principe, même s’il n’y a pas encore de test pour)

Le format suivant doit être utilisé pour écrire des « user story »

As a [role]

I want [feature]

So that [benefit]

Il est important de ne pas oublier la partie « bénéfices », car chacun devrait être conscient de la valeur qu’il ajoute en développant l’histoire.

Critères d’acceptation

Chaque « user story » doit contenir des critères d’acceptance. 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’acceptance doivent être écrits lors de la création de la « user story » et doivent être intégrés au corps de l’histoire. Tous les critères d’acceptance doivent être testables.

Chaque critère d’acceptance doit comporter un certain nombre de tests d’acceptance présentés sous forme de scénarios rédigés.

Il est possible d’utiliser l’approche BDD et le langage au format Gherkin, pour faciliter la communication entre les différents acteurs (les 3 amigos : PO/DEV/QA).

Scenario 1 : Title

Given [context]

And [some more context] …

When  [event]

Then  [outcome]

And [another outcome]…

3. Ateliers sur “User Story” / planification de sprint

Dans chaque atelier de création de story, chaque membre de l’équipe découvre les détails de ces user story, ce qui permet aux développeurs et à l’assurance qualité de connaître la portée du travail. Tout le monde devrait avoir la même compréhension de l’histoire.

Les développeurs doivent avoir une bonne compréhension des détails techniques impliqués dans la présentation de l’histoire, et l’assurance qualité doit savoir comment l’histoire (US) sera testée et s’il existe des obstacles à son exécution.

Prévenir les défauts – Membres de l’équipe

Dans les ateliers des stories, PO, Dev, QA et BA doivent être impliqués.

Les scénarios (valides, non valides et cas particuliers) doivent être pris en compte (le contrôle qualité peut apporter une énorme valeur ajoutée en réfléchissant de manière abstraite à l’histoire) et consignés dans des fichiers de caractéristiques.

C’est pour cela qu’il est important de noter que ce sont les scénarios (plus que toute autre chose) qui révèlent des défauts lors du test du produit. Plus vous consacrez d’efforts et de temps à cette activité, plus vous obtiendrez les meilleurs résultats.

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

De même, lors des réunions de planification de sprints, les estimations fournies pour une story doivent inclure l’essai de test ainsi que l’effort de codage. Un contrôle qualité (manuel et automatisé) doit également être présent dans les réunions de planification du sprint pour fournir une estimation permettant de tester le récit.

Développement

Pyramide de test

Lorsque le développement commence, le nouveau code de production et / ou la refactorisation du code existant doivent être complétés par des tests unitaires écrits par les développeurs et revus 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 retour 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’erreur dans la logique.

Lors de l’automatisation des tests, il est également important de respecter cette pyramide et donc de commencer par automatiser les tests unitaires, puis les tests de service / composant / intégration.

Le volume de tests automatisés doit être plus important en bas de pyramide car ces tests sont plus rapides et moins coûteux.

Test développeur

En tant que développeur, agissez comme si vous n’aviez aucune assurance qualité dans l’équipe ou l’organisation. Il est vrai que les QA ont des mentalités différentes, mais vous devriez tester au mieux de vos capacités.

Vous pensez gagner du temps en passant rapidement à la story suivante, mais en réalité, lorsqu’un défaut est détecté et signalé, il faut plus de temps pour le résoudre que de passer quelques minutes à s’assurer du bon fonctionnement de la fonctionnalité.

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

Tests d’acceptance automatisés et tests non fonctionnels

  • Les tests d’acceptance automatisés comprennent des tests d’intégration, des tests de service et des tests d’interface utilisateur visant à prouver que le logiciel fonctionne et qu’il est conforme aux exigences et aux spécifications de l’utilisateur. Les tests d’acceptation automatisés sont généralement écrits en langage Gherkin et exécutés à l’aide d’un outil BDD tel que le Cucumber. Pour aller plus loin vous pouvez consulter notre article sur  “Comment utiliser la méthode BDD dans les projets agiles ?”
  • Les tests non fonctionnels (performances et sécurité) sont aussi importants que les tests fonctionnels. Ils doivent donc être exécutés à chaque déploiement.
  • Les tests de performance doivent vérifier les métriques de performance sur chaque déploiement pour ne pas dégrader les performances.
  • Les tests de sécurité doivent vérifier les vulnérabilités de sécurité de base dérivées d’ OWASP. Des outils comme Kiuwan ou Sonar peuvent vous aider à réaliser des tests de ce type.

Il est essentiel que ce processus soit entièrement automatisé et qui nécessite très peu de maintenance pour tirer le meilleur parti des déploiements automatisés. Cela signifie qu’il ne devrait y avoir aucun échec de test intermittent, problème de script de test ou d’environnement défectueux.

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

Les tests de régression

Il ne faut pas s’attendre à trouver beaucoup de défauts. Leur objectif est uniquement de fournir des informations selon lesquelles nous n’avons pas des fonctionnalités majeures qui ne fonctionnèrent plus d’une version à une autre. Il devrait y avoir très peu de tests de régression manuels.

Pack de 15 min :

Ce pack contient uniquement des fonctionnalités de haut niveau permettant de s’assurer que l’application est suffisamment stable pour permettre un développement ou des tests supplémentaires.

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

  • Recherche de produit
  • Évaluation du produit
  • Item d’achat
  • 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 des tests de régression et contient tout ce qui n’est pas inclus dans le pack de 15 minutes.

Ici, l’objectif est d’obtenir un retour rapide avec un plus grand nombre de tests. Si le retour d’informations prend plus d’une heure, ce n’est pas rapide. La solution serait de soit réduire le nombre de tests en utilisant la méthode de test par paires, créer des packs de tests basés sur le risque ou exécuter les tests en parallèle.

Les tests de validation utilisateur (UAT) et tests exploratoires

Il n’y a aucune raison pour que l’UAT et les tests exploratoires ne puissent pas s’exécuter en parallèle avec les tests d’acceptance 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 du sens sur le plan commercial et sont utiles aux clients.

Le responsable de produit (Product Owner) doit exécuter des tests d’acceptation utilisateur ou des tests d’acceptance commerciale pour confirmer que le produit construit correspond aux attentes et qu’il correspond aux attentes de l’utilisateur.

Les tests exploratoires doivent se concentrer sur les scénarios d’utilisateur et rechercher les bugs non trouvés par l’automatisation. Les tests exploratoires ne doivent pas détecter des bugs triviaux, mais plutôt des anomalies plus subtiles.

Le critère « DONE »

Une fois que toutes les activités ci-dessus sont terminées et qu’aucun problème n’a été trouvé, la «user story » est terminée !

Pour conclure, nous espérons que toutes ces indications vous aideront à rédiger votre document de stratégie de test agile. Évidemment, cela doit être adapté aux besoins de votre organisation.

Il peut aussi parfois être utile d’avoir une vision externe pour challenger sa stratégie de test, aider à accompagner le changement ou choisir des outils de test par ex. C’est dans cette optique que nous avons mis en place une offre AUDIT avec des équipes de consultants aux profils complémentaires (Craftman, Test Manager, formateur BDD, Spécialiste en Automatisation de test …) ainsi que des formations sur la QA.

Vous souhaitez suivre nos articles ? Abonnez-vous à notre newsletter mensuelle via nos dossiers thématiques !

Vous avez aimé cet article ? Partagez-le avec vos amis chasseurs de bugs, DEV, PO   😊

Pour aller plus loin, vous pouvez consulter notre article sur le thème “Comment mesurer la qualité logicielle ?”