Comment écrire des cas de test

Il ne fait aucun doute que l’écriture des cas de test efficaces est la compétence indispensable pour les spécialistes de l’assurance qualité. Comme toute compétence, elle peut être acquise et améliorée. Les principaux principes et astuces de la rédaction de Test Case efficaces seront considérés dans cet article.

Avant de le commencer, comprenons bien ce qu’est le Test Case. Imaginez que vous devez tester une certaine fonctionnalité de l’application. Vous devez, étape par étape, initier la situation où elle pourrait être mise en œuvre.

Pour faire simple, le Test Case est un ensemble de telles étapes (actions) bien conçues et faciles à comprendre, exécutées pour vérifier une caractéristique ou une fonctionnalité particulière de votre application logicielle. Gardez à l’esprit « bien conçu » et « facilement compréhensible ». Cela a un sens important comme vous le verrez un peu plus tard.

Donc, maintenant nous pouvons commencer. Ici nous allons diviser le cas de test aux composants et essayer d’analyser ce qui doit être fait ainsi que ce qui ne doit pas l’être pour l’écrire avec une grande efficacité.

Identification du cas de test

C’est un numéro unique du cas de test dans le système de gestion des tests ou dans le document. En règle générale, tous les systèmes modernes de gestion des tests comme Jira, TestRail et Zephyr attribuent automatiquement l’ID aux nouveaux cas de test créés. Ainsi, il n’y a aucune possibilité de faire une erreur avec ce composant.

Mais, il faut noter, que sur certains projets est encore utilisé Excel pour les tests. C’est pourquoi vous devez toujours vous rappeler la règle suivante :  » Il n’y a pas de cas de test avec le même ID dans votre système de gestion des tests. Même ceux-ci sont des cas de test de projets terminés ».

Titre du cas de test

Un titre fort est l’attribut obligatoire du cas de test efficace. Qu’est-ce que cela signifie ? Les principales caractéristiques du Titre fort sont : facile à comprendre et laconique. En plus de cela, le Test Case Title doit représenter le nom du module ou le domaine fonctionnel que vous allez vérifier.

Imaginons que nous ayons pour tâche de vérifier ce qui se passera si nous entrons des symboles invalides comme $,&, * dans le champ « e-mail » du formulaire d’enregistrement du système de gestion des tests EasyQA. Selon les principes mentionnés ci-dessus, le titre du cas de test devrait ressembler à : « Champ e-mail entrée invalide dans le formulaire d’inscription ».

Regardons l’exemple d’un titre pas fort. « Entrée des symboles du champ E-mail « $&* » dans le formulaire d’enregistrement de l' »EasyQA ». Ici, nous avons au moins deux erreurs.

• La longueur excessive du titre. Il n’est pas nécessaire de mentionner « EasyQA », car ce cas de test fait partie du plan de test de ce système de gestion des tests. Ainsi, tous les cas de test sont concernés par « EasyQA ».
• Concrétisation des symboles spéciaux « $&* ». D’autres symboles invalides pourraient également être saisis pour l’exécution de ce type de cas de test. Ainsi, « symboles invalides » est une définition plus appropriée pour ce titre.

Certains systèmes de gestion des tests, dont EasyQA, simplifient ce processus en créant un champ de module spécial pour chaque cas de test.

Le plan de test est divisé en modules, qui comprennent des cas de test particuliers. C’est pourquoi il est plus facile de créer un titre fort pour le cas de test.

Description du cas de test

Avant de commencer les tests, vous devez mentionner tous les détails sur ce que vous allez tester. Il s’agit de : Les données de test à utiliser, les conditions préalables (Presteps), les détails de l’environnement de test, les outils de test.

Si vous donnez les données de test à utiliser le cas échéant pour le cas de test dans la description du cas de test ou avec l’étape spécifique du cas de test, vous vous aiderez non seulement vous-même, mais aussi vos collègues-testeurs. Il y a une grave erreur à écrire des cas de test uniquement pour soi-même.

Les conditions préalables (Presteps) décrivent différents types de dépendances de l’exécution du test :

• Une configuration spéciale doit être effectuée
• Dépendances de tout autre cas de test – le cas de test doit-il être exécuté avant/après un autre cas de test
• Dépendance des données de l’utilisateur – quelle page l’utilisateur doit-il commencer son parcours ; l’utilisateur doit être connecté.

