Comment rédiger des cas de test: le guide ultime avec des exemples

how write test cases

Dans ce didacticiel pratique approfondi sur la façon d'écrire des cas de test, j'ai couvert les détails de ce qu'est un scénario de test, sa définition standard et les techniques de conception de cas de test.

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

Un cas de test a des composants qui décrivent une entrée, une action et une réponse attendue, afin de déterminer si une fonctionnalité d'une application fonctionne correctement.

Un cas de test est un ensemble d'instructions sur «COMMENT» pour valider un objectif / une cible de test particulier, qui, une fois suivi, nous dira si le comportement attendu du système est satisfait ou non.

Liste des didacticiels couverts dans cette série de rédaction de cas de test:

Comment écrire:

Tutoriel n ° 1: Qu'est-ce qu'un scénario de test et comment écrire des scénarios de test (ce tutoriel)
Tutoriel n ° 2: Exemple de modèle de scénario de test avec des exemples (Télécharger) (Doit lire)
Tutoriel n ° 3: Écriture de cas de test à partir d'un document SRS
Tutoriel n ° 4: Comment écrire des cas de test pour un scénario donné
Tutoriel n ° 5: Comment vous préparer à la rédaction de cas de test
Tutoriel n ° 6: Comment rédiger des cas de test négatifs

Exemples:

Tutoriel n ° 7: Plus de 180 exemples de cas de test pour les applications Web et de bureau
Tutoriel n ° 8: Plus de 100 scénarios de test prêts à être exécutés (liste de contrôle)

Techniques d'écriture:

Tutoriel n ° 9: Graphique de cause à effet - Technique d'écriture de cas de test dynamique
Tutoriel n ° 10: Technique de test de transition d'état
Tutoriel n ° 11: Technique de test de matrice orthogonale
Tutoriel n ° 12: Technique de détermination des erreurs
Tutoriel n ° 13: Technique de conception de test de table de validation sur le terrain (FVT)

Scénarios de test Vs Test:

Tutoriel n ° 14: Cas de test vs scénarios de test
Tutoriel n ° 15: Différence entre plan de test, stratégie de test et scénario de test

Automatisation:

Tutoriel n ° 16: Comment sélectionner les scénarios de test corrects pour les tests d'automatisation
Tutoriel n ° 17: Comment traduire des cas de test manuels en scripts d'automatisation

Outils de gestion des tests:

Tutoriel n ° 18: Meilleurs outils de gestion des tests
Tutoriel n ° 19: TestLink pour la gestion des cas de test
Tutoriel n ° 20: Création et gestion de cas de test à l'aide de HP Quality Center
Tutoriel n ° 21: Exécution de cas de test à l'aide d'ALM / QC

Cas spécifiques au domaine:

Tutoriel n ° 22: Cas de test pour une application ERP
Tutoriel n ° 23: Cas de test d'application JAVA
Tutoriel n ° 24: Analyse de la valeur limite et partitionnement d'équivalence

Continuons avec le premier didacticiel de cette série.

Outils recommandés:

Avant de poursuivre le processus d'écriture de cas de test, nous vous recommandons de télécharger cet outil de gestion de cas de test. Cela facilitera le processus d'écriture de vos scénarios de test mentionné dans ce tutoriel:

# 1) TestRail

=> Télécharger l'outil de gestion des cas de test TestRail

# 2) TestMonitor

Gestion des tests en ligne de haut niveau. Révolutionnaire facile.

TestMonitor est un outil de gestion de test de bout en bout pour chaque organisation. Une approche simple et intuitive des tests. Que vous implémentiez un logiciel d'entreprise, que vous ayez besoin d'un contrôle qualité, que vous développiez une application de qualité ou que vous ayez simplement besoin d'un coup de main dans votre projet de test, TestMonitor est là pour vous.

=> Visitez le site Web de TestMonitor

Ce que vous apprendrez:

• Qu'est-ce qu'un scénario de test et comment écrire des scénarios de test?
  • Pourquoi écrivons-nous des tests?
  • Comment rédiger des cas de test?
  • Format de base de l'instruction de cas de test
• Conseils pour rédiger des tests
  • • # 1) Restez simple mais pas trop simple; rendre complexe mais pas trop complexe:
    • # 2) Après avoir documenté les cas de test, passez en revue une fois en tant que testeur:
    • # 3) Liez et soulagez les testeurs:
    • # 4) Soyez un contributeur:
    • # 5) N'oubliez jamais l'utilisateur final:
• Comment atteindre l'excellence dans la documentation des cas de test
  • Trucs et astuces utiles
    • # 1) Votre document de test est-il en bon état?
    • # 2) N'oubliez pas de couvrir les cas négatifs
    • # 3) Avoir des étapes de test atomique
    • # 4) Hiérarchisez les tests
    • # 5) La séquence compte
    • # 6) Ajouter l'horodatage et le nom du testeur aux commentaires
    • # 7) Inclure les détails du navigateur
    • # 8) Conservez deux feuilles séparées - «Bugs» et «Résumé» dans le document
• Comment NE PAS écrire de tests
  • 3 Problèmes les plus courants dans les cas de test
    • # 1) Étapes composites
    • # 2) Le comportement de l'application est considéré comme un comportement attendu
    • # 3) Plusieurs conditions dans un cas
• Comment améliorer l'efficacité des cas de test
  • Collection de documents pour la rédaction de tests
  • Exemple réel
  • Document de cas de test
  • Collecte de données de test
• Importance de la normalisation des cas de test
  • Raisons de réutiliser les cas de test
  • Qu'est-ce qu'un test standard dans les tests Web?
  • Conclusion
  • lecture recommandée

