Qu’est-ce qu’un plan de tests Agile?

Un plan de tests Agile est un document très important parce qu’il donne à votre équipe d’assurance qualité (AQ) la possibilité d’avoir en un seul endroit tous les scénarios de haut niveau, les exigences opérationnelles et les estimations. Votre analyste AQ ou votre testeur Agile doit remplir un plan de tests lors de chaque réunion de planification de sprint. Et comme le document est constamment mis à jour, il change et évolue en fonction des exigences du sprint et des échéanciers globaux.

Un plan de test Agile doit avoir une structure claire et appropriée, contenant les intrants métier et les tâches d’AQ.

Voyons comment ça marche.

1. Introduction

Les plans de tests commencent généralement par une introduction ; il s’agit d’une brève description du projet contenant des informations générales sur le processus de test pendant le sprint. Cette partie du document devrait comprendre deux sous-parties :

1.1 Portée du document

Le but de cette section est de préciser comment sera testée la livraison de la future application. Elle définit les éléments suivants :

• Récits utilisateurs
• Environnement AQ
• Portée des tests
• Processus de test
• Risques et dépendances
• Estimations et critères de sortie

1.2. Description fonctionnelle

Cette description clarifie les caractéristiques des fonctions nouvellement créées au sein de l’application et la manière dont elles peuvent être testées. Le fonctionnement est expliqué en termes généraux et non en détail. Par exemple : « Une nouvelle fonction de géolocalisation est activée lorsque l’utilisateur se connecte à l’application web et est automatiquement désactivée après deux heures d’inactivité. Aussi, l’utilisateur peut désactiver manuellement la géolocalisation dans les paramètres du compte : Compte → Paramètres → Paramètres de géolocalisation → Localisation. »

2. Récits utilisateurs

Cette partie du plan de tests inclut toute nouvelle fonctionnalité accompagnée d’une explication ou d’un récit utilisateur (User Story). Les récits utilisateurs sont importants parce qu’ils montrent les besoins de l’entreprise. Si une nouvelle fonctionnalité vient du client sans être accompagnée d’un récit utilisateur, l’analyste qualité et le chef de projet doivent écrire ensemble les scénarios de haut niveau et créer ensuite une nouvelle tâche dédiée dans Jira.

3. Environnement AQ

Cette partie détaille habituellement tous les logiciels et outils destinés à être utilisés dans le processus de test lors du sprint, y compris les types de tests manuels et automatiques. Tout dépend des principales exigences du projet et des discussions pour éclaircissement avec le Product Owner ou avec le client.

• Par exemple : une plate-forme logicielle, un système d’exploitation, un type d’appareil ;
• Quel outil d’automatisation : Selenium WebDriver ou UFT ;
• Appium Framework ou Express pour l’automatisation sur mobile ;
• jMeter ou LoadRunner pour les tests de performance.

4. Portée des tests

La portée ou le périmètre des tests est une liste de tous les tickets et tâches d’assurance qualité, que le testeur consultera lors d’un sprint Agile. Le document contient tous les numéros des tickets Jira, des résumés des tickets, les durées estimées de travail d’AQ et les liens Hiptest (facultatif). Lors de la rédaction de la portée des tests, il est important de tout coordonner avec les développeurs, le chef d’équipe et le Product Owner.

Voyons un exemple pour un test :

Référence du ticket : Jira 876.
Résumé : la géolocalisation doit être testée sur iPhone 7.
Build: app-staging-build-1.2.3.
OS : Android et iOS.
Temps estimé : 2,5 heures.
Lien Hiptest : https://app.hiptest.com/l/fo/765776.

5. Processus de test

Un plan de tests doit indiquer quels types de tests seront utilisés lors du sprint Agile. Les processus manuels et automatisés permettent différents types de tests logiciels, tels que :

• Tests fonctionnels : seulement les tests positifs pour les principales fonctionnalités du logiciel ; pas de tests négatifs pendant le cycle de test.
• Tests de sécurité : tests positifs et négatifs, ce qui signifie vérifier le fonctionnement de l’application pour les fonctionnalités « s’inscrire », « s’identifier » et « mot de passe oublié ».
• Test d’interfaces utilisateur : tester la présence d’éléments particuliers de l’interface sur une page web ou une version mobile. Les tests d’interface vérifient généralement l’affichage, la taille et l’emplacement des éléments sur une page/un écran.
• Tests multinavigateurs : tests sur les navigateurs les plus populaires (la liste dépend des exigences de l’entreprise cliente comme du pays d’utilisation).
• Tests de régression : Il existe deux types de tests de régression : les tests de prérégression sur les versions candidates à la livraison et les tests de post-régression après le déploiement et les tests de fumée (Smoke Tests). Les tests de régression mobile impliquent la vérification d’une version précédente, puis l’installation d’une version actuelle et aussi le test de la version candidate.
• Smoke/Sanity Testing : des tests simples et rapides des fonctions essentielles. Par exemple, l’application fonctionne-t-elle ou pas après la livraison ? Les tests de fumée se déroulent généralement après la livraison pour vérifier si le lancement est correct.

6. Risques et dépendances

Avant de commencer un processus de tests Agile, l’analyste AQ doit décider s’il existe des bloquants ou de potentiels risques d’échec des tests. Si oui, s’agit-il de risques mineurs ou majeurs ? Par exemple, est-ce que les développeurs ont dû délaisser la programmation en raison d’un « gel du code » lors du précédent sprint ? La dernière version a-t-elle été publiée avec succès ? A-t-elle été approuvée par le client ? L’analyste AQ devrait discuter de tout cela avant que les développeurs ne commencent à coder.

7. Estimations et critères de sortie

Les estimations sont des prévisions générales pour la complétion des sprints et les livraisons. Combien d’heures l’AQ devrait-elle consacrer à différents types de tests ? Quand le feu vert sera-t-il donné pour le lancement d’une version web et/ou mobile ? Ces questions devraient aider à mettre l’accent sur les résultats essentiels.

Enfin, lorsque vous complétez toutes les parties du plan de tests, assurez-vous que tous les scénarios essentiels ont été créés dans Jira et Hiptest avec une description détaillée, incluant les critères d’entrée et de sortie, le nom du sprint, les estimations d’origine et un résumé approprié.

La création d’un plan de tests Agile détaillé et structuré aide à garantir un processus d’AQ complet, à être confiant dans son travail et à éviter d’importantes omissions. C’est une excellente habitude que de toujours se référer à ce document dans lequel tout est indiqué.