test scenario vs test case
Différence entre scénario de test et scénario de test.
Il y a 6 ans , tout en travaillant avec un MNC de taille moyenne, lorsque j'ai suggéré de documenter des scénarios de test plutôt que de perdre du temps à préparer le document de preuve complet appelé cas de test, toutes les têtes se sont tournées vers moi avec agacement.
Le regard sur les visages indiquait clairement que j'avais fait une grosse erreur en le suggérant. Bien que personne ne nie l'idée, personne n'a même accepté. Tout le monde pensait que suivre la tradition, c'est-à-dire rédiger des documents de cas de test, serait plus sûr. Je ne pouvais pas discuter.
Après 4 ans , l'entreprise a reçu un projet de test, où la seule contrainte était le temps et la seule attente était la preuve complète essai.
Nous étions de nouveau à la réunion et discutions d'idées pour respecter l'échéance critique. L'application consistait principalement à rechercher et à générer différents rapports via différents éléments de menu. La documentation des cas de test était censée arracher la plupart du temps et nous ne savions pas combien le document allait utiliser pour le client.
J'ai suggéré de documenter les scénarios de test et en quelque sorte avec une certaine hésitation, tout le monde était d'accord. Inutile de mentionner que nous pourrions gagner un temps précieux sur la documentation et l'utiliser pour les tests.
Ce que vous apprendrez:
- Les scénarios de test sont-ils remplacés rapidement par des scénarios de test?
- Quand la documentation des cas de test est-elle importante?
- Différences entre le scénario de test et le scénario de test au format tabulaire
- Conclusion
- lecture recommandée
Les scénarios de test sont-ils remplacés rapidement par des scénarios de test?
Avec le temps, comme tout change, l'industrie du logiciel et les processus ont également beaucoup changé.
liste des fausses adresses e-mail à utiliser
Traditionnel Cascade et Modèles en V sont remplacés par des modèles agiles et itératifs. La documentation est nécessaire mais pour respecter les délais et rendre le processus facile et transparent, le mode de documentation peut être modifié.
Quand la documentation des cas de test est-elle importante?
- Le client a demandé la même chose dans le cadre du projet.
- Il n’ya pas de contrainte de temps (je ne pense pas que ce soit possible).
- Les testeurs sont plus frais ou inconnus du produit.
- Politique de l'entreprise (je crois fermement qu'elle peut être modifiée).
Laissez-moi partager avec vous une expérience:
Mon équipe et moi avons été impliqués dans le test d'un projet d'une entreprise Fortune 500 avec des délais flexibles. Nous avons documenté les cas de test avec le meilleur modèle disponible et l'avons fait approuver par le client.
Une fois que la version a commencé à être publiée pour l'équipe d'assurance qualité, pendant la majeure partie de la journée, notre devoir était de suivre mécaniquement 100 cas de test par jour, de mettre à jour le document avec un résultat de réussite / échec et de l'envoyer au client à la fin de la journée. La plupart les membres de l'équipe ont commencé à se plaindre travail monotone mais l'entreprise générait des revenus.
Ensuite, il y a eu une pause d'un jour entre les deux sans nouvelle version à tester. Nous nous sommes assis ensemble au début de la journée et avons discuté de ce que nous allions faire pour la journée. Lorsque j'ai proposé de générer plus d'idées pour améliorer le document de cas de test, tous les membres de l'équipe ont nié avoir déployé des efforts.
Selon eux, il n'y avait plus rien à penser car nous avions couvert tous les scénarios. Et les convaincre de sortir des sentiers battus et générer plus d'idées était vraiment difficile.
La plupart du temps, lorsque nous documentons des cas de test et cela aussi une fois approuvés par le client, cet esprit humain pense que nous avons fait notre travail et notre esprit cesse automatiquement de considérer tout effort pour réfléchir à d'autres moyens de tester le produit.
Et croyez-moi, lorsque le document des cas de test est préparé, nous voulons simplement le suivre mécaniquement. Dites-moi combien de fois au cours de votre carrière, vous avez constaté que vous ou votre coéquipier avez offert des cas de test supplémentaires au document de cas de test approuvé?
Encore une expérience:
Au cours de l'activité hebdomadaire de défi d'équipe, nous avons annoncé l'application et demandé aux membres de l'équipe de verser des scénarios de test.
Tous les membres de l'équipe, y compris les derniers répondants ou non-répondants, ont mis des idées. Pourquoi? Il n'y avait pas de documentation formelle où ils devaient remplir le résultat attendu pour chaque séquence de fonctionnalités et pré-condition pour chaque cas de test. Nous avons collecté 40 scénarios de test en une journée et ce fut une expérience formidable.
Pour favoriser mon expérience, Je voudrais présenter un exemple.
Prenez un exemple d'application, dites page de connexion avec nom d'utilisateur, mot de passe, connexion et boutons d'annulation. Si on vous demande d'écrire des cas de test pour le même, nous finirons par écrire plus de 50 cas de test en combinant différentes options et détails.
Mais si des scénarios de test doivent être écrits, ce sera une question de 10 lignes comme ci-dessous:
Scénario de haut niveau: Fonctionnalité de connexion
Scénarios de bas niveau :
les outils d'analyse Big Data les plus populaires
1. Pour vérifier que l'application se lance
2. Pour vérifier le contenu du texte sur la page de connexion
3. Pour vérifier le champ Nom d'utilisateur
4. Pour vérifier le champ Mot de passe
5. Pour vérifier le bouton de connexion et annuler la fonctionnalité du bouton
Voir également=> Plus de 180 exemples de scénarios de test pour tester les applications Web et de bureau.
Comme nous manquons tous de temps, les scénarios de test fonctionnent comme un spray analgésique plutôt que comme l'ancien IODEX. Et encore, l'effet est le même.
Différences entre le scénario de test et le scénario de test au format tabulaire
Enfin, je voudrais résumer la différence entre le scénario de test et le scénario de test:
| Cas de test | Scénarios de test | |
|---|---|---|
| Qu'est-ce que c'est => | Un concept qui fournit des informations détaillées sur ce qu'il faut tester, les étapes à suivre et le résultat attendu | Un concept qui fournit des informations en une ligne sur ce qu'il faut tester. |
| Il s’agit de => | Il s'agit davantage de documenter les détails. | Il s'agit plus de réfléchir et de discuter des détails. |
| Importance => | C’est important lorsque les tests ne sont pas étayés et que le développement est sur site. La rédaction de cas de test avec des détails aidera les équipes de développement et d'assurance qualité à se synchroniser. | C’est important lorsque le temps presse et que la plupart des membres de l’équipe peuvent convenir / comprendre les détails d’un scénario à une ligne. |
| Avantage => | Une documentation unique de tous les cas de test est utile pour suivre des séries de 1000 tests de régression à l'avenir. La plupart du temps, il est utile lors du signalement de bogues. Le testeur doit simplement donner la référence de l'ID du cas de test et ne nécessite pas de mentionner chaque détail minutieux. | Une activité d'économie de temps et de génération d'idées, préférée par la communauté de test de logiciels de nouvelle génération. La modification et l'ajout sont simples et non spécifiques à une personne. Pour un projet de grande envergure, où un groupe de personnes ne connaît que des modules spécifiques, cette activité donne à chacun une chance de se pencher sur d'autres modules et de faire du brain storm et de discuter |
| Bénéfique pour => | Un document de cas de test à l'épreuve complète est une ligne de vie pour un nouveau testeur. | Une bonne couverture de test peut être obtenue en divisant l'application en scénarios de test et cela réduit la répétabilité et la complexité du produit |
| Inconvénient => | Cela prend du temps et de l'argent car il faut plus de ressources pour tout détailler sur ce qu'il faut tester et comment tester | S'il est créé par une personne spécifique, le réviseur ou l'autre utilisateur peut ne pas synchroniser l'idée exacte derrière lui. Besoin de plus de discussions et d'efforts d'équipe. |
Conclusion
Les cas de test sont la partie la plus importante du cycle de vie du développement logiciel et sans celle-ci, il est difficile de suivre, comprendre, suivre et raisonner quelque chose. Mais à l'ère de l'Agile, les cas de test sont rapidement remplacés par des scénarios de test.
Un commun liste de contrôle de test pour chaque type de test (test de base de données, test d'interface graphique, test de fonctionnalité, etc.) couplé à des scénarios de test est l'artillerie moderne pour les testeurs de logiciels. Les discussions, la formation, les questions et la pratique peuvent définitivement changer le graphique final de votre productivité ainsi qu'une matrice de rapport de bogue.
Comme d'habitude, nous accueillons vos réflexions et vos questions. Veuillez vous connecter.
Tutoriel PREV | Tutoriel SUIVANT
lecture recommandée
- Différence entre plan de test, stratégie de test, scénario de test, script de test, scénario de test et condition de test
- Types de tests logiciels: différents types de tests avec des détails
- Comment rédiger des cas de test: le guide ultime avec des exemples
- Comment réviser un document SRS et créer des scénarios de test - Formation aux tests de logiciels sur un projet en direct - Jour 2
- Comment classer les scénarios de test positifs et négatifs - Aide-mémoire d'un testeur
- Test de performance vs test de charge vs test de stress (différence)
- Test statique et test dynamique - Différence entre ces deux techniques de test importantes
- 101 différences entre les bases des tests de logiciels