Qu'est-ce qu'un scénario de test et comment écrire des scénarios de test?

Ecrire des cas efficaces est une compétence. Et vous pouvez l'apprendre grâce à l'expérience et à la connaissance de l'application testée.

Pour obtenir des instructions de base sur la façon d'écrire des tests, veuillez consulter la vidéo suivante:

Les ressources ci-dessus devraient nous donner les bases du processus d'écriture de test.

Niveaux du processus d'écriture du test:

• Niveau 1: Dans ce niveau, vous écrirez le cas de base de la spécification disponible et documentation utilisateur.
• Niveau 2: C'est le étape pratique dans lequel les cas d'écriture dépendent du flux fonctionnel et système réel de l'application.
• Niveau 3: C'est à ce stade que vous regrouperez certains cas et rédiger une procédure de test . La procédure de test n'est rien d'autre qu'un groupe de petits cas, peut-être un maximum de 10.
• Niveau 4: Automatisation du projet. Cela minimisera l'interaction humaine avec le système et ainsi l'AQ peut se concentrer sur les fonctionnalités actuellement mises à jour pour tester plutôt que de rester occupé avec les tests de régression.

Pourquoi écrivons-nous des tests?

L'objectif de base de la rédaction de cas est pour valider la couverture de test d'une application.

Si vous travaillez dans une organisation CMMi, les normes de test sont suivies de plus près. L'écriture de cas apporte une sorte de standardisation et minimise l'approche ad hoc dans les tests.

Comment rédiger des cas de test?

Des champs:

• ID de cas de test
• Unité à tester: Que vérifier?
• Hypothèses
• Données de test: Variables et leurs valeurs
• Étapes à exécuter
• résultat attendu
• Résultat actuel
• Réussite / échec
• commentaires

Format de base de l'instruction de cas de test

Vérifier
Utilisant (nom de l'outil, nom de la balise, boîte de dialogue, etc.)
Avec (conditions)
À (ce qui est retourné, montré, démontré)

Vérifier: Utilisé comme premier mot de l'instruction de test.
Utilisant: Identifier ce qui est testé. Vous pouvez utiliser «entrer» ou «sélectionner» ici au lieu d’utiliser selon la situation.

Pour toute application, vous devez couvrir tous les types de tests comme:

• Cas fonctionnels
• Cas négatifs
• Cas de valeur limite

En écrivant ces tous vos Les TC doivent être simples et faciles à comprendre .

meilleurs nettoyeurs de registre pour windows 10

************************************************

Conseils pour rédiger des tests

L'une des activités les plus fréquentes et les plus importantes d'un testeur de logiciel (personne SQA / SQC) est d'écrire des scénarios et des cas de test.

Il existe des facteurs importants et critiques liés à cette activité majeure. Examinons d'abord ces facteurs à vol d'oiseau.

Facteurs importants impliqués dans le processus d'écriture:

a) Les TC sont sujets à des révisions et mises à jour régulières:

Nous vivons dans un monde en constante évolution et il en va de même pour les logiciels. Le changement des exigences logicielles a un impact direct sur les cas. Chaque fois que les exigences sont modifiées, les TC doivent être mis à jour.

Pourtant, ce n'est pas seulement le changement de l'exigence qui peut entraîner la révision et la mise à jour des TC. Au cours de l'exécution des TC, de nombreuses idées surgissent dans l'esprit et de nombreuses sous-conditions d'un seul TC peuvent être identifiées. Tout cela entraîne une mise à jour des TC et parfois même l’ajout de nouveaux TC.

De plus, lors des tests de régression, plusieurs correctifs et / ou ondulations exigent des TC révisés ou nouveaux.

b) Les TC ont tendance à être distribués parmi les testeurs qui les exécuteront:

Bien entendu, il n'y a guère de situation dans laquelle un seul testeur exécute tous les TC. Normalement, plusieurs testeurs testent différents modules d'une même application. Les TC sont donc répartis entre les testeurs en fonction de leurs domaines respectifs de l'application testée.

Certains TC qui sont liés à l'intégration de l'application peuvent être exécutés par plusieurs testeurs tandis que les autres TC peuvent être exécutés uniquement par un seul testeur.

c) Les TC sont enclins au clustering et au groupage:

Il est normal et courant que les TC appartenant à un même scénario de test exigent généralement leur exécution dans une séquence spécifique ou sous la forme d'un groupe. Il peut y avoir certains prérequis d'un TC qui exigent l'exécution d'autres TC avant de s'exécuter lui-même.

De même, conformément à la logique métier de l'AUT, un seul TC peut contribuer à plusieurs conditions de test et une seule condition de test peut être constituée de plusieurs TC.

d) Les CT ont tendance à être interdépendants:

Il s'agit également d'un comportement intéressant et important des TC, indiquant qu'ils peuvent être interdépendants les uns des autres. Des applications moyennes à grandes avec une logique métier complexe, cette tendance est plus visible.

Le domaine le plus clair de toute application où ce comportement peut être définitivement observé est l'interopérabilité entre différents modules de la même ou même des applications différentes. En termes simples, partout où les différents modules d'une seule application ou de plusieurs applications sont interdépendants, le même comportement se reflète également dans les TC.

e) Les TC sont susceptibles d'être distribués entre les développeurs (en particulier dans un environnement de développement piloté par les tests):

Un fait important concernant les TC est que ceux-ci ne doivent pas seulement être utilisés par les testeurs. Dans le cas normal, lorsqu'un bogue est en cours de correction par les développeurs, ils utilisent indirectement le TC pour résoudre le problème. De même, si le développement piloté par les tests est suivi, alors les TC sont directement utilisés par les développeurs afin de construire leur logique et de couvrir tous les scénarios dans leur code qui sont adressés par les TC.