L’environnement de test est une configuration de logiciels et de matériel permettant aux équipes de test d’exécuter des cas de test. En d’autres termes, il prend en charge l’exécution des tests avec le matériel, les logiciels et le réseau configurés.

Lorsque les gens mentionnent les outils de test, les tests automatisés sont souvent suggérés. Bien sûr, ils sont précédemment concernés par ce type de test. Mais il existe aussi des outils simples pour les tests manuels. Les outils de mind mapping comme Xmind, les gestionnaires de captures d’écran comme Jing sont faciles à utiliser même pour les nouveaux venus dans le domaine de l’assurance qualité. Quoi qu’il en soit, si un outil spécial est obligatoire pour le test, vous devriez le mentionner dans la description du cas de test.

Bien sûr, si le même outil est utilisé pour l’exécution d’un certain groupe de cas de test, il serait préférable de le décrire sur le module/sous-module de test ou même dans le plan de test.

Il y a une sorte d’erreur typique sur laquelle vous devriez vous concentrer. Certains testeurs avec moins d’expérience confondent Steps avec le Presteps. Faites une note, que Presteps est le moyen d’obtenir la situation l’exécution du cas de test pourrait être lancée. Les étapes sont le moyen le plus efficace pour obtenir le résultat réel de l’exécution du cas de test.

Par exemple, si nous devons tester les capacités fonctionnelles de l’utilisateur enregistré, il y aurait une erreur à créer des étapes spéciales d’enregistrement de l’utilisateur pour chaque cas de test dans le module approprié. La bonne décision est de l’afficher dans les Presteps pour tous les modules de Suites de test de l’utilisateur enregistré : l’utilisateur doit être enregistré. Le processus d’enregistrement est vérifié dans la suite de test particulière.

Comme il a été mentionné précédemment, les étapes sont le chemin vers le résultat attendu. Une autre chose qu’il faut rappeler Les étapes dans le cas de test efficace sont bien conçues et facilement compréhensibles. Ces deux points sont la base pour comprendre comment planifier les Étapes pour vos Cas de Test.

Les principaux attributs des Étapes bien conçues :

1. Une quantité optimale d’Étapes. Pas besoin d’écrire des étapes supplémentaires ainsi que l’étape « manger ». Les choses paraissaient évidentes pour vous, ne pouvaient pas être aussi claires pour vos collègues.
2. Un scénario de test ne couvre qu’une seule fonctionnalité indépendante. C’est une erreur de vérifier différentes fonctionnalités dans un seul scénario de test.
3. Les étapes sont facilement exécutables.
4. Les étapes ne doivent pas seulement couvrir le flux fonctionnel mais aussi chaque point de vérification qui doit être testé.

Les principaux attributs des étapes faciles à comprendre :

1. Les étapes vont droit au but. Vous ne devriez pas écrire un essai pour décrire vos Étapes.
2. Expression claire. Vous devriez éviter d’utiliser l’ambiguïté dans vos étapes de scénario de test.
3. Compréhensible même pour les débutants. Vos collègues, qui ne sont probablement pas aussi expérimentés, devraient être en mesure de comprendre comment exécuter chaque étape.

Les performances de l’application après l’exécution des étapes de test ci-dessus sont affichées dans le résultat attendu. Ainsi, avant d’écrire des cas de test, vous devriez pleinement reconnaître quelle page/écran vous vous attendez à voir apparaître après le test et, toutes les mises à jour que vous attendez comme résultat à faire dans les systèmes back-end ou la base de données.

J’espère que vous vous souvenez qu’un cas de test couvre une fonctionnalité indépendante. C’est pourquoi, ce serait une erreur d’écrire un Test Case avec plus d’un résultat attendu.

Les commentaires/conditions postales ne sont pas des composants obligatoires du Test Case, mais cela rend vraiment plus élevée l’efficacité de votre Test Case. Ici, vous pouvez mettre des informations utiles supplémentaires comme des captures d’écran et des descriptions pour fournir aux développeurs les informations dont ils auront besoin pour corriger les défauts trouvés.

Les Post Conditions sont également utilisées pour donner une instruction de guidage pour restaurer le système à son état d’origine pour qu’il n’interfère pas avec les tests ultérieurs. Par exemple, cela est tout à fait utile si vous mentionnez les modifications à apporter à une donnée de test pour qu’elle puisse être utilisée pour un cas de test ultérieur pour la même fonctionnalité.

Différents systèmes de gestion des tests offrent des variantes variées de champ de cas de test. Le cas de test dans l’outil de gestion des tests EasyQA a les suivants:

