Vous avez votre revue d’exigences entre les mains. Il est désormais temps de rédiger la stratégie de test.
Attendez, vous ne nous avez pas expliqué ce qu’est une stratégie de test !
Vous avez raison, je vais vous donner sa définition.
Des éléments seront abordés, qui ne vous parleront pas pour le moment. Et c’est normal, nous ne les avons pas encore décrits dans ce cours. Je vous en parlerai dans les différentes parties de ce chapitre.
Définissez les caractéristiques des scénarios de test
Une stratégie de test fonctionnel est un plan d'action définissant la trajectoire et les méthodes à utiliser pour vérifier que le système fonctionne conformément aux exigences fonctionnelles.
D’accord, mais par quoi on commence ?
Elle commence par une analyse des exigences pour identifier les fonctionnalités à tester, les délais impartis et les ressources disponibles. Cette étape permet de déterminer les objectifs de test et les critères de réussite du projet (analyse des exigences que vous avez vue en partie 1 de ce cours 🙂).
OK, d’abord on analyse et on fait une sorte d’état des lieux du projet, et ensuite ?
Ensuite, il s’agit d’établir les types de tests à effectuer. Pour chaque type de test, elle décrit comment les tests se déroulent. Et également les outils et les techniques de tests à utiliser.
Les tests sont planifiés et exécutés de manière itérative, en utilisant des cycles de développement courts. Ils sont également continuellement mis à jour et adaptés en fonction des changements dans les exigences du projet.
Entendu, on définit comment on va faire, avec quoi et quand. Est-ce que cela inclut d’autres éléments ?
Cela inclut également des méthodes pour gérer les résultats des tests et les rapports. Elle comprend une méthode pour suivre les défauts et les corrections nécessaires, ainsi qu’une façon de communiquer les résultats aux parties prenantes.
Bien que validée avant le début des tests, elle est révisée régulièrement et mise à jour tout au long du projet. Cela afin d’être toujours en phase avec les exigences du projet en cas de modification de ces dernières.
En résumé, la stratégie de test est un plan qui décrit comment les tests vont être planifiés, exécutés et gérés tout au long du projet.
Prenez en main les scénarios de test
Avant de débuter et d'entrer dans le vif du sujet, je vous propose de revoir brièvement ce qu’est un scénario de test.
Voilà, avec ça, j’ai tout et rien dit en même temps. Si vous avez déjà suivi le cours sur l’exécution des tests, ce que je vais vous expliquer sera sûrement une redite, mais dans le cas contraire, ces éléments seront nécessaires à votre compréhension.
Imaginons la fonctionnalité pour un site de vente en ligne : implémentation du panier d’achat.
Nos scénarios auront besoin de :
Un Nom : Il doit refléter l’objectif du test et permettre de l’identifier facilement.
Ex. : Ajouter un produit au panier.
En fonction de l’entreprise pour laquelle vous travaillerez, des normes spécifiques pour le nommage peuvent exister. Mais elles reprendront ces quelques pratiques :
utiliser une terminologie claire et concise : afin de communiquer efficacement leur objectif aux membres de l’équipe ;
éviter les noms trop longs : ils doivent être suffisamment courts pour être compris et retenus par les membres de l’équipe ;
utiliser une convention de nommage cohérente : cela afin de faciliter leur organisation et leur recherche ultérieure ;
être spécifiques : ils doivent être assez spécifiques pour éviter toute confusion avec d’autres tests.
Un Objectif : Le but du scénario, que vais-je tester ? et pourquoi ?
Ex. : Le but du scénario est d’ajouter un produit au panier, afin de vérifier que le client pourra l’acheter.
Une ou des Exigences associées : L’association permet de justifier que le scénario est légitime, c'est-à-dire qu’il y a un besoin derrière.
Des cas de test :
qui sont une succession d’étapes spécifiques à suivre ;
dans un ordre séquentiel défini ;
en incluant toutes les actions à effectuer ;
avec un résultat attendu précis ;
ex. :
Étapes | Action | Résultat attendu |
1 | Se rendre sur le site web | La page d’accueil du site est affichée |
2 | Cliquer sur le rayon "Électroménager" | Affichage du rayon Électroménager |
3 | Sur l’aspirateur, cliquer sur “Ajouter au panier” | L’aspirateur est ajouté au panier |
Voici comment nous pourrions représenter la structure d’un scénario :
Cela insinue donc qu’on peut avoir plusieurs scénarios pour une même fonctionnalité ?
Tout à fait, dans notre exemple, nous pourrions ajouter des scénarios pour tester le comportement :
en ajoutant 2 produits au panier ;
en ajoutant plusieurs produits de différents rayons au panier.
Les combinaisons peuvent être multiples.
Dois-je faire attention particulièrement à certains points lorsque je définis mes scénarios ?
Voici deux bonnes pratiques à adopter quand vous définirez vos scénarios :
Pertinence : Le scénario de test doit couvrir une fonctionnalité ou un cas d'utilisation du logiciel.
Par exemple, il ne serait pas pertinent de créer un scénario sur les modes de paiement proposés dans le site, alors que notre objectif est de tester l’implémentation du panier.
Compréhensibilité : Il doit être facile à comprendre pour les testeurs et les autres membres de l'équipe de développement.
Cela commence par le nom ; il est préférable de dire “Ajouter un produit au panier” plutôt que “Ajouter un produit”.
Estimez le nombre de vos scénarios
Comment puis-je estimer la quantité nécessaire de scénarios ?
Pour cette partie, une réflexion que vous pourriez avoir serait “Comment tester le moins, pour couvrir le plus d’exigences ?”.
En effet, vous vous rendrez compte que plusieurs scénarios peuvent tester plusieurs exigences, voyez comment.
Pour vous permettre d’avoir une vue globale de votre périmètre à tester, définissez de manière macro (approximative) vos scénarios. L’idée est de pouvoir avoir une estimation du nombre de scénarios qui vont être nécessaires pour atteindre les objectifs du projet. Sommes-nous aux alentours de 10 scénarios ? ou plutôt 50 ? Voici une méthode qui peut vous aider à déterminer le nombre de scénarios :
Identifiez toutes les fonctionnalités de l'application, comme l'ajout d'un produit au panier, la suppression d'un produit, la mise à jour de la quantité d'un produit, la validation du panier, etc.
Pour chaque fonctionnalité, identifiez les différents cas de test possibles. Par exemple, pour l'ajout d'un produit au panier, les cas de test pourraient inclure la vérification que le produit est ajouté avec succès, la vérification que la quantité du produit est correcte, la vérification que le prix est correct, etc.
Estimez le nombre de cas de test pour chaque fonctionnalité. Cette estimation dépendra de la complexité de chaque fonctionnalité, et du nombre de scénarios différents que vous souhaitez tester.
Calculez le nombre total de cas de test pour l'ensemble de l'application, en additionnant le nombre de cas de test pour chaque fonctionnalité.
Identifiez les impacts sur le patrimoine
C’est une étape cruciale dans la stratégie. Cela permet d’identifier les effets des nouvelles fonctionnalités sur le patrimoine existant, et vous permet de sécuriser ces effets.
Pour identifier les impacts, il est nécessaire de passer en revue les exigences nouvelles ou modifiées, et d’analyser leurs impacts potentiels sur l’existant.
Pour identifier les impacts sur le patrimoine, posez-vous les questions suivantes :
Quels cas de test / scénarios devront être mis à jour ?
Cela consiste à modifier un cas de test existant pour le rendre conforme aux nouvelles exigences.
Imaginons que vous en ayez un : “Vérifier la page d’accueil du site”. Votre projet ajoute la fonctionnalité du panier, qui est accessible depuis la page d’accueil.
Vous devrez donc mettre à jour les cas de test associés, pour que vous puissiez tester l’accès à votre panier depuis cette page d’accueil.
Qu’est-ce qui pourra être réutilisé ?
On peut réutiliser un cas de test, du moment qu’il reste pertinent pour les nouvelles exigences, et ne nécessite pas de modifications.
Un scénario “Accéder au site” peut ne pas être impacté par l’ajout du panier, car il teste si l’accès au site est toujours possible.
Quels sont les tests qui ne seront plus pertinents après les modifications apportées aux exigences existantes ?
Qu’est-ce qui devient obsolète ?
Une fonction a été désactivée, et les scénarios de test associés n’ont par conséquent plus de raisons d’être utilisés.
Qu’est-ce que je vais devoir rédiger entièrement ?
Ici, de quel cas de test ou scénario allez-vous avoir besoin, qui n’existe pas encore dans votre patrimoine de test ?
Par exemple, le contrôle de l’interface du panier, car il est introduit dans cette version du projet.
À vous de jouer !
Contexte
Vous avez terminé votre analyse des exigences. Suite au dernier mail que vous avez envoyé, Édouard continue de voir comment intégrer les informations de la commande et son suivi.
Ce n’est pas définitif, mais la piste la plus probable est de faire évoluer la nouvelle table des commandes (t_commande) pour y intégrer ces éléments. Cette partie d’enregistrement n’aura donc pas d’impact sur votre patrimoine de test, et vous permettra d’avancer sur ce sujet pour le moment.
Consignes
Votre mission actuelle est de construire les scénarios par rapport aux fonctionnalités :
Rédiger une liste, macro, des scénarios.
Identifier les impacts sur le patrimoine de test.
En résumé
Une stratégie de test est un plan d’action qui permet de vérifier la conformité de l’application par rapport aux exigences.
Un scénario est une suite d’étapes à suivre pour vérifier le fonctionnement de l’application.
Pour l’estimation du nombre de scénarios, identifiez toutes les fonctionnalités, les cas d’utilisation possibles, et estimez ensuite la quantité de scénarios.
Le patrimoine de test est la bibliothèque où sont stockés vos scénarios et cas de test.
Les exigences peuvent avoir un impact sur le patrimoine, qui pourrait vous amener soit à pouvoir le réutiliser sans modification, soit à devoir le mettre à jour.
Vous avez esquissé la quantité de scénarios nécessaires pour mener à bien le projet. Maintenant, voyez quel crayon utiliser pour les réaliser.