Conseils pour rédiger des tests efficaces:

En gardant à l'esprit les 5 facteurs ci-dessus, voici quelques conseils pour rédiger des TC efficaces.

Commençons!!!

# 1) Restez simple mais pas trop simple; rendre complexe mais pas trop complexe:

Cette affirmation semble un paradoxe. Mais, je promets que ce n'est pas le cas. Gardez toutes les étapes des TC atomiques et précises. Mentionnez les étapes avec la séquence correcte et la correspondance correcte avec les résultats attendus. Le cas de test doit être explicite et facile à comprendre. C'est ce que je veux dire pour faire simple.

Désormais, en faire un moyen complexe de l'intégrer au plan de test et aux autres TC. Reportez-vous aux autres TC, aux artefacts pertinents, aux interfaces graphiques, etc. où et quand cela est nécessaire. Mais faites-le de manière équilibrée. Ne faites pas aller et venir un testeur dans la pile de documents pour compléter un seul scénario de test.

En revanche, ne laissez même pas le testeur documenter ces TC de manière très compacte. Lorsque vous rédigez des TC, n'oubliez jamais que vous ou quelqu'un d'autre devrez les réviser et les mettre à jour.

# 2) Après avoir documenté les cas de test, passez en revue une fois en tant que testeur:

Ne pensez jamais que le travail est terminé une fois que vous avez écrit le dernier TC du scénario de test. Allez au début et passez en revue tous les TC une fois, mais pas avec l'état d'esprit d'un rédacteur de TC ou d'un planificateur de tests. Passez en revue tous les TC avec l'esprit d'un testeur. Pensez rationnellement et essayez de faire fonctionner vos TC.

Évaluez que toutes les étapes et voyez si vous les avez mentionnées clairement de manière compréhensible et si les résultats attendus sont en harmonie avec ces étapes.

Assurez-vous que le données de test spécifié dans les TC est faisable non seulement pour les testeurs réels, mais aussi en fonction de l'environnement en temps réel. Assurez-vous qu'il n'y a pas de conflit de dépendance entre les TC et vérifiez que toutes les références aux autres TC / artefacts / GUI sont exactes. Sinon, les testeurs peuvent être en grande difficulté.

# 3) Liez et soulagez les testeurs:

Ne laissez pas les données de test sur les testeurs. Donnez-leur une gamme d'entrées, en particulier lorsque des calculs doivent être effectués ou que le comportement de l'application dépend des entrées. Vous pouvez les laisser décider des valeurs des éléments de données de test, mais ne leur donnez jamais la liberté de choisir eux-mêmes les éléments de données de test.

Parce que, intentionnellement ou non, ils peuvent utiliser les mêmes données de test encore et encore et certaines données de test importantes peuvent être ignorées pendant l'exécution des TC.

Gardez les testeurs à l'aise en organisant les TC selon les catégories de test et les domaines associés d'une application. Clairement, indiquez et mentionnez quels TC sont interdépendants et / ou groupés. De même, indiquez explicitement quels TC sont indépendants et isolés afin que le testeur puisse gérer son activité globale en conséquence.

À ce stade, vous voudrez peut-être en savoir plus sur l'analyse des valeurs limites, qui est une stratégie de conception de cas de test utilisée dans les tests de boîte noire. Cliquez sur ici pour en savoir plus.

# 4) Soyez un contributeur:

N'acceptez jamais le FS ou le document de conception tels quels. Votre travail n'est pas seulement de passer par le FS et d'identifier les scénarios de test. En tant que ressource QA, n'hésitez pas à contribuer aux affaires et à donner des suggestions si vous pensez que quelque chose peut être amélioré dans l'application.

Suggérer également aux développeurs, en particulier dans un environnement de développement piloté par TC. Suggérer les listes déroulantes, les contrôles du calendrier, la liste de sélection, les boutons radio de groupe, les messages plus significatifs, les avertissements, les invites, les améliorations liées à la convivialité, etc.

En tant que QA, ne vous contentez pas de tester, mais faites une différence!

# 5) N'oubliez jamais l'utilisateur final:

L’intervenant le plus important est «l’utilisateur final» qui utilisera finalement l’application. Alors, ne l'oubliez jamais à aucun stade de l'écriture des TC. En fait, l'utilisateur final ne doit être ignoré à aucun stade du SDLC. Pourtant, mon accent jusqu'à présent est simplement lié à mon sujet.

Ainsi, lors de l'identification des scénarios de test, ne négligez jamais les cas qui seront principalement utilisés par l'utilisateur ou les cas critiques pour l'entreprise même s'ils sont moins fréquemment utilisés. Restez dans la peau de l'utilisateur final, puis parcourez tous les TC et jugez la valeur pratique de l'exécution de tous vos TC documentés.

************************************************

Comment atteindre l'excellence dans la documentation des cas de test

En tant que testeur de logiciels, vous conviendrez sûrement avec moi que trouver un document de test parfait est vraiment une tâche difficile.

Nous laissons toujours une marge d'amélioration dans notre Documentation de cas de test . Parfois, nous ne sommes pas en mesure de fournir une couverture de test à 100% via les TC et parfois, le modèle de test n'est pas à la hauteur, ou nous manquons de fournir une bonne lisibilité et clarté à nos tests.

En tant que testeur, chaque fois que vous êtes invité à rédiger une documentation de test, ne commencez pas simplement de manière ad hoc. Il est très important de bien comprendre l'objectif de l'écriture de cas de test avant de travailler sur le processus de documentation.