1. Titre
2. Module – pour choisir le module auquel notre cas de test se réfère. – Si vous appuyez sur Ajouter un cas dans le module, ce champ sera saisi par défaut.
3. Type – sélectionner un type de cas de test dans la liste déroulante selon la description suivante :

• Positif est un cas de test utilisant uniquement des données correctes.
• Négatif est un cas de test utilisant non seulement des données correctes.
• La limite est un cas de test utilisant des valeurs max/min.
• L’intégration est un composant du test d’intégration.
• UI est le test d’une interface graphique utilisateur.
• La localisation est le test de lieux, de langues, etc.

1. Pré-étapes
2. Étapes
3. Résultat attendu

Dans cette image, vous pouvez voir le processus d’ajout de cas de test avec les champs remplis.

Une fois que vous avez ajouté les cas de test, vous pouvez les choisir avec les cases à cocher correspondantes. Après avoir choisi un ou plusieurs cas de test, vous pouvez les déplacer où vous le souhaitez. Vous êtes en mesure de les modifier ou de les supprimer.

Maintenant, lorsque vous avez quelques connaissances théoriques sur l’écriture de cas de test, essayez de les utiliser pour la prochaine décision de tâche.

Données de la tâche:

1. Il existe un système de gestion des tests « EasyQA » – https://geteasyqa.com/
2. Vous devez vérifier la capacité de l’utilisateur enregistré à créer un nouveau plan de test pour le projet appelé « Blogger » selon la spécification.
3. L’e-mail de l’utilisateur est « [email protected] », le mot de passe est « gEORGe52 »

Voyons comment créer chaque étape.

Bien sûr, l’ID unique sera automatiquement attribué par le système de gestion des tests que vous utilisez.

Premièrement, vous devez choisir le titre, le module et le scénario de test appropriés pour le cas de test. Naturellement, le module pourrait être « Utilisateur enregistré ». Et les autres cas de test testant la fonctionnalité d’utilisateur enregistré seront mis à ce module. Le titre fort ressemble à « capacité de création de plan de test ». Le scénario de test est positif.

De même que vous devez vérifier la fonctionnalité d’utilisateur enregistré, vous devez afficher le chemin vers l’enregistrement dans les Pre Steps. Ces Pré-étapes seront les mêmes pour tous les cas de test du module  » Utilisateur enregistré « .

Dans le champ Étapes, vous devez montrer comment atteindre le résultat attendu.

Déterminons le Résultat attendu comme étant  » L’utilisateur enregistré a la capacité de créer un plan de test « .

Nous pouvons voir le résultat de nos actions en utilisant les outils de gestion des tests EasyQA.

Envisageons quelques cas de test typiques basés sur un scénario différent.

Les données de la tâche sont presque les mêmes que celles de la tâche précédente :

1. Il existe un système de gestion des tests « EasyQA » – https://geteasyqa.com/
2. Le formulaire « Sign Up » doit être testé.
3. La longueur minimale du mot de passe est de 6 symboles. La longueur maximale est de 128 symboles
4. Vous ne pouvez utiliser que des lettres de l’alphabet latin de A à Z et des chiffres dans les champs « Login », « Password », « Confirm Password ».

C’est ici que nous considérons quelques spécificités de ce type de processus de création de cas de test.

Le formulaire « Sign Up » de EasyQA a le champ obligatoire suivant :  » Prénom « ,  » Nom « ,  » Email « ,  » Mot de passe  » et  » Confirmer le mot de passe « . En plus de cela, il y a d’autres champs comme « Société » et « Pays », qui ne sont pas obligatoires, mais qui doivent également être testés. Vous devez donc diviser votre module  » Sign Up  » Test Suite en sous-modules appropriés.

Tentez d’analyser quelques scénarios typiques : positif, négatif et limite.

Selon le scénario positif, l’utilisateur non inscrit ne saisit que des données valides dans tous les champs. Vous n’aurez donc pas de problèmes avec la création de ce type de cas de test. Vous pouvez voir comment cela pourrait se présenter sur l’image ci-dessous.

Le résultat attendu pour ce cas de test est « La saisie de lettres latines et de chiffres est possible dans le champ « Mot de passe » ».

Mais, que se passera-t-il si l’utilisateur saisit les symboles invalides dans l’un des champs mentionnés précédemment ? Nous pouvons le vérifier en exécutant des cas de test basés sur le scénario négatif. En fait, il existe de nombreuses variantes de saisie invalide. On pourrait les considérer dans un article particulier. En voici seulement quelques-unes :

