Comment écrire des cas de test et des rapports de bogues & Amp; Quels sont ses principaux composants

Dans cet article, nous allons en apprendre davantage sur les cas de test et les rapports de bogues et comment en rédiger de très bons afin qu’ils aident les testeurs et les développeurs impliqués dans le processus.

Qu’est-ce qu’un cas de test ?

Un scénario de test est un ensemble d’actions permettant de vérifier la fonctionnalité ou la fonctionnalité d’une application logicielle. Il contient des tests spécifiques, des données de test, une précondition, une postcondition, etc. Certains des outils de gestion de cas de test les plus populaires sont Quality Center, JIRA, etc. En fait, de nombreuses entreprises utilisent encore des feuilles Excel pour rédiger des cas de test.

Comment écrire des cas de test ?

L’écriture de cas de test dépend entièrement de ce qui est mesuré par le cas de test . En partageant les cas de test avec les testeurs et les développeurs, il est possible d’accélérer le processus de test, mais cela dépend en grande partie de la qualité de l’écriture des cas de test.

Vous trouverez ci-dessous certaines des parties intégrantes d’un scénario de test.

Étape 1 : ID du cas de test

Tous les cas de test doivent avoir un identifiant unique qui peut être utilisé pour les identifier. L’attribution d’un ID de cas de test indique clairement au développeur qu’il doit s’occuper du problème.

Etape 2 : Description du cas de test

Décrivez en détail l’unité, la caractéristique et la fonction qui sont testées ou vérifiées.

Étape 3 : Hypothèses/Conditions préalables

Dans cette étape, vous allez décrire toutes les conditions qui sont censées être remplies avant l’exécution du scénario de test. Par exemple, l’une des conditions pourrait être que seul un e-mail d’une organisation sera autorisé.

Étape 4 : Tester les données

Il fait référence aux variables et à leurs valeurs qui se trouvent dans le cas de test.

Etape 5 : Etapes d’exécution

N’oubliez pas que ces étapes sont exécutées du point de vue de l’utilisateur final, elles doivent donc être facilement reproductibles. Par exemple, la connexion au portail peut comporter les étapes suivantes.

1. Ouvrez le portail à l’aide de l’URL ou du lien interne
2. Saisissez votre nom d’utilisateur
3. Entrer le mot de passe
4. Cliquez sur ‘Connexion’ ou ‘Soumettre’.

Etape 6 : Résultat

Il montre le résultat auquel vous pouvez vous attendre après l’exécution de l’étape du cas de test. Lorsque vous entrez les bonnes informations de connexion, quel est le résultat attendu et où cela mène-t-il l’utilisateur.

Etape 7 : Résultat et post-conditions

Nous pouvons déterminer le cas de test en fonction du fait que les bonnes valeurs ont été saisies ou non. La post-condition est ce qui peut se produire à la suite des étapes d’exécution, s’ils pourront se connecter ou être envoyés sur une page où il leur sera demandé de saisir à nouveau les informations.

Étape 8 : réussite ou échec

Il détermine le statut réussite/échec en fonction de la comparaison entre le résultat attendu et le résultat réel.

Bonnes pratiques pour écrire de bons cas de test :

1. Les cas de test doivent être simples et transparents : Les cas de test doivent être aussi simples que possible. Assurez-vous d’utiliser un langage simple tel que « Cliquez sur la page d’accueil » ou « Entrez les données » afin qu’il soit facile de comprendre les étapes.
2. Créez des scénarios de test en pensant à l’utilisateur final : l’objectif de tout projet est de s’assurer qu’il répond aux attentes de l’utilisateur final. Un testeur doit garder à l’esprit l’utilisateur final lors de la création de cas de test.
3. Ne pas répéter les cas de test : si un cas de test est requis pour exécuter un autre cas de test, vous pouvez appeler le cas de test par l’ID de cas de test dans la colonne de précondition.
4. Tenez-vous en au document de spécifications : ne commettez pas l’erreur d’assumer les fonctionnalités et les caractéristiques de l’application logicielle.
5. Couverture à 100 % : Assurez-vous d’écrire des scénarios de test pour vérifier toutes les exigences logicielles mentionnées dans le document de spécifications.
6. Nommez les ID de cas de test afin qu’ils puissent être facilement identifiés lors du suivi des défauts ou de l’identification d’une exigence.
7. Faites réviser les cas de test par vos collègues.