Les tests doivent toujours être clairs et lucides. Ils doivent être rédigés de manière à offrir au testeur la facilité d'effectuer le test complet en suivant les étapes définies dans chacun des tests.

En outre, le document de cas de test doit contenir autant de cas que nécessaire pour fournir Couverture de test . Par exemple , vous devriez essayer de couvrir les tests pour tous les scénarios possibles qui peuvent se produire dans votre application logicielle.

En gardant à l'esprit les points ci-dessus, permettez-moi maintenant de vous présenter une visite guidée sur la façon d'atteindre l'excellence dans la documentation de test.

Trucs et astuces utiles

Ici, je vais vous fournir quelques conseils utiles qui peuvent vous donner une longueur d'avance dans votre documentation de test par rapport aux autres.

# 1) Votre document de test est-il en bon état?

La meilleure et simple façon d'organiser votre document de test est de le diviser en plusieurs sections utiles. Divisez l'ensemble des tests en plusieurs scénarios de test. Ensuite, divisez chaque scénario en plusieurs tests. Enfin, divisez chaque cas en plusieurs étapes de test.

Si vous utilisez Excel, documentez chaque scénario de test sur une feuille distincte du classeur dans laquelle chaque scénario de test décrit un flux de test complet.

# 2) N'oubliez pas de couvrir les cas négatifs

En tant que testeur de logiciels, vous devez sortir des sentiers battus et définir toutes les possibilités que votre application présente. En tant que testeurs, nous devons vérifier que si une tentative non authentique d'entrer dans le logiciel ou des données non valides circulant dans l'application doivent être arrêtées et signalées.

Ainsi, un cas négatif est aussi important qu'un cas positif. Assurez-vous que pour chaque scénario deux cas de test - un positif et un négatif . Le positif doit couvrir le débit prévu ou normal et le négatif doit couvrir le débit non intentionnel ou exceptionnel.

# 3) Avoir des étapes de test atomique

Chaque étape de test doit être une étape atomique. Il ne devrait pas y avoir d'autres sous-étapes. Plus une étape de test est simple et claire, plus il sera facile de procéder au test.

# 4) Hiérarchisez les tests

Nous avons souvent des délais rigoureux pour terminer les tests d'une application. Dans ce cas, nous pouvons manquer de tester certaines des fonctionnalités et aspects importants du logiciel. Afin d'éviter cela, vous devez marquer une priorité avec chaque test tout en le documentant.

Vous pouvez utiliser n'importe quel codage pour définir la priorité d'un test. Il est généralement préférable d'utiliser l'un des 3 niveaux, haut, moyen et bas , ou 1, 50 et 100. Ainsi, lorsque vous avez un calendrier strict, vous devez d'abord terminer tous les tests de priorité élevée, puis passer aux tests de priorité moyenne et faible.

Par exemple - pour un site Web d'achat, la vérification du refus d'accès pour une tentative non valide de connexion à l'application peut être un cas de haute priorité, la vérification de l'affichage des produits pertinents sur l'écran de l'utilisateur peut être un cas de priorité moyenne et la vérification de la couleur du texte affiché sur les boutons d'écran peuvent être un test de faible priorité.

# 5) La séquence compte

Confirmez si la séquence des étapes du test est absolument correcte. Une mauvaise séquence d'étapes peut prêter à confusion. De préférence, les étapes doivent également définir la séquence entière depuis l'entrée dans l'application jusqu'à la sortie de l'application pour un scénario particulier en cours de test.

# 6) Ajouter l'horodatage et le nom du testeur aux commentaires

Il peut arriver que vous testiez une application, que quelqu'un apporte des modifications en parallèle à la même application ou que quelqu'un puisse mettre à jour l'application une fois le test terminé. Cela conduit à une situation où les résultats de vos tests peuvent varier avec le temps.

Il est donc toujours préférable d’ajouter un horodatage avec le nom du testeur dans les commentaires de test afin qu’un résultat de test (réussite ou échec) puisse être attribué à l’état d’une application à ce moment précis. Sinon, vous pouvez avoir un ' Date d'exécution »Ajoutée séparément au scénario de test qui identifiera explicitement l’horodatage du test.

# 7) Inclure les détails du navigateur

Comme vous le savez, s'il s'agit d'une application Web, les résultats des tests peuvent différer en fonction du navigateur sur lequel le test est exécuté. Pour la facilité des autres testeurs, développeurs ou quiconque examine le document de test, vous devez ajouter le nom et la version du navigateur au cas afin que le défaut puisse être répliqué facilement.

# 8) Conservez deux feuilles séparées - «Bugs» et «Résumé» dans le document

Si vous documentez dans un Excel, les deux premières feuilles du classeur doivent être Résumé et Bogues. La feuille de résumé doit résumer le scénario de test et la feuille de bogues doit répertorier tous les problèmes rencontrés pendant le test. L'importance de l'ajout de ces deux feuilles est que cela donnera une compréhension claire du test au lecteur / utilisateur du document.

Ainsi, lorsque le temps est limité, ces deux fiches peuvent s'avérer très utiles pour donner un aperçu des tests.

Le document de test doit fournir la meilleure couverture de test possible, une excellente lisibilité et doit suivre un format standard tout au long.

Nous pouvons atteindre l'excellence dans la documentation de test en gardant simplement à l'esprit quelques conseils essentiels comme l'organisation du document de cas de test, en priorisant les TC, en ayant tout dans le bon ordre, y compris tous les détails obligatoires pour exécuter un TC, et en fournissant des étapes de test claires et lucides, etc. comme indiqué ci-dessus.

questions d'entretien sur html et css

************************************************

Comment NE PAS écrire de tests

