Cas de test – qu’est-ce qu’un cas de test et comment le rédiger ?

Le test d’un logiciel ou d’une application comprend la vérification de ses exigences fonctionnelles et non fonctionnelles. Pour valider ces exigences, les testeurs de logiciels doivent créer des cas de test efficaces en utilisant diverses techniques de conception de tests boîte blanche/boîte noire.

Dans ce texte, nous aborderons en détail les cas de test, leurs différents attributs et types.

Table des matières

1. Qu’est-ce qu’un scénario de test ?
2. Attributs des cas de test
3. Comment rédiger de bons scénarios de test ?

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

Un scénario de test est un ensemble de conditions permettant d’évaluer une caractéristique particulière d’un produit logiciel afin de déterminer sa conformité avec les exigences de l’entreprise.

Le scénario de test contient des hypothèses, des valeurs d’entrée et des résultats attendus sous une forme documentée qui couvre différents scénarios de test.

Une fois que les cas de test sont créés à partir des exigences, c’est aux testeurs qu’il incombe d’exécuter ces cas de test. Les testeurs lisent tous les détails du cas de test, exécutent les étapes du test, puis marquent le cas de test comme réussi ou échoué en fonction du résultat attendu et du résultat réel.

Attributs du cas de test

Examinons les différents attributs d’un scénario de test qui le composent et le rendent plus fiable, plus clair et plus concis, évitant ou réduisant ainsi toute forme de redondance.

1. TestCaseId – Identifiant unique du cas de test. Il s’agit d’un champ obligatoire qui identifie de manière unique le cas de test, par exemple TC_01.
2. Résumé du test – Résumé sans ambiguïté du cas de test. Ce champ est facultatif. En général, les cas de test ont un champ « Résumé du test » ou un champ « Description ».
3. Description – Description détaillée du cas de test. Ce champ définit l’objectif du cas de test, par exemple vérifiez que l’utilisateur peut se connecter avec un nom d’utilisateur et un mot de passe valides.
4. Préalable ou condition préalable – Ensemble de conditions préalables qui doivent être remplies avant que les étapes du test puissent être exécutées. Par exemple, lorsque vous testez la fonctionnalité d’une application après l’ouverture d’une session, vous pouvez avoir un champ de précondition qui dit « L’utilisateur doit être connecté à l’application ».
5. Etapes du test – Etapes détaillées pour exécuter un cas de test. Il s’agit du champ le plus important du scénario de test. Le testeur doit s’efforcer de rendre les étapes du test claires et sans ambiguïté afin qu’une autre personne puisse les suivre pendant l’exécution du test.
6. Données de test – la valeur des données de test utilisées dans le cas de test. Par exemple, lorsque vous testez la fonction de connexion, le champ de données de test peut contenir la valeur réelle du nom d’utilisateur et du mot de passe à utiliser pendant l’exécution du test.
7. Résultat escompté – Le résultat escompté où nous marquons le test comme réussi. Sur la base des étapes de test effectuées et des données de test utilisées, nous obtenons le résultat escompté, par exemple l’utilisateur doit réussir à se connecter et à naviguer jusqu’à la page d’accueil.
8. Résultat réel – le résultat réel après l’exécution des étapes du test. Ce champ n’est rempli que pendant l’exécution du test. Dans ce champ, nous inscrivons le résultat réel observé lors de l’exécution du cas de test.
9. Résultat du test – l’état de réussite ou d’échec du test. En fonction du résultat attendu et du résultat réel, le cas de test est marqué comme réussi ou non réussi.
   En plus de la valeur succès/échec, nous pouvons également avoir d’autres valeurs, telles que Différé, lorsqu’un cas de test est marqué pour une exécution ultérieure pour une raison quelconque. Bloqué lorsque l’exécution du cas de test est bloquée pour une autre raison dans l’application.
10. Statut d’automatisation – Identifiant d’automatisation – si l’application est automatisée ou non. Il s’agit d’un champ facultatif qui n’est utilisé que lorsque le projet est automatisé.
11. Date – La date à laquelle le test a été effectué. Ce champ permet de suivre les différentes itérations sur plusieurs cycles d’exécution des tests.
12. Exécuté par – le nom de la personne qui exécute le scénario de test. Ce champ est utile lorsque plusieurs membres de l’équipe travaillent sur une activité d’exécution de test.

Comment rédiger de bons scénarios de test ?

1. Technique de conception des tests

Suivez la technique de conception des tests la plus appropriée à votre organisation ou aux besoins spécifiques de votre projet, telle que l’analyse des seuils, la distribution des classes d’équivalence, le test de la table de décision, etc. Cela permettra de s’assurer que des normes et des procédures bien documentées sont mises en œuvre lors de l’élaboration des cas de test.

2. Des tests clairs et concis

Résumé du cas de test, description, étapes du test, résultats attendus, etc. doit être rédigé de manière claire et concise. Ils doivent être facilement compréhensibles par les différentes parties prenantes aux essais.

3. Nomenclature uniforme

Pour maintenir la cohérence entre les cas de test, nous devrions suivre une nomenclature uniforme et un ensemble de normes lors de l’écriture des cas de test.

4. Cas de test basique/atomique

Les cas de test doivent être aussi simples que possible. Ainsi, un scénario de test ne doit tester qu’une seule unité de fonctionnalité sans combiner ou chevaucher plusieurs parties testables.

5. Ne laissez aucune place à l’ambiguïté

Rédigez des cas de test avec un ensemble d’instructions claires. {homepageURL}Par exemple, au lieu de « Ouvrir la page d’accueil », tapez « Ouvrir la page d’accueil – http://www. .com dans votre navigateur et appuyez sur la touche Entrée ».

6. Pas de conditions préalables

Lorsque vous écrivez des scénarios de test, ne supposez aucune fonctionnalité, aucun prérequis ou aucun état de l’application. Attribuez plutôt les cas de test aux documents requis, tels que le SRS, les documents relatifs aux cas d’utilisation, etc.

7. Évitez la redondance

Ne répétez pas les cas de test, cela entraîne une perte de temps et de ressources. Cet objectif peut être atteint grâce à des cas de test bien planifiés et catégorisés.

8. Tests traçables

Utilisez une matrice de traçabilité pour vous assurer que 100 % des fonctionnalités de l’application dans le champ d’application des tests sont couvertes par les cas de test.

9. Assurer la couverture des différents aspects du logiciel

Veillez à ce que les différents aspects du logiciel testé, tels que les performances, la facilité d’utilisation, la robustesse, etc., soient couverts dans les cas de test, en plus de la fonctionnalité. en créant des cas de test de performance et des critères de référence, des cas de test de convivialité, des cas de test négatif, etc.

10. Données d’essai

Les données utilisées pour les essais doivent être aussi diverses et aussi proches que possible d’une utilisation en temps réel. Si vous disposez de données de test diversifiées, vous pouvez élaborer des scénarios de test plus fiables.