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:

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:

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é.