Nous passons la plupart de notre temps à écrire, réviser, exécuter ou maintenir ces derniers. Il est assez regrettable que les tests soient également les plus sujets aux erreurs. Les différences de compréhension, les pratiques de test de l'organisation, le manque de temps, etc. sont quelques-unes des raisons pour lesquelles nous voyons souvent des tests qui laissent beaucoup à désirer.

Il y a beaucoup d'articles sur notre site sur ce sujet, mais ici vous verrez Comment NE PAS écrire des cas de test - quelques conseils qui contribueront à créer des tests distinctifs, de qualité et efficaces.

Continuons votre lecture et notez que ces conseils sont destinés aux testeurs débutants et expérimentés.

3 Problèmes les plus courants dans les cas de test

1. Marches composites
2. Le comportement de l'application est considéré comme un comportement attendu
3. Plusieurs conditions dans un cas

Ces trois doivent être sur ma liste des 3 premiers problèmes courants dans le processus de rédaction du test.

Ce qui est intéressant, c'est que cela se produit avec des testeurs nouveaux et expérimentés et nous continuons simplement à suivre les mêmes processus défectueux sans jamais se rendre compte que quelques mesures simples peuvent résoudre les choses facilement.

Allons-y et discutons de chacun en détail:

# 1) Étapes composites

Tout d'abord, qu'est-ce qu'une étape composite?

Par exemple, vous donnez des directions du point A au point B: si vous dites que «allez à l'endroit XYZ et ensuite à ABC» cela n'a pas beaucoup de sens, car ici nous nous trouvons en train de penser - «comment puis-je arriver à XYZ en premier lieu »- au lieu de cela en commençant par« Tourner à gauche d'ici et parcourir 1 mile, puis tourner à droite sur Rd. n ° 11 pour arriver à XYZ »pourrait obtenir de meilleurs résultats.

Les mêmes règles s'appliquent également aux tests et à ses étapes.

Par exemple J'écris un test pour Amazon.com - passez une commande pour n'importe quel produit.

Voici mes étapes de test (Remarque: je n'écris que les étapes et pas toutes les autres parties du test comme le résultat attendu, etc.)

à . Lancez Amazon.com
b . Recherchez un produit en saisissant le mot-clé / nom du produit dans le champ «Recherche» en haut de l'écran.
c . Dans les résultats de la recherche affichés, choisissez le premier.
ré . Cliquez sur Ajouter au panier sur la page de détails du produit.
est . Commander et payer.
F . Consultez la page de confirmation de commande.

À présent, pouvez-vous identifier laquelle de ces étapes est une étape composite? Étape droite (e)

N'oubliez pas que les tests concernent toujours «Comment» tester, il est donc important d'écrire les étapes exactes de «Comment vérifier et payer» dans votre test.

Par conséquent, le cas ci-dessus est plus efficace lorsqu'il est écrit comme ci-dessous:

à . Lancez Amazon.com
b . Recherchez un produit en saisissant le mot-clé / nom du produit dans le champ «Recherche» en haut de l'écran.
c . Dans les résultats de la recherche affichés, choisissez le premier.
ré . Cliquez sur Ajouter au panier sur la page de détails du produit.
est . Cliquez sur Commander dans la page du panier.
F . Saisissez les informations CC, les informations d'expédition et de facturation.
g . Cliquez sur Checkout.
h . Consultez la page de confirmation de commande.

Par conséquent, une étape composite est celle qui peut être décomposée en plusieurs étapes individuelles. La prochaine fois que nous écrirons des tests, prêtons tous attention à cette partie et je suis sûr que vous conviendrez avec moi que nous faisons cela plus souvent que nous ne le pensons.

# 2) Le comportement de l'application est considéré comme un comportement attendu

De plus en plus de projets doivent faire face à cette situation ces jours-ci.

Le manque de documentation, la programmation extrême, les cycles de développement rapides sont quelques raisons qui nous obligent à nous fier à l'application (une version plus ancienne ou plus) pour écrire les tests ou pour baser les tests eux-mêmes. Comme toujours, c'est une mauvaise pratique avérée - pas toujours vraiment.

Il est inoffensif tant que vous gardez l'esprit ouvert et que vous vous attendez à ce que - «AUT puisse être défectueux». Ce n'est que lorsque vous ne pensez pas que c'est le cas, les choses fonctionnent mal. Comme toujours, nous laisserons les exemples parler.

Si la page suivante est la page pour laquelle vous écrivez / concevez les étapes de test:

Cas 1:

Si les étapes de mon scénario de test sont les suivantes:

1. Lancez le site d'achat.
2. Cliquez sur Expédition et retour - Résultat attendu: La page d'expédition et de retour s'affiche avec «Mettez vos informations ici» et un bouton «Continuer».

Ensuite, c'est incorrect.

Cas 2:

1. Lancez le site d'achat.
2. Cliquez sur Expédition et retour.
3. Dans la zone de texte «Saisir le n ° de commande» présente dans cet écran, saisissez le n ° de commande.
4. Cliquez sur Continuer - Résultat attendu: les détails de la commande liés à l'expédition et aux retours sont affichés.

Le cas 2 est un meilleur cas de test car même si l'application de référence se comporte de manière incorrecte, nous ne le prenons que comme ligne directrice, faisons des recherches supplémentaires et écrivons le comportement attendu selon la fonctionnalité correcte prévue.

Conclusion: L'application en tant que référence est un raccourci rapide mais elle comporte ses propres risques. Tant que nous sommes prudents et critiques, cela produit des résultats étonnants.

# 3) Plusieurs conditions dans un cas

Encore une fois, apprenons de Exemple .

Jetez un œil aux étapes de test ci-dessous: Voici les étapes de test dans un test pour une fonction de connexion.

une. Entrez des détails valides et cliquez sur Soumettre.
b. Laissez le champ Nom d'utilisateur vide. Cliquez sur Soumettre.
c. Laissez le champ du mot de passe vide et cliquez sur Soumettre.
ré. Choisissez un nom d'utilisateur / mot de passe déjà connecté et cliquez sur Soumettre.

Ce qui devait être 4 cas différents est combiné en un seul. Vous pensez peut-être… Quel est le problème avec ça? Cela économise beaucoup de documentation et ce que je peux faire en 4, je le fais en 1, n’est pas génial? Enfin, pas tout à fait. Les raisons?

Continuer à lire:

• Et si l’une des conditions échoue - nous devons marquer l’ensemble du test comme «échoué». Si nous marquons l’ensemble du cas comme «échoué», cela signifie que les 4 conditions ne fonctionnent pas, ce qui n’est pas vraiment vrai.
• Les tests doivent avoir un flux. De la condition préalable à l'étape 1 et tout au long des étapes. Si je suis ce cas, à l'étape (a), s'il réussit, je serai connecté à la page, où l'option «connexion» n'est plus disponible. Donc, quand j'arrive à l'étape (b) - où le testeur va-t-il entrer le nom d'utilisateur? Vous voyez, le flux est interrompu.

D'où, écrire des tests modulaires . Cela ressemble à beaucoup de travail, mais il vous suffit de séparer les choses et d'utiliser nos meilleurs amis Ctrl + C et Ctrl + V pour travailler pour nous. :)

