Top 13 Conseils pour les cas d'écriture de test efficace, QuickSoftwareTesting
Les cas de tests sont très importants pour tout projet que c'est la première étape dans un cycle de test, et si quelque chose va mal à cette étape, les impacts s'extrapolé que vous avancez dans le cycle de vie des logiciels de test.
Savoir comment écrire de bons cas de test est extrêmement important pour vous en tant que ressource de test et vous croyez-moi, il ne prend pas trop de vos efforts et de temps pour écrire des scripts de test efficaces! Vous avez juste besoin de suivre certaines directives lors de l'écriture des cas de test ou comme ils l'appellent - suivre « cas de test écrit les meilleures pratiques. »
Dans cet article, je vais parler de quelques conseils simples mais efficaces que vous pouvez utiliser pour écrire des scénarios de test efficaces. [Annonce connexe: Avez-vous besoin d'écrire des cas de test dans les tests agiles? ]
écriture cas test est une activité qui a un grand impact sur la phase de test, ce qui rend les cas de test d'une partie importante du processus d'exécution de test!
Ainsi, l'écriture des scénarios de test qui sont efficaces, ainsi que réutilisable est très important; bons cas de test d'économiser beaucoup de temps dans les étapes ultérieures de tests (vraiment!) si vous le faites correctement dans la première tentative ...
Cas de test efficace écriture est une compétence et vous pouvez acquérir uniquement avec la pratique et une compréhension approfondie de l'application pour laquelle les cas de test sont en cours d'écriture.
L'intégration de quelques conseils simples que j'ai donnés ici vous aideront à maîtriser l'art de l'écriture de cas de test.
Avant de sauter à droite sur les trucs et astuces, permet de comprendre brièvement, « Qu'est-ce qu'un cas de test? »
Un cas de test est simplement une liste d'actions qui doivent être exécutées pour vérifier une fonctionnalité particulière ou fonction de votre application en cours de test. Consultez la définition de Wikipedia ici.
Voici la liste des 13 meilleurs conseils / directives que vous pouvez garder à l'esprit au cours des activités de conception de test pour écrire des scénarios de test qui sont efficaces, facilement compréhensible et réutilisable! Nous allons ici ... Donc,
Conseils simples pour l'écriture des scénarios de test efficaces
#1. Conventions de nommage cas de test
Bien que ce soit la plus simple astuce à suivre sur cette liste (je le sens), la majorité d'entre nous ne la pratiquent de façon très efficace - Convention de dénomination pour les cas de test!
Il est toujours une bonne pratique pour nommer vos cas de test d'une manière qu'il est logique de celui qui va renvoyer les cas de test à l'avenir (y compris vous!)
Conseil: En tant que meilleure pratique, nommez les cas de test pour représenter le nom du module ou domaine fonctionnel que vous allez vérifier dans ce cas de test.
Prenons un exemple!
Il y a un projet intitulé « en ligne », qui a une zone fonctionnelle nommée « Connexion »
Pour garder les choses simples, au lieu de nommer les tests que TC_01, je pourrais utiliser la convention de nommage ci-dessous pour mon cas de test afin qu'il donne une brève idée de ce que le test est pour juste en regardant son nom.
- TC_01_Online_Login_Success ou,
- TC_01_Online_Valid_Case et aussi ...
Juste essayer de faire paraître pertinents au projet / module / caractéristique fonctionnelle à l'essai ...
Ceci est juste un exemple et vous pouvez nommer les cas de test ne importe quelle manière vous convient le mieux.
Essayez de les faire faire autant de sens qu'ils peuvent juste en regardant le nom d'identification de cas de test ou cas de test!
J'espère que celui-ci était assez simple. D'accord, nous allons passer à la suivante!
# 2. Description du cas de test
Description est l'endroit où vous mentionnez tous les détails sur ce que vous allez tester, et le comportement particulier en cours de vérification par le test.
La « description » d'un cas de test doit définir « Que vais-je tester? »
Ce qui doit être vérifié, quel environnement test, il doit être vérifié dans quelles données de test doit être utilisé - toutes ces informations va dans la description.
Astuce rapide: Entrez le plus d'information possible dans la description de cas de test!
Principalement, vous trouverez les informations ci-dessous une description de cas de test bien écrit:
- Test à effectuer / comportement contrôlée
- Conditions préalables et hypothèses (les dépendances)
- Les données d'essai à utiliser
- Test de l'environnement Détails (le cas échéant)
- Tous les outils de test à utiliser pour le test
Je l'ai écrit plus sur « Les hypothèses et les Préalables et « Test Data » ci-dessous.
# 3. Les hypothèses et les Préalables
Tout en écrivant des scénarios de test, vous devez communiquer toutes les hypothèses applicables à un test, ainsi que toutes les conditions qui doivent être remplies avant que le test peut être exécuté.
Voici le genre de détails que vous souhaitez couvrir dans le cadre de cette section:
- Toute dépendance de données utilisateur (par exemple l'utilisateur doit être connecté, quelle page doit commencer le voyage de l'utilisateur, etc.)
- Dépendances sur l'environnement de test
- Toute configuration spéciale à effectuer avant l'exécution de test
- Dépendances sur tout autre cas de test - ne le cas de test doivent être exécutés avant / après un autre cas de test?
Conseil: Assurez-vous d'ajouter autant d'informations que possible pour toutes les conditions à remplir avant d'exécuter le cas de test.
Cette liste est non exhaustive et les éléments que je viens d'énumérer sont juste un exemple de ce que vous pouvez inclure dans cette section.
# 4. Entrée des données d'essai
Identification des données de test peuvent être vraiment une activité de temps - de nombreuses fois la préparation des données de test prend la plupart du temps dans un cycle de test.
Pour vous rendre la vie facile en tant que testeur (et vos compagnons de testeurs!), Là où il y a lieu, vous pouvez donner des données de test à utiliser pour le cas de test dans la description de cas de test ou à l'étape de cas de test spécifique.
Cela permet d'économiser beaucoup de temps à long terme que vous n'aurez pas à chasser de nouvelles données de test à chaque fois que vous devez exécuter le test.
# 5. Couvrir tous les points de vérification dans la conception des tests étapes
Une autre partie importante d'un test bien écrit sont correctement définies les étapes de vérification de cas de test couvrant tous les points de vérification pour la fonction en cours de test.
Conseil: Le test de conception Des mesures devraient couvrir non seulement le flux fonctionnel, mais aussi chaque point de vérification qui doit être testé!
En comparant votre cas de test étapes avec les artefacts (documents d'exigences, cas d'utilisation, Histoires de l'utilisateur ou Maps Processus) données pour votre projet, vous pouvez vous assurer que le cas de test couvre de manière optimale tous les points de vérification.
Bonus Astuce: Si vous travaillez dans les tests agiles, vous pouvez choisir de ne pas couvrir chaque test en cas de test (vérifier: doit-on écrire des cas de test dans agile?). Au lieu de cela, vous pouvez couvrir certaines de ces étapes de vérification lors de tests exploratoires (lire: avantages des tests exploratoires).
# 6. Joindre les Artefacts pertinents
Comme je l'ai mentionné dans le point ci-dessus, chaque fois que possible, vous devez joindre les objets pertinents à votre cas de test.
Si le changement que vous testez est pas énorme, vous pourriez envisager de le mentionner dans l'étape de test lui-même.
Mais, si elle implique une section spécifique sur l'écran qui pourrait être difficile à mentionner dans l'étape de test, la fixation des documents de spécification ou de dessins d'écran à cette étape particulière aide.
#7. résultat attendu
Une mention de cas de test bien écrit clairement le résultat attendu de l'application ou du système en cours de test. Chaque étape de conception d'essai doit mentionner clairement ce que vous attendez comme résultat de cette étape de vérification.
Ainsi, lors de l'écriture des scénarios de test, mentionner en détail quelle page / écran que vous attendez à apparaître après le test et les mises à jour que vous attendez comme résultat à fait dans les systèmes de back-end ou la base de données (ex. Devrait être une nouvelle entrée Table DB).
Vous pouvez également joindre des captures d'écran ou des documents de spécification à l'étape pertinente de mentionner le système devrait fonctionner comme indiqué dans le document donné pour rendre les choses plus simples.
# 8. Diviser les cas de tests fonctionnels spéciaux dans des ensembles
Pour l'écriture efficace des cas de test. vous devriez envisager de ventiler vos cas de test en ensembles et sous-ensembles pour tester certains scénarios spéciaux tels que les comportements spécifiques du navigateur, la vérification des cookies, des tests d'utilisation, les tests de services Web et la vérification des conditions d'erreur, etc.
Si vous vous efforcez d'écrire des scénarios de test efficaces, vous devriez écrire ces cas de tests fonctionnels spéciaux séparément.
Par exemple, les cas de test pour vérifier les conditions d'erreur doivent être écrites séparément des cas de tests fonctionnels et devraient avoir des mesures pour vérifier les messages d'erreur.
Conseil: Si en écrivant ces scénarios en ensembles, une caractéristique particulière a beaucoup de combinaisons d'entrée, vous pouvez séparer le test en sous-tests.
Par exemple, si vous avez besoin de vérifier comment la fonction de connexion pour toute application fonctionne avec l'entrée non valide, vous pouvez briser ce test négatif pour la fonctionnalité de connexion dans les tests de sous pour différentes valeurs telles que:
- Vérifiez avec l'email-id invalide
- Vérifiez avec mot de passe incorrect
- Vérifiez avec le champ email-id vide et ainsi de suite ...
# 9. Lisible - Facilement Compréhensible
Quel que soit le projet que vous travaillez, lors de la conception des cas de test, vous devez toujours considérer que les cas de test ne seront pas toujours exécutés par celui qui les conçoit.
Ainsi, les tests doivent être facilement compréhensibles, lisibles et à la pointe.
suites de test qui ne sont compréhensibles par ceux qui les ont conçus sont omniprésents.
Imaginez un scénario où la personne qui a écrit tous les cas de test part pour une raison quelconque et vous avez une équipe complètement nouvelle pour travailler sur l'exécution de cas de test, tout l'effort passé au cours de la phase de conception pourrait aller dans le drain.
Si vous êtes celui qui quitte l'organisation, vous êtes mieux, mais si vous êtes dans la même entreprise, mais juste changé d'équipe, vous pourriez être poussé du coude tout le temps pour expliquer ce que vous avez écrit!
Il vaudrait donc mieux le faire correctement dès la première fois!
Vous devez vous concentrer sur l'écriture des scénarios de test:
- sont simples et facilement compréhensibles par tous (y compris vous!)
- ARETO-le-point! Vous n'avez pas d'écrire des essais! (Où vous vous sentez un cas de test va au-delà d'un certain nombre d'étapes, ne hésitez pas à le casser dans un nouveau cas de test)
- ont encore une couverture suffisante
#dix. La revue
Avec cas de test jouant un rôle important dans le cycle de vie du logiciel de test. en vous assurant qu'ils sont corrects et conformes aux normes devient encore plus nécessaire - c'est là le processus d'examen des cas de test entre en image.
Astuce rapide: cas de test d'examen peut être fait par les testeurs par les pairs (appelé « examen par les pairs»), BA, les développeurs, les propriétaires de produits ou les parties prenantes concernées.
# 11. réutilisable
Vous devriez écrire des scénarios de test en gardant à l'esprit qu'ils pourraient être réutilisés à l'avenir pour d'autres projets / équipes.
Sur cette note, avant d'écrire un nouveau scénario de test pour votre projet / module, toujours essayer de savoir s'il y a des cas de test écrit déjà pour la même région? Cela permet d'économiser vraiment beaucoup de temps!
Si vous passez un peu de temps avec d'autres équipes à trouver le scénario de test que vous pourriez avoir de la chance - vous ne serez pas répéter tous les cas de test évitant ainsi les redondances dans vos outils de gestion de test (comme ALM ou QC).
Cela pourrait ne pas appliquer si le vôtre est un nouveau projet, cependant, vous pouvez essayer d'écrire des scénarios de test de manière à pouvoir être réutilisés pour un autre futur projet.
, Si vous avez besoin également un test particulier pour exécuter un autre cas de test, vous pouvez simplement appeler le cas de test existant dans des conditions préalables ou à une étape de conception de test spécifique.
# 12. Maintenance - Mises à jour
Bon, pour celui-ci a beaucoup de pointeurs ont déjà couvert ci-dessus (point n ° 11)!
Conseil: Pensez toujours à mettre à jour les cas de tests existants avant de commencer à écrire de nouveaux cas de test!
Réitérant mon point sur les possibilités de réutilisation. en cas de tout changement à un existant ou la fonctionnalité, vous devez considérer la mise à jour des cas de tests existants au lieu d'écrire de nouveaux cas de test évitant ainsi les redondances à l'ensemble existant.
# 13. Conditions de poste
Post-conditions précisent essentiellement les différentes choses qui doivent être vérifiées après le test a été effectué.
En outre, les post-conditions sont également utilisés pour donner des instructions de guidage pour restaurer le système à son état d'origine pour elle de ne pas interférer avec les tests plus tard.
Par exemple, cela est tout à fait utile si vous mentionnez les modifications à apporter à des données de test pour être utilisé pour un cas de test plus tard pour la même fonctionnalité.
Il est une tâche énorme pour écrire des scénarios de test efficaces avec tous les détails nécessaires à ce sujet. Tant que vous assurez-vous de penser de la perspective des utilisateurs finaux, connaître la fin à la fin de l'application, et suivre le cas de test écrit les meilleures pratiques que je viens de mentionner ici, tu vas bien! # 128521;
Ici, dans cette liste, je l'ai essayé de couvrir des conseils les plus simples et utiles que vous pouvez appliquer pendant que vous êtes dans la phase de conception de cas de test.
J'ai essayé de préparer une liste complète, vous pouvez suivre lors de la conception des cas de test - il m'a fallu plusieurs séances et de nombreuses heures pour compiler cette liste - il suffit de remarquer, l'article a traversé plus de 2300 mots # 128521;
J'espère vraiment que cette liste vous aide!
Maintenant que vous savez comment écrire des cas de test (au moins je vous fais confiance faites!), Revenir à la conception des meilleurs cas de test et de briser l'application lors de l'exécution!
Si vous avez trouvé cette liste utile, s'il vous plaît ne soutenir mes efforts en partageant cet article sur linkedin, facebook et twitter.
Bonne chance et Bonne test!
Vous pouvez aussi me laisser tomber une ligne avec votre suggestion et commentaires ici.
Aman bien écrit. ces conseils devraient continuer à rappeler de garder les bases propres.
Avez-vous ou l'un des lecteurs ici face à ce? Comment travaillez-vous autour dans votre espace de travail?
Je vais travailler sur une écriture et poster ici bientôt à ce que nous faisons. En attendant, je voulais jeter cette question à la communauté.
Salut Manish, vous avez fait un bon point ici.
Le point entier de agile est de décomposer les exigences (histoires de l'utilisateur) en petits morceaux de caractéristiques livrables (produits viables minimum). Idéalement, si nous en tant qu'équipe de mêlée le sentiment qu'une histoire d'utilisateur est énorme à livrer dans le sprint, nous essayons de le décomposer en petits histoires d'utilisateurs ou des sous-tâches.
Cela se fait en supposant que le projet / scrum viendrait à une fin, cette particularité pourrait encore être libérer en direct et encore ajouter de la valeur à l'application. C'est précisément ce que nous faisons dans notre équipe Scrum.
J'aimerais voir votre écriture et ce serait génial de le publier sur la TVQ pour les autres lecteurs de fournir leur version comment ils gèrent ces situations dans leurs équipes. Vous pouvez envoyer votre écriture à aman [at] quicksoftwaretesting [dot] com ou le télécharger ici.