• « &%$ » saisie de symboles
• Saisie d’espaces
• Saisie de champs vides
• Combinaisons de saisie de symboles invalides et non valides
• Saisie de lettres dans d’autres cas, etc.

A l’image ci-dessous est représenté un exemple de cas de test négatif.

Le résultat attendu pour ce cas de test est « La saisie invalide est impossible dans le champ « Mot de passe » ».

Prêtez attention à la condition – restriction de la longueur du mot de passe (6-128 symboles). Est-il possible d’être enregistré avec un mot de passe de seulement 3 symboles ? Qu’en est-il du mot de passe de 150 symboles ? Les cas de test écrits par la technique de conception Boundary Value Testing vous donnent des réponses à ces questions.

L’idée de base du Boundary Value Testing est de sélectionner les valeurs des variables d’entrée à leur : minimum, juste au-dessus du minimum, juste en dessous du maximum, maximum. Dans notre exemple, vous devriez écrire des cas de test pour les situations avec :

• 5 symboles d’entrée de mot de passe
• 6 symboles d’entrée de mot de passe
• 128 symboles d’entrée de mot de passe
• 129 symboles d’entrée de mot de passe.

Regardez l’image ci-dessous pour voir comment ressemble un cas de test écrit selon cette technique.

Le résultat attendu pour ce cas de test est « Le message d’information « La longueur minimale du mot de passe est de 6 symboles » s’affiche ».

Différentes fonctionnalités comme la recherche, le classement, la pagination doivent également être testées. Ces cas de test pourraient également être écrits selon les scénarios que nous avons considérés auparavant. Ils vérifient le fonctionnement normal de :

• Champs de recherche
• Boutons de page
• Flèches
• Rapports par nom (A à Z, Z à A)
• Rapports par prix (le plus bas en premier, le plus haut en premier)
• Boutons de menu du tableau de bord et de la barre latérale, etc.

Retournez au système de gestion des tests EasyQA et écrivez un cas de test simple pour vérifier la fonctionnalité de filtrage du bouton « Closed issues ». Le voici.

Le résultat attendu pour ce cas de test est « Seuls les problèmes fermés sont affichés dans le menu du tableau de bord ».

Le test de sécurité est souvent assuré par des outils de test automatisé spéciaux comme Vega, Google Nogotofail, Wapiti, etc. Mais en utilisant vos compétences d’activité mentale, vous pouvez écrire un cas de test simple pour vérifier certains paramètres de sécurité du site Web. Revenez encore une fois à EasyQA Test Management System. Vous pouvez voir un exemple d’un tel cas de test ci-dessous.

Prêtez attention aux étapes. Le résultat attendu pour ce cas de test est  » Le formulaire de connexion EasyQA s’affiche après avoir copié/collé l’URL d’un navigateur à un autre « . Il n’y a donc pas d’accès au compte utilisateur.

Il existe de nombreux outils de gestion des tests pour aider les testeurs dans leur travail. EasyQA vous offre un large éventail de fonctionnalités utiles supplémentaires :

1. Exporter un plan de test préparé au format CSV en appuyant sur un bouton
2. Importer un plan de test préparé vers notre système.
3. Affichage des cas de test selon différents critères :
4. Faire des rapports de crash
5. Distribution de la construction
6. Système de suivi des bugs
7. Exécution des tests
8. Génération de rapports
9. Intégration rapide et facile avec vos outils existants.

Pour faire simple, EasyQA est plus qu’un système de gestion des tests. C’est un environnement pour un travail agréable et efficace.

1. Gardez à l’esprit , que les cas de test sont exécutés également par vos collègues
2. Utiliser un titre fort
3. Porter attention aux étapes préalables et aux conditions préalables
4. Le cas de test couvre une fonctionnalité et
5. Le cas de test n’a qu’un seul résultat attendu
6. Ecrire des étapes bienconçues et facilement compréhensibles
7. N’oubliez pas de mettre toutes les informations utiles dans les commentaires ou les postconditions
8. Utilisez des illustrations et des outils de test simples si cela est nécessaire
9. Le scénario de test doit être réutilisable
10. Commencez à vous entraîner

Voulez-vous écrire des scénarios de test efficaces ? Commencez simplement à le faire. Et nous nous ferons un plaisir de vous aider.

TRY EASY QA