Définissez les besoins du scénario
Dans un film, le scénario est une succession de scènes, organisées chronologiquement.
Dans le test logiciel, ces scènes sont des cas de test, qui viendront former votre scénario.
Comme pour les exigences, vos scénarios pourront être de type fonctionnel ou non fonctionnel.
Dans le premier type, vous construisez un scénario pour décrire un comportement d’un utilisateur réel, quelque chose que le client final pourra faire.
Dans le second, vous les construisez pour tester des éléments plus techniques, de performance ou de sécurité.
Reprenez votre stratégie de test, où vous aviez défini de manière macro vos scénarios.
Vous détenez jusqu’ici une liste qui peut être complétée.
Pour ce faire, voici deux techniques (parmi tant d’autres), que vous pourrez utiliser dans de nombreuses situations :
Les tests aux limites : L’objectif ici est de tester les limites et les valeurs extrêmes normalement possibles pour la fonctionnalité.
Si le panier d’achat du site peut contenir 99 produits maximum, qu’est-ce qui se passe si j’en mets 100 ?
Les tests de combinaisons : Cette technique consiste à tester toutes les combinaisons possibles de variables.
Si pour ce même panier, il est possible d’ajouter un produit, de supprimer, de modifier la quantité et de vérifier le total, que ce passe-t-il si :
J’ajoute un produit et vérifie le total ?
J’ajoute plusieurs produits, j’ajoute un autre produit, je modifie la quantité et vérifie le total ?
Etc.
Pour vous aider à cette identification sur les cas de test, vous pouvez procéder ainsi :
Analysez le scénario : Comprenez les objectifs du scénario. Quels sont les éléments, fonctionnalités ou exigences que vous voulez vérifier ?
Identifiez les étapes : Décomposez le scénario en étapes logiques. Quelles sont les actions à effectuer, et les résultats attendus à chaque étape ?
Relevez les conditions préalables : Notez les éléments dans lesquels le système doit être, ou dont il va avoir besoin pour tester une fonctionnalité. Quels sont les prérequis pour pouvoir débuter mon test ?
Prenons un exemple concret pour illustrer cette théorie :
Gardons notre situation de site de vente en ligne, et tentons d’ajouter des produits au panier d’achat.
⇒ Analysez le scénario
L’objectif pourrait être de tester :
Que le site est accessible.
Que l’on peut voir un produit.
Que l'on peut ajouter un produit au panier.
Que l'on peut voir le contenu du panier.
⇒ Identifiez les étapes
L’accès au site.
La visualisation d’un produit.
L’ajout du produit dans le panier.
La visualisation du panier.
⇒ Relevez les conditions préalables
Le site est dans une version donnée (v1.0, par ex.).
Pour accéder au site, celui-ci doit être disponible.
Pour visualiser et ajouter un produit au panier, des produits doivent être présents sur le site.
En voyant cela, vous pouvez identifier les besoins en cas de test suivants :
Cas : Accès au panier.
Cas : Accès à une fiche produit.
Cas : Accès au site web.
Cas : Ajout d’un produit au panier.
Associez vos cas de test
Il est temps d’associer les cas de test pour former le scénario.
En définissant les besoins en scénario, vous avez déjà fait presque tout le travail, bravo à vous ! 🙂
L’association des cas de test doit permettre de valider les exigences, tout en suivant un comportement le plus proche possible de celui qu’adoptera l’utilisateur final.
L’élément le plus important est de définir l’ordre d'enchaînement des cas de test, dans lequel ils doivent être exécutés pour atteindre l’objectif du scénario.
Dans notre exemple un peu plus haut, nous avons défini les besoins de cas de test en :
Cas : Accès au panier.
Cas : Accès à une fiche produit.
Cas : Accès au site web.
Cas : Ajout d’un produit au panier.
En les remettant dans un ordre d'exécution cohérent avec ce qu’un utilisateur fait, vous obtiendrez :
Accès au site web.
Accès à une fiche produit.
Ajout d’un produit au panier.
Accès au panier.
En pratique, les phases de rédaction des cas de test et d’assemblage des scénarios peuvent se faire en parallèle. Des idées de scénarios supplémentaires peuvent survenir. N’hésitez pas à passer d’une étape à l’autre.
Vérifiez votre couverture d’exigences
Vos cas de test sont rédigés et les scénarios assemblés, il s’agit désormais de vérifier que toutes les exigences à tester soient couvertes.
Une exigence peut être associée à un ou plusieurs cas de test, et la réciproque est vraie également.
Cela peut s’expliquer par sa complexité, ou les comportements qu’elle peut exprimer.
Pour ce faire, il n’y a pas de secret ou de technique miracle, malheureusement. Si vous utilisez un logiciel proposant de vous faire un rapport de couverture, vous gagnerez un temps non négligeable, car il va vous identifier toutes les exigences, couvertes ou non.
S’il ne vous le propose pas, vous ne pourrez y échapper : une vérification manuelle sera nécessaire. Mais le jeu en vaut la chandelle, croyez-moi.
Un rapport de couverture d’exigences est un document qui permet de vérifier si toutes les exigences sont couvertes. C'est-à-dire, qu'elles sont testées par au moins un cas de test.
Ce rapport peut intervenir à différents moments du projet, lors de la conception ou de l’exécution.
Il inclut donc : si les exigences sont testées ou non, si elles sont validées, en échec ou en cours de validation.
Le premier sujet de stratégie et de conception de test qui m’ait été confié aurait pu avoir une fin bien moins glorieuse qu’elle n’a eu.
Notre client lançait son application mobile, avec plus ou moins les mêmes fonctionnalités que celles disponibles sur son site web. Projet volumineux, découpé en plusieurs parties, et personne pour alléger la charge de travail et tenir les délais. J’étais chargé de la partie “Accessibilité et navigation”, j’avais hérité du morceau le plus sympa.
À l’époque (années 2010), nos cahiers de recette étaient des tableurs Excel. Donc la vérification de la couverture d’exigences devait se faire à la main.
J’importe les exigences, rédige les cas de test, assemble les scénarios, et je vérifie ma couverture.
Je ne vois pas de problème particulier, et on avait prévu qu’un pair effectue une relecture approfondie, comme c’était mon premier sujet.
Ce fut une chance, car il a remarqué qu’une exigence n’était pas couverte. Et qu’en plus je n’avais pas rédigé de cas de test pour la vérifier (la totale…).
À vous de jouer !
Contexte
Dans l’outil de gestion des tests, les cas de test ont été mis à jour ou rédigés.
Vous avez besoin maintenant de les assembler afin de créer les scénarios que vous avez définis :
Enregistrement d’une commande client authentifié.
Annulation de la saisie d’une commande.
Vérification de la table t_commande.
Vérification du suivi de la commande.
Ces scénarios ont été imaginés au début de la stratégie de test.
Il est possible que maintenant, avec le recul, il vous soit possible d’en mutualiser certains.
Consignes
Assemblez vos cas de test pour former les scénarios.
En résumé
Un scénario est une succession de cas de test organisés de manière chronologique, permettant la vérification de son ou ses objectifs.
Deux techniques peuvent vous aider à affiner votre liste de scénarios : la technique des tests aux limites et celle des combinaisons.
Organisez vos cas de test dans un ordre d’exécution précis, afin d’offrir au testeur exécutant votre cas de test, la possibilité de rentrer dans les conditions permettant de valider l’objectif.
Vérifiez votre couverture d'exigences afin de vous assurer qu’elles seront toutes testées par un ou plusieurs cas de test.
Votre cahier de recette est fin prêt. Vous pouvez maintenant le présenter, et c’est ce que nous allons voir dans le prochain chapitre.