Qu’est-ce qu’un rapport de bogue ?

La rédaction d’un bon rapport de bogue augmente les chances qu’il soit corrigé. Si le bogue n’est pas signalé de la bonne manière, il sera ignoré par le développeur en disant qu’il n’était pas clair.

Comment rédiger un bon rapport de bug ?

Un bon rapport de bogue doit être spécifique, informatif et reproductible.

Spécifique – Lorsque vous signalez le bogue, assurez-vous de ne pas vous attarder sur le problème en écrivant des choses qui ne sont pas nécessaires. Être spécifique. Allez droit au but.

Informatif – Assurez-vous d’attribuer un numéro unique à chacun des bogues dans votre rapport. Cela aide à identifier l’enregistrement de bogue. Lorsque vous utilisez un outil de rapport de bogue automatisé, un numéro vous sera attribué automatiquement.

Reproductible – Si le bogue ne peut pas être reproduit, il ne peut pas être corrigé du tout. Assurez-vous que le bogue est signalé étape par étape. Il y a des moments où il n’est pas possible de reproduire le bogue tel quel, dans un tel cas, vous devez mentionner la nature périodique du bogue tout en le mentionnant.

Testez le bogue sur des modules similaires – Les développeurs sont connus pour utiliser le même bogue pour des modules similaires. Dans ce cas, vous trouverez également le bogue dans d’autres modules. Il est même possible de trouver une version plus compliquée du bogue sur un module différent.

Écrivez clairement – Avant de cliquer sur le bouton Soumettre, il est impératif que vous relisiez le rapport de bogue au moins trois fois pour vous assurer qu’il est correct. Les mots que vous utilisez doivent être simples, clairs et faciles à comprendre. Essayez d’éviter le jargon, sauf si cela est absolument nécessaire.

Quels sont les composants d’un rapport de bogue ?

Vous trouverez ci-dessous un exemple de rapport de bogue qui peut être utilisé pour un rapport efficace.

Testeur – Nom et adresse e-mail.

Produit – Le produit dans lequel le bogue a été trouvé.

Version – La version du produit dans laquelle le bogue a été trouvé.

Composant – Principaux sous-modules du produit

Plate-forme – Sur quelle plate-forme matérielle le bogue a-t-il été trouvé ? PC, MAC, HP, Sun, etc., sont quelques-unes des plates-formes.

Système d’exploitation – Bien que Windows, Linux, Unix, etc. soient des systèmes d’exploitation, assurez-vous de mentionner la version du système d’exploitation dont il s’agit. Sans connaître la plate-forme exacte, cela peut devenir difficile pour le développeur car le bogue peut se comporter différemment selon l’environnement dans lequel l’application est utilisée.

Priorité – La priorité des bogues est généralement définie dans le format P1 à P5. P1 est le bogue avec la priorité la plus élevée tandis que P5 est un bogue qui ne nécessite pas une attention immédiate.

Gravité du bogue – L’impact du bogue peut être décrit de plusieurs façons.

Bloqueur – Vous ne pouvez pas faire plus de tests à ce sujet.

Critique – Ce bogue peut entraîner le blocage de l’application.

Majeur – Cela affecte gravement l’application.

Mineur – Ils ont peu d’impact sur le fonctionnement de l’application.

Statut du bogue – Lorsque vous vous connectez au système de suivi des bogues, le statut du bogue sera attribué à “Nouveau”. Après cela, le statut du bogue continue de changer – corrigé, vérifié, rouvert, ne peut pas être corrigé, etc.

Attribuer à : Mentionnez l’adresse e-mail du développeur.

Décrivez le problème : rédigez un résumé du bogue afin que le développeur puisse facilement comprendre le problème.

Conclusion:

Votre rapport de bogue doit être de haute qualité car il y a beaucoup à faire. Imaginez que vous rencontrez un problème différent du vrai parce que le rapport de bogue n’a pas été écrit clairement. Il doit y avoir une communication claire entre les testeurs et les développeurs afin que chacun d’eux sache à quoi s’attendre l’un de l’autre. Bien que la rédaction d’un bon rapport de bogue relève de la responsabilité d’un testeur, les développeurs doivent également transmettre leurs directives, le cas échéant.