************************************************

Comment améliorer l'efficacité des cas de test

Les testeurs de logiciels doivent écrire leurs tests à partir de la première étape du cycle de vie du développement logiciel, le mieux pendant la phase des exigences logicielles.

Le responsable des tests ou un responsable QA doit collecter et préparer le maximum de documents possibles conformément à la liste ci-dessous.

test boîte blanche vs boîte noire

Collection de documents pour la rédaction de tests

# 1) Document sur les exigences de l'utilisateur

Il s'agit d'un document qui répertorie le processus métier, les profils utilisateur, l'environnement utilisateur, l'interaction avec d'autres systèmes, le remplacement des systèmes existants, les exigences fonctionnelles, les exigences non fonctionnelles, les exigences de licence et d'installation, les exigences de performance, les exigences de sécurité, l'utilisabilité et les exigences simultanées, etc. .,

# 2) Document de cas d'utilisation commerciale

Ce document détaille les cas d'utilisation scénario des exigences fonctionnelles du point de vue commercial. Ce document couvre les acteurs métier (ou système), les objectifs, les pré-conditions, les post-conditions, le flux de base, le flux alternatif, les options, les exceptions de chaque flux métier du système sous conditions.

# 3) Document sur les exigences fonctionnelles

Ce document détaille les exigences fonctionnelles de chaque fonctionnalité pour le système sous les exigences.

Normalement, le document d'exigences fonctionnelles sert de référentiel commun à la fois à l'équipe de développement et de test ainsi qu'aux parties prenantes du projet, y compris les clients, pour les exigences engagées (parfois figées), qui doivent être traitées comme le document le plus important pour tout développement logiciel.

# 4) Plan de projet logiciel (facultatif)

Un document qui décrit les détails du projet, les objectifs, les priorités, les jalons, les activités, la structure organisationnelle, la stratégie, le suivi des progrès, l'analyse des risques, les hypothèses, les dépendances, les contraintes, les exigences de formation, les responsabilités du client, le calendrier du projet, etc.,

# 5) Plan de contrôle qualité / test

Ce document détaille le système de gestion de la qualité, les normes de documentation, le mécanisme de contrôle des modifications, les modules et fonctionnalités critiques, le système de gestion de la configuration, les plans de test, le suivi des défauts, les critères d'acceptation, etc.

Le plan de test Le document est utilisé pour identifier les fonctionnalités à tester, les fonctionnalités à ne pas tester, les allocations de l'équipe de test et leur interface, les besoins en ressources, le calendrier des tests, la rédaction des tests, la couverture des tests, les livrables de test, les conditions préalables à l'exécution des tests, le rapport de bogue et le suivi mécanisme, métriques de test, etc.,

Exemple réel

Voyons comment écrire efficacement des cas de test pour un écran de «connexion» familier et simple, comme illustré ci-dessous. Le approche de test sera presque le même même pour les écrans complexes avec plus d'informations et des fonctionnalités critiques.

#1) La première approche pour tout processus de cas de test sera d'obtenir un prototype d'écran (ou des wire-frames) comme ci-dessus, si disponible. Cela peut ne pas être disponible pour certaines des fonctionnalités et dépend de la criticité de la conception d'un prototype aux premiers stades de développement.

Mais, si un SRS (Spécification des exigences logicielles) est disponible pour le projet, la plupart des prototypes d'écran sont développés par l'équipe du projet. Ce type d’écran simplifie le travail du testeur et augmente l’efficacité des tests.

#deux) Ensuite, le spécifications des exigences fonctionnelles . Cela dépend du processus d'organisation, il sera disponible dans une suite de plusieurs documents.

Alors, décidez du meilleur document pour la rédaction de cas, qu'il s'agisse d'un document d'exigences utilisateur ou d'un cahier des charges fonctionnel (ou même d'un document SRS s'il peut être compréhensible confortablement par l'équipe de test) qui donnera un flux fonctionnel complet de la sélection fonctionnalité à tester.

# 3) Une fois que le prototype d'écran et les spécifications fonctionnelles sont en place, le testeur doit commencer à écrire les cas avec l'approche et les critères suivants.

