Nouveauté ! Développez votre produit SxMD avec un eQMS structuré comprenant des modèles SxMD prêts à être audités et conformes aux normes EU et US. En savoir plus !
Qu'est-ce qu'un scénario de test ? Les meilleurs conseils pour écrire des cas de test dans les tests de logiciels.
Qu'est-ce qu'un scénario de test ?
Un scénario de test est un ensemble d'instructions ou d'étapes détaillées utilisées pour vérifier qu'un logiciel, un module ou une fonctionnalité logicielle spécifique fonctionne comme prévu. Ils sont généralement élaborés spécifiquement pour les scénarios de test afin de s'assurer que le logiciel répond à ses exigences spécifiques. Dans les entreprises de logiciels, cette tâche est généralement confiée à une équipe de test ou à une équipe de développement spécialisée, mais elle ne se limite pas à celles-ci. Des scénarios de test inefficaces peuvent être à l'origine de bogues qui passent à travers les mailles du filet et finissent par apparaître dans la production. C'est pourquoi il est essentiel de rédiger des cas de test de bonne qualité pour assurer la robustesse de l'application et la réussite ducycle de développement logiciel (SDLC) . Cet article de blog couvre les types de cas de test, la structure des cas de test, les meilleures pratiques et l'importance de la gestion des cas de test.
Quelle est la différence avec le plan de test ?
Un plan de test fait référence à une stratégie et à une approche plus larges pour tester un système ou une application logicielle, y compris l'objectif, la portée, les ressources et le calendrier. Les informations typiques contenues dans le plan de test sont : le nombre de tests, l'objectif de chaque test, les outils nécessaires, etc. Un plan de test est un document de haut niveau contenant l'approche globale du projet en matière de test, tandis qu'un scénario de test fait référence à des instructions détaillées, étape par étape, pour exécuter des scénarios de test spécifiques. En substance, alors que le plan de test fournit le cadre général et les objectifs des tests, un scénario de test fournit les procédures spécifiques et les détails nécessaires à l'exécution des tests individuels.
Pourquoi écrire des scénarios de test ?
Vu de l'extérieur, on pourrait croire que les tests consistent simplement à utiliser le logiciel, mais ce n'est pas le cas. Bien que l'objectif principal des tests soit de voir si le logiciel fonctionne, il y a de nombreux avantages à écrire des scénarios de test détaillés :
Les scénarios de test apportent structure et stabilité au processus de test. Si les cas de test sont bien écrits, ils peuvent être exécutés par une plus grande partie de l'équipe, permettant même à ceux qui n'ont pas de connaissances préalables d'effectuer des tests.
Aide à réfléchir aux détails. Lorsque l'auteur rédige un test, cela l'aide à réfléchir en profondeur à la fonctionnalité du logiciel, ce qui lui permet de repérer les zones d'oubli avant qu'elles ne deviennent trop coûteuses à corriger.
Documents sur la manière dont le système devrait fonctionner. Ils constituent une bonne source de vérité sur le fonctionnement d'un logiciel ou d'une fonctionnalité spécifique.
Réduction des coûts de maintenance des logiciels. Les cas de test apportent des couches prévisibles et reproductibles au processus de test, ce qui permet de détecter les bogues à un stade précoce, réduisant ainsi les coûts associés à la correction des bogues et à l'assistance logicielle. Cela signifie également que des produits de meilleure qualité se traduisent par des clients plus satisfaits.
Types de cas de test
Comprendre les types de cas de test peut aider à comprendre quels types d'aspects doivent être abordés dans le cas de test. Il existe de nombreuses façons de classer les scénarios de test. L'une d'entre elles consiste à les classer en fonction de l'approche et du style de test :
Tests positifs. Ce type de test est connu sous le nom de "happy-path testing". Dans ce type de test, seul un bon ensemble de valeurs est vérifié. En d'autres termes, l'application est testée par rapport aux données d'entrée valides. L'objectif est de comprendre si le logiciel fait ce qu'il est censé faire. Par exemple, si nous disposons d'un formulaire de saisie avec des identifiants de connexion valides, nous devrions être connectés.
Test négatif. Ce test est également connu sous le nom de test du chemin d'erreur. L'objectif est d'identifier les bogues lorsque des ensembles de données inappropriés ont été utilisés. Par exemple, dans un formulaire de saisie, si nous ne pouvons saisir que des lettres et des chiffres, nous ne devrions pas pouvoir saisir de caractères spéciaux, ou du moins nous devrions recevoir un avertissement.
Tests destructifs. Ce type de test logiciel est conçu pour identifier les défaillances du logiciel lorsqu'un système est essentiellement cassé ou exposé à des conditions extrêmes. L'objectif des tests destructifs est d'identifier les défaillances potentielles du système avant qu'elles ne se produisent du côté de l'utilisateur. Par exemple, il s'agirait de simuler une tentative de piratage en essayant d'injecter du JavaScript avec des intentions malveillantes dans un formulaire de connexion.
Une autre façon de procéder consiste à les distinguer par leur objectif :
Tests fonctionnels. Il s'agit de vérifier si le logiciel est conforme auxexigences et aux spécifications dulogiciel .
Tests de convivialité. Il s'agit de vérifier l'expérience de l'utilisateur final et la facilité générale d'utilisation.
Tests de performance. Il s'agit de vérifier comment le logiciel gère des charges de travail plus importantes.
Test de régression. Vérifier que les modifications récentes du code n'ont pas introduit d'effets secondaires dans les fonctionnalités existantes du logiciel.
Test de l'interface utilisateur. Il s'agit de vérifier si les éléments visuels sont rendus correctement, si l'interface utilisateur fonctionne correctement et si l'apparence de l'application est correcte.
Test d'acceptation par l'utilisateur. Il s'agit de vérifier qu'une application satisfait aux exigences de l'entreprise avant que les utilisateurs ne l'acceptent. Ils déterminent si les utilisateurs acceptent ou rejettent les résultats produits par un système particulier avant qu'il ne soit mis en production.
Tests de sécurité. Il s'agit de vérifier si les données sont protégées et si les autres aspects de la sécurité sont pris en compte. L'objectif principal est d'identifier les faiblesses, les vulnérabilités et les risques de sécurité. Ils vérifient également que certains types d'attaques externes peuvent être évités ou traités avec des conséquences minimales.
Quand rédiger des scénarios de test ?
Il existe plusieurs approches différentes pour l'écriture des cas de test. Cela dépend de la taille de l'équipe, de la portée du produit et du processus de développement.
Avant le développement. Avec cette approche, les cas de test sont rédigés avant tout codage. Le principal avantage de cette approche est qu'elle permet de comprendre et d'identifier les exigences clés avant tout développement.
Après le développement. Les cas de test sont écrits après le développement d'un logiciel ou d'une fonctionnalité. Cela facilite la rédaction des cas de test car le système testé peut déjà exister. Mais le principal inconvénient de cette approche est qu'elle n'est pas très efficace en termes de temps.
Pendant le développement. Avec cette approche, les cas de test sont écrits en parallèle pendant le développement. Le principal avantage est une plus grande efficacité en termes de temps et un degré plus élevé de collaboration entre les membres de l'équipe.
Quelle est la structure du scénario de test ?
La documentation du scénario de test comprend généralement toutes les informations nécessaires à l'exécution et à l'analyse du test. En général, la structure du scénario de test diffère d'une organisation à l'autre, mais la majorité comprend au moins les éléments suivants
ID du test. Cet identifiant unique peut être exprimé par un nombre, mais il s'agit généralement d'une combinaison de lettres et de chiffres. L'objectif principal de l'identifiant d'essai est de permettre un suivi plus efficace et d'assurer la traçabilité. Si une entreprise utilise un système de gestion des tests, cet identifiant est généralement attribué automatiquement.
Nom. Ce nom se passe d'explications. Mais les noms doivent toujours indiquer la fonctionnalité clé qui est testée et les noms des modules dans lesquels la fonctionnalité testée apparaît.
Conditions préalables. Cette section définit l'état initial du système avant l'exécution du test. Par exemple, elle peut indiquer quel type de données doit exister sur le serveur, quels droits d'accès utilisateur le testeur doit avoir, quel type d'environnement il doit utiliser et sur quel type de système le test doit être exécuté (par exemple Browser/Os). Cette section peut être très importante car un état initial incorrect du système peut être le précurseur d'un cas de test mal exécuté.
Description. Cette section doit fournir au testeur plus d'informations sur le cas de test.
Étapes du test. C'est la partie la plus importante du scénario de test. Elle contient la séquence d'actions que le testeur doit effectuer pour obtenir le résultat souhaité. Il est important de noter que les étapes doivent être très claires, descriptives et faciles à comprendre. Elles doivent contenir le moins d'hypothèses et d'incertitudes possible.
Résultats attendus. Cette section doit fournir des informations sur le type de résultat attendu du système après l'exécution de l'étape de test. Il existe deux approches différentes pour rédiger cette section. La première consiste à présenter un résultat attendu pour toutes les étapes précédentes. Un autre serait d'avoir des résultats attendus pour chaque étape de test correspondante.
Données d'essai. Il peut être nécessaire d'introduire certaines données dans le système. Ou bien le testeur devra modifier le système d'une certaine manière pendant le test. Le scénario de test pourrait donc comporter une section spécifique à cet effet. Mais il est important de noter que cette section peut être combinée avec les sections conditions préalables/description/étapes de l'essai.
Détermination de la réussite ou de l'échec. Il est bon que les scénarios de test comportent une section permettant de noter le résultat de chaque étape. Essentiellement, si le résultat réel correspond au résultat attendu, le test est réussi. Dans le cas contraire, le test échoue.
Postconditions. Cette section comprend les détails et les actions à effectuer une fois le test terminé. Elle sert à mettre le système dans son état initial. La section des postconditions peut être très utile pour les tests automatisés, car elle permet de remplir très rapidement la base de données avec des données inutiles.
En respectant les sections décrites ci-dessus, les organisations peuvent s'en tenir à la norme d'écriture de leurs tests de logiciels. Cette liste n'est pas exhaustive, car il existe d'autres façons de structurer un scénario de test. Par conséquent, toute organisation employant une structure quelconque devrait régulièrement revoir et mettre à jour ses processus de test et les normes utilisées. Un scénario de test bien défini réduit le temps nécessaire aux tests et la probabilité que des bogues non détectés se glissent dans le système.
Rédaction des cas de test : Conseils
Des scénarios de test de bonne qualité sont essentiels pour tous les cycles de développement de logiciels (SDLC). En effet, les scénarios de test sont essentiels pour vérifier la fonctionnalité de l'application logicielle et sa conformité avec les exigences et les spécifications. Il est important de comprendre quelques étapes essentielles avant de rédiger un scénario de test :
Utiliser un titre clair et descriptif. Une bonne pratique consiste à nommer le scénario de test de la même manière que le composant logiciel ou la fonctionnalité qui est testé.
Inclure une description : il est important que la personne qui effectuera les tests les comprenne.
Inclure des conditions préalables. Lors de l'exécution des tests, des conditions initiales correctes peuvent permettre d'éviter les faux négatifs. Si le système est dans un mauvais état avant le début du test, il peut en résulter des résultats inattendus et imprévisibles. C'est pourquoi le système testé doit toujours être placé dans un état connu.
S'assurer que les étapes du test sont claires et précises. Les étapes du cas de test doivent inclure les données et les actions nécessaires à l'exécution du test. Elles ne doivent pas contenir d'ambiguïté. Une ambiguïté dans le scénario de test peut conduire la personne qui exécute le test sur un chemin inconnu, ce qui rendrait l'exécution du scénario de test presque inutile. Un autre point important est que le scénario de test doit être écrit de manière à ce qu'une personne n'ayant pas une grande expérience de l'utilisation du logiciel puisse l'exécuter.
Assurez-vous que le résultat attendu est clair. Cette section doit indiquer exactement le type de résultat que le testeur attend du système. C'est une bonne pratique d'inclure des captures d'écran ici et de permettre une vérification rapide de la fonctionnalité du logiciel.
Faire en sorte qu'il soit répétable et réutilisable. C'est toujours une bonne pratique de rendre les scénarios de test réutilisables, car cela apporte une valeur à long terme à l'ensemble de l'équipe du projet. Par exemple, si le scénario de test doit vérifier un ensemble de données changeant, l'auteur du scénario de test peut écrire certaines étapes comme s'il s'agissait d'une chaîne interpolée, de sorte que l'étape de test ne change pas, mais que les données de test changent.
En suivant les principes décrits ci-dessus, l'auteur d'un scénario de test peut prendre un bon départ pour la rédaction de son scénario de test.
Rédaction d'un scénario de test : Un exemple
Cette section de l'article de blog fournit un exemple simple d'écriture d'un scénario de test. Imaginons que nous ayons une application de calculatrice de base. Nous sommes chargés d'écrire deux scénarios de test pour la fonctionnalité de cette application : un pour la soustraction par zéro, et un autre pour la division par zéro. Le premier cas de test pourrait ressembler à ce qui suit :
Titre : Opérations avec zéro (soustraction)
Description : Le scénario de test vérifie que la soustraction par zéro fonctionne correctement. Il s'agit d'un scénario de test fonctionnel - il vérifie que les fonctionnalités fonctionnent comme prévu.
Condition préalable : Aucune entrée n'est présente dans la calculatrice.
Etapes du test :
Saisir 1
Cliquez sur l'opérateur de soustraction -
Entrer 0
Cliquez sur l'opérateur d'évaluation =
Résultat attendu: Vérifier que le résultat est 1
Un autre exemple serait un scénario de test pour la division par zéro d'une calculatrice. D'après l'exigence, nous savons qu'une fois la division par zéro effectuée, le message "Error !" doit s'afficher ; écrivons donc un autre scénario de test pour cela :
Titre : Opérations avec zéro (division)
Description : Le scénario de test vérifie que la division par zéro fonctionne correctement. Il s'agit d'un scénario de test fonctionnel - il vérifie que les fonctionnalités fonctionnent comme prévu.
Condition préalable : Aucune entrée n'est présente dans la calculatrice.
Etapes du test :
Entrez 1 / 0
Cliquez sur l'opérateur d'évaluation =
Résultat attendu:
Vérifiez que l'écran n' affiche pas Infinity
Vérifier que l'écran indique Error !
Gestion des cas de test
Plus la portée d'un logiciel augmente, plus l'ampleur des cas de test augmente également. Plus la fonctionnalité du logiciel est ajoutée, plus elle devra être testée. En outre, non seulement les nouvelles fonctionnalités devront être testées, mais il sera également nécessaire de procéder à des tests de régression. Les tests peuvent ainsi devenir un goulot d'étranglement pour l'ensemble du processus de développement du logiciel. Pour les petites entreprises disposant de petites suites de tests, l'utilisation de feuilles de calcul et de fichiers texte peut fonctionner dans un premier temps, mais elle peut finir par provoquer le phénomène de la grenouille en ébullition.
Les outils de gestion des tests peuvent aider les organisations à suivre et à mettre à jour leurs tests en fonction des besoins. Il existe de nombreuses options pour les outils de gestion des tests. En fin de compte, la meilleure option est celle qui s'adapte au processus, aux flux de travail et qui dispose de multiples intégrations. Les outils de création et de gestion des cas de test peuvent améliorer considérablement la qualité des tests. Lorsque tout est organisé et facile à exploiter, l'efficacité du processus de test augmente.
Un bon outil de création et de gestion des scénarios et des cas de test doit comprendre les éléments suivants
des capacités d'édition de texte pratiques et étendues
Prise en charge des pièces jointes
Possibilité d'organiser les cas de test en fonction des différentes catégories de test
Bonne intégration avec les systèmes de gestion des tâches
Possibilité d'inclure automatiquement les résultats des tests dans les rapports
Bonne visualisation des données grâce à différents tableaux de bord des tests.
Intégration avec des scripts d'automatisation
MatrixALM est l'un des outils qui offrent toutes ces possibilités . Il s'agit d'une plateforme robuste et multicouche permettant de gérer les tests de vérification et de validation. Ilintègre de manière transparente avec Jira Clouds, ce qui permet d'ajouter et de lier facilement des tickets Jira à des cas de test exécutés. En outre, notre module Agile Sync permet de conserver certaines sources de vérité en dehors de Matrix Requirements qui peuvent être synchronisées. MatrixSDK offre la possibilité d'intégrer divers cadres d'automatisation des tests et permet aux équipes de créer leurs propres tableaux de bord.
Conclusion
Rédiger des scénarios de test efficaces est à la fois un art et une science. Elle nécessite un sens aigu du détail et une bonne compréhension du produit. Comme mentionné précédemment, un bon scénario de test est descriptif, clair, concis et sans ambiguïté. MatrixALM, avec ses nombreuses intégrations, fournit une plateforme pratique pour écrire, organiser et gérer vos cas de test. Si vous souhaitez en savoir plus, n'hésitez pas à réserver une démonstration!