Définir des scénarios de test et des priorités

Déterminez les éléments à tester, définissez vos scénarios de test et définissez les priorités.

Ramona Schwering

Dans l'article précédent, vous avez découvert les stratégies de test, le nombre de tests nécessaires pour tester une application, et comment trouver la solution la mieux adaptée pour obtenir les résultats les plus fiables en tenant compte de vos ressources. Cependant, cela ne nous donne qu'une idée de la quantité à tester. Vous devez encore déterminer exactement ce qu'il faut tester. Les trois critères suivants peuvent vous aider à comprendre à quoi vous attendre lors d'un test et à déterminer le type et le niveau de détail qui conviendraient le mieux:

1. Prenez soin de vous. Il s'agit de l'histoire d'utilisateur la plus générique ou principale de votre application, où l'utilisateur remarquera une erreur très rapidement.
2. Déterminez le niveau de détail. Si votre cas d'utilisation est vulnérable ou si une erreur peut causer d'importants dommages, expliquez-lui en détail comment l'utiliser.
3. Dans la mesure du possible, privilégiez les tests de niveau inférieur (tels que les tests unitaires et d'intégration) plutôt que les tests de niveau supérieur de bout en bout.

Le reste de cet article décrit ces critères et leur application lorsque vous définissez des scénarios de test.

Qu'est-ce qu'un scénario de test ?

Dans le domaine du développement logiciel, un scénario de test est une séquence d'actions ou de circonstances visant à confirmer l'efficacité d'un programme logiciel ou d'une application. Un scénario de test vise à s’assurer que le logiciel fonctionne comme prévu et que toutes ses fonctionnalités et fonctions fonctionnent correctement. Les testeurs ou développeurs de logiciels créent généralement ces scénarios de test pour garantir que le logiciel répond aux exigences et spécifications spécifiées.

Lorsqu'un scénario de test est exécuté, le logiciel effectue une série de vérifications pour s'assurer qu'il produit les résultats souhaités. Pendant ce temps, un test effectue les tâches suivantes:

• Validation : Processus de vérification approfondie du logiciel pour s'assurer qu'il fonctionne sans erreur. Déterminer si le produit créé répond à toutes les exigences non fonctionnelles nécessaires et atteint avec succès son objectif prévu est crucial. Il répond à la question suivante : « Le produit est-il bien conçu ? »
• Validation. Processus consistant à s'assurer que le produit logiciel répond aux normes nécessaires ou aux exigences de haut niveau. Elle consiste à vérifier si le produit réel est conforme au produit attendu. Fondamentalement, nous répondons à la question suivante : « Construisons-nous le bon produit pour les exigences de l'utilisateur ? »

Supposons que le programme ne fournisse pas le résultat attendu. Dans ce cas, le scénario de test correspond au messager : il signale un résultat infructueux, et le développeur ou le testeur doit examiner le problème et y trouver une solution. Considérez les vérifications et les actions comme des chemins que l'ordinateur suit, quel que soit le type de test. Les groupes de données ou de conditions d'entrée utilisés pour la vérification sont appelés "classes d'équivalence". Ils devraient obtenir un comportement ou des résultats similaires de la part du système testé. Les chemins d'accès spécifiques exécutés dans un test peuvent varier, mais ils doivent correspondre aux activités et aux assertions effectuées dans votre test.

Chemins de test: types de scénarios de test typiques

Dans le développement logiciel, un scénario de test est un scénario d'exécution de code à partir duquel un certain comportement est attendu et testé. Les scénarios de test se basent généralement sur trois scénarios.

Le premier est le plus connu, que vous utilisez probablement déjà. Il s'agit du parcours heureux, également appelé "scénario Happy Day" ou "parcours idéal". Il définit le cas d'utilisation le plus courant de votre fonctionnalité, votre application ou votre modification, ainsi que la façon dont cela doit se dérouler pour le client.

Le deuxième chemin de test le plus important à suivre dans vos scénarios de test est souvent omis, car il est inconfortable, comme son nom l'indique. Il s'agit du "chemin qui fait peur" ou, en d'autres termes, du test négatif. Ce chemin d'accès cible les scénarios entraînant un dysfonctionnement du code ou le passage à un état d'erreur. Tester ces scénarios est particulièrement important si vous avez des cas d'utilisation très vulnérables qui présentent un risque élevé pour les personnes concernées ou les utilisateurs.

Il existe d'autres chemins que vous pouvez connaître et envisager d'utiliser, mais ils sont généralement moins utilisés. Le tableau suivant les récapitule:

Scénario de test	Explication
Chemin en colère	Cela entraîne une erreur, mais une erreur attendue, par exemple si vous voulez vous assurer que la gestion des erreurs fonctionne correctement.
Chemin en défaut de paiement	Ce chemin d'accès prend en charge tous les scénarios de sécurité que votre application doit respecter.
Chemin désolé	Le chemin d'accès testant le scénario dans votre application ne reçoit pas suffisamment de données pour fonctionner (par exemple, le test de valeurs nulles).
Parcours oublié	Tester le comportement de votre application avec des ressources insuffisantes, par exemple en provoquant une perte de données
Chemin indécisif	Test avec un utilisateur qui tente d'effectuer des actions ou suit des histoires d'utilisateurs dans votre application, mais qui n'a pas terminé ces flux de travail. Cela peut se produire, par exemple, lorsque l'utilisateur interrompt son workflow.
Chemin glouton	Essayer d'effectuer des tests avec de grandes quantités d'entrées ou de données
Chemin stressant	Essayer de charger l'application par tous les moyens nécessaires jusqu'à ce qu'elle ne fonctionne plus (comme pour un test de charge)

Il existe plusieurs méthodes pour classer ces chemins. Voici deux approches courantes:

• Partitionnement des équivalences. Méthode de test qui classe les scénarios de test en groupes ou en partitions et, par conséquent, permet de créer des classes d'équivalence. Cela est basé sur l'idée que si un scénario de test dans une partition découvre un défaut, d'autres scénarios de test de la même partition révéleront probablement des défauts similaires. Étant donné que toutes les entrées d'une classe d'équivalence spécifique doivent présenter un comportement identique, vous pouvez réduire le nombre de scénarios de test. En savoir plus sur le partitionnement des équivalences
• Limitez l'analyse. Une méthode de test, également appelée analyse de la valeur limite, qui examine les limites ou les extrêmes des valeurs d'entrée afin de détecter les problèmes ou les erreurs potentiels pouvant survenir aux limites des capacités ou des contraintes du système.

Bonne pratique: Rédiger des scénarios de test

Un scénario classique écrit par un testeur contient des données spécifiques qui vous aideront à comprendre le contenu du test que vous voulez réaliser et, bien sûr, à l'exécuter. Un testeur type documente ses efforts de test dans un tableau. À ce stade, nous pouvons utiliser deux modèles qui nous aident à structurer nos scénarios de test et, plus tard, nos tests eux-mêmes:

• Organiser, agir, affirmer. Le modèle de test « arranger, agir, affirmer » (également connu sous le nom de « AAA » ou « Triple A ») est un moyen d'organiser les tests en trois étapes distinctes: organiser le test, puis effectuer le test et enfin, tirer des conclusions.
• Modèle Avec, quand, alors. Ce modèle est semblable au modèle AAA, mais il trouve des racines dans le développement axé sur le comportement.

Les prochains articles s'intéresseront plus en détail à ces modèles, dès que nous aborderons la structure d'un test lui-même. Si vous souhaitez approfondir ces modèles à ce stade, consultez ces deux articles: Arrange-Act-Assert: un modèle pour écrire des tests de qualité et Dès-quand-alors.

S'appuyant sur tous les enseignements de cet article, le tableau suivant résume un exemple classique:

Informations	Explication
Prérequis	Tout ce qui doit être fait avant d'écrire le test.
Objet testé	Quels éléments doivent être validés ?
Données d'entrée	Les variables et leurs valeurs.
Étapes à exécuter	Toutes les choses que vous ferez pour donner vie à votre test: toutes les actions ou interactions que vous effectuez dans vos tests.
Résultat attendu	Que doit-il se passer et quelles attentes doivent être satisfaites ?
Résultat réel	Que se passe-t-il réellement ?

Avec les tests automatisés, vous n'avez pas besoin de documenter tous ces scénarios de test de la manière dont un testeur a besoin, même s'il est sans aucun doute utile de le faire. Vous pouvez trouver toutes ces informations dans votre test si vous y êtes attentif. Transformons ce scénario classique en test automatisé.

Informations	Traduction en automatisation des tests
Prérequis	Toutes les choses dont vous avez besoin, organiser le test et réfléchir à ce qui est fourni pour que le scénario de votre test se produise.
Objet testé	Cet "objet" peut être une application, un flux, une unité ou un composant testé.
Données d'entrée	Valeurs des paramètres.
Étapes à exécuter	Toutes les actions et commandes exécutées dans votre test, les éléments sur lesquels vous agissez et la découverte de ce qui se passe lorsque vous faites certaines choses.
Résultat attendu	L'assertion que vous utilisez pour valider votre application, c'est-à-dire les éléments que vous déclarez dans votre application.
Résultat réel	Résultat de votre test automatisé.

Remarque :Cet article de blog a été rédigé par Ramona, avec la contribution et l'avis de Jecelyn Yeen (Twitter), Michael Hablich (Twitter) et Sofia Emelianova.