• Tests d'interface utilisateur :Les champs / champs visibles par l'utilisateur. Des contrôles statiques et dynamiques sont disponibles pour la fonctionnalité à tester. Par exemple, dans l'écran de connexion ci-dessus, les textes «Nom d'utilisateur et mot de passe» sont des champs statiques qui ne nécessitent aucune interaction de l'utilisateur, uniquement pour afficher le texte.

• Cas fonctionnels :D'autre part, le bouton de connexion et les hyperliens (mot de passe oublié? & Inscription) sont des champs dynamiques qui nécessitent une interaction de l'utilisateur en cliquant sur les commandes, ce qui fera une action par la suite.

• Cas de base de données :Une fois que l'utilisateur a entré le nom d'utilisateur et le mot de passe, les tests peuvent être écrits pour vérifier la base de données associée, si le nom d'utilisateur et le mot de passe sont vérifiés dans la bonne base de données et la bonne table et que l'utilisateur a également l'autorisation de se connecter à l'application testée.
  

• Tests de processus :Ceci est lié au processus (et non aux actions associées aux commandes visibles disponibles à l'écran) associé à la fonctionnalité et à la fonctionnalité. Par exemple, cliquer sur le lien Mot de passe oublié dans l'exemple d'écran ci-dessus peut envoyer un e-mail à l'utilisateur. Alors, peut-être qu'un e-mail doit être testé pour le processus et la confirmation appropriés.

4) Enfin, gardez le ' Mantra BAOE ', moyens i) Flux de base ii) Flux alternatif iii) Options et iv) Exceptions pour la couverture complète du flux fonctionnel et de la fonctionnalité à tester. Chaque concept doit être appliqué aux tests positifs et négatifs.

Par exemple, voyons la simple approche BAOE pour l'exemple d'écran de connexion ci-dessus.

• Flux de base: Entrez le chemin URL de la connexion dans n'importe quel navigateur et entrez les informations requises et connectez-vous à l'application.
• Flux alternatif: Installez l'application sur un appareil mobile et entrez les informations requises et connectez-vous à l'application.
• Options: Quelles sont les options disponibles pour accéder au même écran de connexion? Par exemple, après la connexion à l'application, cliquer sur «Déconnexion» peut afficher le même écran ou si le délai d'expiration de la session ou la session a expiré, l'utilisateur peut accéder à l'écran de connexion.
• Des exceptions: Quelles sont les exceptions si mes tests sont négatifs? Par exemple, si de fausses informations d'identification sont saisies dans l'écran de connexion, si l'utilisateur recevra un message d'erreur ou aucune action associée.

Avec toutes ces informations en main, commençons à écrire les TC pour l'écran de connexion, dans un format avec une couverture et une traçabilité complètes et avec des informations détaillées. La séquence logique et la numérotation d’identification du « ID du scénario de test » sera très utile pour une identification rapide de l'historique d'exécution des cas de test.

Lire aussi=> Plus de 180 exemples de cas de test prêts à l'emploi pour les applications Web et de bureau.

Document de cas de test

Noter : Les colonnes de test ne sont pas limitées à l'exemple de document de test ci-dessous, qui peut être conservé dans une feuille Excel pour avoir autant de colonnes que nécessaire pour une matrice de traçabilité complète à savoir, priorité, objectif du test, type de test, emplacement de la capture d'écran d'erreur etc.,

Lire aussi=> Exemple de modèle de cas de test avec des exemples.

Pour la simplicité et la lisibilité de ce document, écrivons ci-dessous les étapes pour reproduire, le comportement attendu et réel des tests pour l'écran de connexion.

Noter : Ajoutez la colonne Comportement réel à la fin de ce modèle.

Collecte de données de test

Lors de l'écriture du scénario de test, la tâche la plus importante de tout testeur est de collecter les données de test. Cette activité est ignorée et ignorée par de nombreux testeurs avec l'hypothèse que les cas de test peuvent être exécutés avec des exemples de données ou des données factices et peuvent être alimentés lorsque les données sont vraiment nécessaires. Il s'agit d'une idée fausse critique selon laquelle alimenter des échantillons de données ou des données d'entrée à partir de la mémoire mentale au moment de l'exécution des cas de test.

Si les données ne sont pas collectées et mises à jour dans le document de test au moment de l'écriture des tests, le testeur passerait anormalement plus de temps à collecter les données au moment de l'exécution du test. Les données de test doivent être collectées pour les cas positifs et négatifs du point de vue du flux fonctionnel de l'entité. Le document de cas d'utilisation métier est très utile dans cette situation.

Trouvez un exemple de document de données de test pour les tests écrits ci-dessus, qui à son tour sera utile sur l'efficacité avec laquelle nous pouvons collecter les données qui faciliteront notre travail au moment de l'exécution du test.

************************************************

Importance de la normalisation des cas de test

Dans ce monde occupé, personne ne peut faire des choses répétitives jour après jour avec le même niveau d'intérêt et d'énergie. Surtout, je ne suis pas passionné de faire la même tâche encore et encore au travail. J'aime gérer les choses et gagner du temps. N'importe qui en informatique devrait l'être.

Toutes les entreprises informatiques exécutent différents types de projets. Ces projets peuvent être basés sur des produits ou des services. Parmi ces projets, la plupart travaillent autour de sites Web et test de site Web . La bonne nouvelle à ce sujet est que tous les sites Web présentent de nombreuses similitudes. Et, si les sites Web concernent le même domaine, ils ont également plusieurs caractéristiques communes.

