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

Déterminez ce que vous devez tester, définissez vos scénarios de test et établissez des 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 plus adaptée pour avoir le plus de confiance dans les résultats, tout en tenant compte de vos ressources. Toutefois, cela ne nous donne qu'une idée de la quantité de tests à effectuer. Vous devez encore déterminer précisément ce que vous devez tester. Les trois critères suivants peuvent vous aider à comprendre à quoi vous attendre dans un test et à déterminer le type de test et le niveau de détail les plus adaptés:

1. Prenez soin de votre parcours heureux. Il s'agit de l'histoire d'utilisateur la plus générique ou principale de votre application, où l'utilisateur remarquera très rapidement une erreur.
2. Choisissez soigneusement le niveau de détail. Détaillez davantage votre cas d'utilisation s'il est vulnérable ou si une erreur pourrait causer des dommages importants.
3. Priorisez les tests de niveau inférieur, tels que les tests unitaires et d'intégration, par rapport aux tests de bout en bout de niveau supérieur dans la mesure du possible.

La suite de cet article explore ces critères et la façon dont ils s'appliquent lorsque vous définissez des scénarios de test.

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

En développement logiciel, un cas de test est une séquence d'actions ou de circonstances conçues pour confirmer l'efficacité d'un programme ou d'une application logicielle. Un cas 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 cas 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. Un test remplit les tâches suivantes:

• Validation Processus consistant à vérifier minutieusement un logiciel pour s'assurer qu'il fonctionne sans erreur. Il est essentiel de déterminer si le produit créé répond à toutes les exigences non fonctionnelles nécessaires et atteint son objectif. Il répond à la question suivante : "Construisons-nous le bon produit ?"
• Validation Processus visant à s'assurer que le produit logiciel répond aux normes ou aux exigences générales nécessaires. Il s'agit de vérifier si le produit réel correspond au produit attendu. En substance, nous répondons à la question suivante : "Créons-nous le bon produit pour répondre aux exigences des utilisateurs ?"

Supposons que le programme ne produise pas le résultat attendu. Dans ce cas, le scénario de test est le messager et signale un résultat négatif. Le développeur ou le testeur devra alors examiner le problème et 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 d'entrée ou de conditions utilisés pour la vérification sont appelés "classes d'équivalence". Ils doivent obtenir un comportement ou des résultats similaires du système testé. Les chemins 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.

Parcours de test: types de scénarios de test courants

En développement logiciel, un cas de test est un scénario d'exécution de code à partir duquel un certain comportement est attendu et testé. En général, trois scénarios peuvent servir de base à des scénarios de test.

Le premier est le plus connu et vous l'utilisez probablement déjà. Il s'agit du parcours heureux, également appelé "scénario heureux" ou "parcours d'or". Il définit le cas d'utilisation le plus courant de votre fonctionnalité, de votre application ou de votre modification, c'est-à-dire la façon dont elle doit fonctionner pour le client.

Le deuxième chemin de test le plus important à couvrir dans vos cas de test est souvent ignoré, car il est inconfortable, comme son nom peut l'indiquer. Il s'agit du "chemin effrayant", ou en d'autres termes, du test négatif. Ce chemin cible les scénarios qui provoquent un comportement incorrect du code ou 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 courants. Le tableau suivant récapitule ces différences:

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

• Partitionnement par équivalence Méthode de test qui catégorise les scénarios de test en groupes ou en partitions, et qui permet ainsi de créer des classes d'équivalence. Cette approche repose sur l'idée que si un cas de test d'une partition révèle un défaut, d'autres cas 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 par équivalence
• Analyse limitée Méthode de test, également appelée analyse des valeurs limites, qui examine les limites ou les valeurs extrêmes des valeurs d'entrée afin de détecter les problèmes ou erreurs potentiels qui pourraient survenir aux limites des capacités ou des contraintes du système.

Bonne pratique: Écrire des scénarios de test

Un cas de test classique rédigé par un testeur contient des données spécifiques pour vous aider à comprendre le contenu du test que vous souhaitez effectuer et, bien sûr, à l'exécuter. Un testeur typique 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, puis nos tests eux-mêmes:

• Modèle Organiser, agir, affirmer Le modèle de test "organiser, agir, affirmer" (également appelé "AAA" ou "Triple A") consiste à organiser les tests en trois étapes distinctes: organiser le test, puis l'exécuter, et enfin tirer des conclusions.
• Modèle Avec, Quand, Alors Ce modèle est semblable au modèle AAA, mais s'inspire du développement basé sur le comportement.

De futurs articles traiteront plus en détail ces modèles, dès que nous aurons abordé la structure d'un test. Si vous souhaitez approfondir ces modèles à ce stade, consultez ces deux articles : Arrange-Act-Assert: A pattern for writing good tests (Arrange-Act-Assert : un modèle pour écrire de bons tests) et Given-When-Then (Given-When-Then : un modèle pour écrire de bons tests).

D'après tous les enseignements de cet article, le tableau suivant résume un exemple classique:

Dans les tests automatisés, vous n'avez pas besoin de documenter tous ces cas de test de la même manière qu'un testeur, même si cela est sans aucun doute utile. Vous trouverez toutes ces informations dans votre test si vous y prêtez attention. Transposons donc ce scénario de test classique en test automatisé.