Zoom sur les tests Agiles fonctionnels Q2-Q3
L’objectif de cet article est de dresser le portrait des tests Q2 et Q3 afin de mettre en avant leurs différences, leur complémentarité, et les problématiques qu’ils soulèvent. Le contexte de cet article est l’agilité à l’échelle ; dans ce cadre, une release correspond à la mise en production d’une version de l’application et a nécessité plusieurs sprints.
Les quadrants de test Agile
Commençons par la terminologie : les notions de Q2 et Q3 sont issues des quadrants de test Agile théorisés par Brian Marick, et repris dans le syllabus Niveau Fondation V4 « Testeur certifié » de l’ISTQB.
Voici ci-dessous un rapide aperçu de ces quadrants.
Comment lire ces quadrants :
- L’axe horizontal concerne la finalité du test.
À gauche, le test vise à aider à la construction du produit en fournissant un feedback rapide au développeur sur la qualité de son développement.
À droite, le test a pour finalité de sécuriser la mise en production en diminuant le risque d’un bug résiduel en production. - L’axe vertical distingue les deux aspects différents que doivent vérifier les tests : aspects techniques versus aspects métiers.
Cet article est dédié aux tests fonctionnels, les tests Q2/Q3 :
- Les tests Q2, réalisés dans le cadre du sprint par un testeur membre de la team Agile, visent à donner aux développeurs un feedback rapide sur le développement de la User Story (US), dans l’optique « plus un bug est corrigé tôt, moins il coûte cher ».
Le développeur a plus de facilité à corriger un bug juste après le développement car le code est encore frais dans sa mémoire. - Les tests Q3, réalisés dans le cadre de la release, visent à sécuriser l’application / le SI en trouvant un maximum de bugs au plus près des conditions réelles de la production (en termes de données, d’interconnexions, etc.).
Ces différents tests sont détaillés dans le chapitre suivant.
Rôle des tests Q2 et Q3 dans un projet Agile
Les tests fonctionnels Q2 dans le projet
Au niveau des tests fonctionnels Q2, très peu sont généralement formalisés. Comme l’objectif est de délivrer un feedback rapide aux développeurs, la priorité est donnée à la vérification du développement dès la fin du développement d’une User Story. Cette approche implique de prioriser son temps sur les activités d’exécution de test. De fait, les tests fonctionnels Q2 ne font pas systématiquement l’objet d’une conception. Le testeur en Q2 doit donc choisir les tests pour lesquels il a besoin de faire une conception préalable.
Les tests réalisés peuvent toutefois être documentés pendant l’exécution pour garantir à la fois leur traçabilité et le partage des informations à toute la team.
Exemple concret de partage d’informations au sein de la team Agile :
Avec Squash, lorsqu’il est interfacé avec l’outil de gestion Agile (Jira ou GitLab), l’avancement et les résultats des tests sont partagés à toute la team, et les anomalies déclarées par le testeur sont directement associées aux US.
Cela permet aux PO et aux développeurs de rester au sein de leurs outils sans avoir à consulter l’outil de recette : les anomalies et l’avancement de la recette y sont remontés directement.
Pour satisfaire à leur finalité d’aider à construire le produit, et être réalisés rapidement après les développements, les tests Q2 sont idéalement réalisés sur des nightly build déployées automatiquement toutes les nuits. Cette automatisation du déploiement nécessite des compromis sur l’environnement qui héberge le System Under Test (SUT) : environnement bouchonné, données non représentatives de la production, etc.
En conséquence, les tests Q2 sont réalisés sur des environnements allégés assez éloignés de la production. Par ailleurs, les tests Q2 concernent principalement des tests de User Story.
Les tests Q2 ne peuvent donc suffire, et doivent donner lieu à d’autres tests : les tests Q3.
Les tests fonctionnels Q3 dans le projet
Les tests Q3 ne s’inscrivent pas dans la temporalité des sprints mais dans celle de la release ; ils ont pour objectif de sécuriser la mise en production.
Ils se distinguent des tests Q2 sur les principaux aspects suivants :
- Ils font l’objet d’une phase de conception dédiée ;
- Ils sont exécutés sur un SUT déployé dans un environnement représentatif de la production.
La phase de conception des tests Q3, en synergie avec les tests réalisés en Q2, doit permettre d’orienter et d’optimiser la couverture et l’effort de tests. Ceux-ci se focalisent sur les tests fonctionnels niveau Epic, les tests de bout-en-bout, les tests métier, etc.
Par ailleurs, l’essentiel de l’analyse et de la spécification des tests est déportée en amont de la livraison du SUT : cela permet d’accélérer l’exécution des tests Q3 dès livraison du SUT.
La spécification des tests réalisée en phase de conception des tests Q3 présente un autre avantage : elle devient également essentielle en palliant la documentation souvent très parcellaire en sortie de tests Q2.
Le patrimoine de tests, éventuellement initié en Q2 mais toujours complété/consolidé en Q3, devient la mémoire vivante de l’application.
Pour plus de détail sur le patrimoine de tests en tant que mémoire vivante du SI, consultez notre article à ce sujet :
L’exécution des tests Q3 se réalise sur un environnement représentatif de la production.
L’objectif de cet environnement est d’avoir un maximum de caractéristiques proches de celles en production afin de tester dans des conditions au plus près de celles des utilisateurs finaux.
Ces caractéristiques sont par exemple :
- Les données ; elles sont essentielles en environnement de tests Q3 car des anomalies peuvent apparaître à cause des données. Une fonctionnalité peut être stable lorsqu’elle a été testée avec des données très parcellaires en Q2 mais se révéler instable lorsqu’elle doit fonctionner avec les données de l’environnement final, en termes de volume et de représentativité fonctionnelle. A cette fin, les données de test Q3 sont souvent issues de la production.
- Les interconnections ; en Q2, le test porte sur un environnement isolé, alors qu’en Q3, on s’efforce de tester sur un environnement comportant les connections avec les autres applications du SI ou de SI tiers (à l’image de la production), les plugins, les API, les outils, les utilitaires…
- Les habilitations ; en Q3, l’environnement de test doit se rapprocher au maximum des conditions de sécurité de la production, en termes de permissions, de droits, d’accès, d’autorisations, etc.
En synthèse
En Q2, les tests vérifient la qualité de fonctionnalités isolées développées durant le sprint. Ils visent d’abord à limiter le coût de correction d’un bug en les identifiant au plus proche du développement.
Les tests Q3 vont plus loin en permettant de déceler les anomalies d’usage en conditions quasi réelles d’utilisation et la non-régression à l’échelle du SUT. Ils permettent ainsi de fiabiliser la mise en production.
Par ailleurs, les tests Q3 permettent également de constituer une spécification vivante de l’application ou du SI. En effet la phase de conception des tests Q3 et la constitution au fil des versions d’un véritable patrimoine de tests peuvent pallier les problématiques induites par la documentation « jetable » de l’approche Agile : ce patrimoine de tests devient la spécification exhaustive et à jour du fonctionnement de l’application.
Au-delà de ces avantages, l’approche Q2/Q3 pose la problématique de la coordination des tests réalisés en Q2 et en Q3, afin d’optimiser la couverture des tests et éviter l’emballement des charges et des délais de recette.
Ce sujet fera l’objet d’un article ultérieur.
Pour en savoir plus
Vous abonner à la Newsletter de Squash :
Découvrir Squash :
Consulter la documentation en ligne de Squash :