La question qui me déroute toujours est la suivante: «Si la plupart des applications sont similaires, par exemple: comme les sites de vente au détail, qui ont été testés mille fois auparavant,« Pourquoi avons-nous besoin d'écrire des cas de test pour un autre site de vente à partir de zéro? ' Ne gagnera-t-il pas une tonne de temps en retirant les scripts de test existants qui ont été utilisés pour tester un ancien site de vente au détail?

Bien sûr, il peut y avoir quelques petits ajustements que nous pourrions avoir à faire, mais dans l'ensemble, c'est plus facile, efficace, économisant du temps et de l'argent aussi et aide ainsi toujours à maintenir les niveaux d'intérêt des testeurs élevés. Qui aime écrire, revoir et maintenir les mêmes cas de test à plusieurs reprises, n'est-ce pas? La réutilisation des tests existants peut résoudre ce problème dans une large mesure et vos clients trouveront cela aussi intelligent et logique.

Donc, logiquement, j'ai commencé à extraire les scripts existants de projets Web similaires, j'ai apporté des modifications et je les ai examinés rapidement. J'ai également utilisé un code couleur pour montrer les modifications apportées, de sorte que le réviseur ne puisse se concentrer que sur la partie qui a été modifiée.

Raisons de réutiliser les cas de test

#1) La plupart des domaines fonctionnels d'un site Web sont la quasi-connexion, l'enregistrement, l'ajout au panier, la liste de souhaits, le paiement, les options d'expédition, les options de paiement, le contenu de la page produit, les produits récemment consultés, les produits pertinents, les fonctionnalités de code promotionnel, etc.

#deux) La plupart des projets ne sont que des améliorations ou des modifications de la fonctionnalité existante.

# 3) Les systèmes de gestion de contenu qui définissent les emplacements pour les téléchargements d'images de manière statique et dynamique sont également communs à tous les sites Web.

# 4) Les sites Web de vente au détail ont RSE (Service client) aussi.

# 5) Le système backend et l'application d'entrepôt utilisant JDA sont également utilisés par tous les sites Web.

# 6) Le concept de cookies, de délai d'expiration et de sécurité est également courant.

# 7) Les projets Web sont souvent sujets à des changements d'exigences.

# 8) Le types de tests les besoins sont courants comme le navigateur test de compatibilité , Test de performance , tests de sécurité

Vous voyez, il y a beaucoup de choses communes et similaires.

Cela dit, la réutilisation est la voie à suivre, parfois les modifications elles-mêmes peuvent prendre ou non plus ou moins de temps. Parfois, on peut penser qu'il vaut mieux repartir de zéro que de modifier autant.

Cela peut être facilement géré en créant un ensemble de cas de test standard pour chacune des fonctionnalités communes.

Qu'est-ce qu'un test standard dans les tests Web?

• Créez des cas de test qui sont complets - étapes, données, variable, etc. Cela garantira que les données / variables non similaires peuvent simplement être remplacées lorsqu'un cas de test similaire est requis.
• Les critères d'entrée et de sortie doivent être correctement définis.
• Les étapes modifiables ou l'instruction dans les étapes doivent être mises en évidence dans une couleur différente pour une recherche et un remplacement rapides.
• Le langage utilisé pour la création de cas de test standard doit être générique.
• Toutes les fonctionnalités de chaque site Web doivent être couvertes dans les cas de test.
• Le nom des cas de test doit être le nom de la fonctionnalité ou de la caractéristique que le cas de test couvre. Cela facilitera grandement la recherche du cas de test à partir de l'ensemble.
• S'il existe un échantillon de base ou standard, un fichier GUI ou une capture d'écran de la fonctionnalité, il doit être joint avec les étapes appropriées.

En utilisant les conseils ci-dessus, on peut créer un ensemble de scripts standard et les utiliser avec des modifications minimes ou nécessaires pour différents sites Web.

Ces cas de test standard peuvent également être automatisés, mais une fois encore, se concentrer sur la réutilisabilité est toujours un plus. Également si automatisation est basé sur une interface graphique, la réutilisation des scripts sur plusieurs URL ou sites est quelque chose que je n'ai personnellement jamais trouvé efficace.

L'utilisation d'un ensemble standard de cas de test manuels pour différents sites Web avec des modifications mineures est le meilleur moyen d'effectuer un test de site Web. Tout ce dont nous avons besoin est de créer et de maintenir les cas de test avec des normes et une utilisation appropriées.

Conclusion

L’amélioration de l’efficacité du scénario de test n’est pas un terme simplement défini, mais c’est un exercice qui peut être réalisé grâce à un processus mûr et une pratique régulière.

L'équipe de test ne doit pas se lasser de s'impliquer dans l'amélioration de telles tâches car c'est le meilleur outil pour de plus grandes réalisations dans le monde de la qualité, cela est prouvé dans de nombreuses organisations de test dans le monde entier sur des projets critiques et des applications complexes.

J'espère que vous auriez acquis d'immenses connaissances sur le concept de cas de test. Regardez notre série de tutoriels pour en savoir plus sur les cas de test et n'hésitez pas à exprimer vos pensées dans la section commentaires ci-dessous!

Tutoriel suivant

lecture recommandée

• Test fonctionnel vs test non fonctionnel
• Guide de test de portabilité avec des exemples pratiques
• Types de tests logiciels: différents types de tests avec des détails
• Meilleurs outils de test de logiciels 2021 (Outils d'automatisation des tests QA)
• Test alpha et test bêta (un guide complet)
• Qu'est-ce que le test du système - Un guide du débutant ultime
• Échantillon de questions sur la certification de test ISTQB avec réponses
• Comment rédiger un rapport hebdomadaire sur l'état des tests de logiciels