Méthode de rédaction des cas de test à partir des exigences

À l’image de la rédaction des exigences d’un projet, la rédaction des cas de test à partir des exigences transverses, comme des cas d’utilisations et des règles de gestion, peut s’avérer longue, minutieuse et complexe.

Nous avons vu dans un article précédent comment rédiger des exigences à partir d’un cahier des charges de « calcul d’aliments ». Dans cet article, nous allons donc étudier comment rédiger les cas de test correspondant aux exigences demandées.

Avant toute chose, chaque exigence exprimée doit être couverte par au moins un cas de test vérifiant son exactitude. Il est donc nécessaire de créer des cas de test pour les exigences situées dans le dossier des exigences (les exigences transverses, autres exigences fonctionnelles…), ainsi que pour les cas d’utilisations et pour les règles de gestion associées.

N’hésitez pas à vous reporter au premier article si vous ne comprenez pas ces termes. 😉

La structure d’un cas de test

Pour commencer, comment est structuré un cas de test ? Un cas de test est structuré de la manière suivante :

Comme vous pouvez le constater, un cas de test est constitué :

• D’étapes : pour notre exemple, il n’y en a qu’une mais l’exemple suivant portant sur le calcul de calories en présente plusieurs
• D’actions utilisateurs : qu’est-ce que l’utilisateur va faire à l’écran ?
• D’actions du système : qu’est-ce que l’action utilisateur va engendrer côté système ?

Pour l’ensemble de notre test, nous supposerons que les étapes de connexion ont déjà été réalisées.

Dans notre exemple de calcul de calories, nous avions rédigé toutes les exigences suivantes :

J’ai ajouté la colonne « Document » pour vous aider à vous repérer plus facilement dans les documents d’exigences à tester.  

Rédiger les exigences transverses 

Commençons par rédiger les exigences transverses présentes dans le dossier des exigences.  

Les exigences transverses ne sont pas forcément les plus faciles à écrire puisque certaines d’entre elles font appel à des cas de figure rares ou difficiles à reproduire en phase de test. Dans ce cas, il est nécessaire de se demander si vous voulez tester l’exhaustivité des cas – et donc obligatoirement créer l’ensemble des cas mentionnés dans les exigences – ou si vous souhaitez tester les cas les plus susceptibles de se produire ou les plus dangereux s’ils se réalisent. Normalement, vous répondez à ces questions en rédigeant la « stratégie de test » de la recette de votre projet.  

Voyons donc par exemple comment rédiger les cas de test correspondant aux RG01 et RG04.  

RG01 – Application en Français 

RG04 – Nombre d’utilisateurs connectés au maximum en simultané 

Cette exigence n’a pas été développée dans le dernier article, mais supposons qu’il est impossible de se connecter à plus de deux utilisateurs en simultané pour notre exemple, alors nous aurions ce cas de test :  

Nous venons donc de voir comment rédiger des cas de test correspondant à des exigences transverses.  

À présent, voyons comment rédiger les cas de test des cas d’utilisations puis de leurs règles de gestion respectives.  

Rédiger les cas d’utilisations

CU01 : Ajout d’une mensuration

Quels seraient donc les cas de test pour vérifier les exigences d’ajout d’une mensuration ?

Reprenons l’exigence précédemment rédigée :

Le cas de test correspondant à un cas d’utilisation doit vérifier que toutes les actions demandées sont effectuées correctement, l’exigence est bien remplie. Il est donc aussi nécessaire d’effectuer les vérifications par la suite.

Les vérifications d’affichage des informations se font dans la partie des règles de gestion et non dans les tests de cas d’utilisation où seule la bonne exécution du cas est vérifiée.

Par la suite nous allons nous concentrer sur les règles de gestion.

Rédiger les règles de gestion

Voyons maintenant les cas de test correspondant aux règles de gestion. Ils sont les plus longs et les plus complexes à écrire. Notre exemple étant simple, nos règles de gestion le sont aussi. Mais généralement, elles sont beaucoup plus complexes que celles-ci et demandent de très nombreuses vérifications.

RG01 – Menu des mensurations

Reprenons l’exigence précédemment rédigée :

Il faut impérativement vérifier chaque information mentionnée dans l’exigence.

Dans la RG01, nous avons donc 3 informations à vérifier :

• L’affichage du tableau avec les informations mentionnées
• Le tri du tableau par colonne
• La possibilité d’effectuer une recherche

RG02 – Page ajout mensuration

Reprenons l’exigence précédemment rédigée :

Le cas de test de vérification de la page d’ajout d’une mensuration va essentiellement vérifier les champs utilisables dans la page, leur type et le fait qu’ils sont obligatoires.

Nous avons donc vu comment rédiger les cas de test des exigences transverses puis des cas d’utilisations et enfin des règles de gestion appliquées aux cas d’utilisations.

Pour aller plus en profondeur dans la rédaction de nos cas de test :

• Nous pourrions également créer un exemple avec des informations précises à renseigner. Dans ce cas de figure, faites attention aux informations qui sont uniques. Si vous effectuez plusieurs recettes à la suite avec des informations précises qui doivent être uniques, vos cas de test vont se retrouver en erreur. Non pas à cause de votre livraison, mais de l’organisation de vos tests.
• Petite subtilité que je n’ai pas mentionnée : si vous avez plusieurs types d’utilisateurs différents (utilisateur simple, administrateur…), vous devez vérifier que chaque utilisateur PEUT réaliser les actions qui lui sont propres et NE PEUT PAS réaliser les actions qui ne lui sont pas propres.

Comme dans la rédaction des exigences, nous pouvons voir facilement que la rédaction des cas de test est très longue et minutieuse. Dans un prochain article, nous aborderons une méthode pour vérifier la couverture des exigences par les cas de test. En attendant, n’hésitez pas à rédiger les cas de test de notre exemple qui n’ont pas été développés pour que nous puissions échanger à ce propos.

Un autre article sur la structure des cas de test, dans un outil, est aussi à l’étude. Nous pourrions aborder, entre autres, comment créer des cas de test qui seraient appelés dans d’autres cas de test (comme par exemple la connexion, indispensable à tout cas de test !).