test execution software testing
Processus exact et plan d'exécution de cas de test avec des exemples réels.
Aujourd'hui, dans notre Mini cours de formation sur les tests de logiciels , nous progressons dans la dernière étape du STLC, qui est le Exécution des tests .
Vous pouvez consulter la liste de tous les didacticiels publiés dans cette série de formation gratuite au contrôle qualité sur cette page: Formation de bout en bout aux tests de logiciels sur un projet en direct.
L’exécution du test est, sans aucun doute, la phase la plus importante et la plus STLC et aussi tout le cycle de vie du développement. La raison en est que la contribution et le travail de chaque équipe / membre d'équipe sont validés ici:
- L'analyste commercial a-t-il correctement interprété les exigences?
- L'équipe de développement a-t-elle traduit les exigences métier en exigences fonctionnelles et finalement en code correctement?
- L'architecte de données et les DBA ont-ils conçu les bons systèmes back-end?
Eh bien, l'exécution des tests est l'endroit où toutes les réponses à ces questions seraient trouvées. Cela fait de nous les héros du processus de création de logiciels, n'est-ce pas? :)
L'exécution des tests est également la partie «Test» du SDLC.
meilleure idée de python pour windows 10
Une fois les cas de test rédigés, partagés avec les BA et l'équipe de développement, examinés par eux, les changements sont notifiés à l'équipe d'assurance qualité (le cas échéant), l'équipe d'assurance qualité apporte les modifications nécessaires - La phase de conception des tests est terminée. Maintenant, préparer les cas de test ne signifie pas que nous pouvons lancer le test. Nous devons également préparer l'application.
Ce que vous apprendrez:
- Directives d'exécution des tests
- Nouvelles colonnes dans le document de cas de test
- Résultats de l'exécution des tests pour le projet Live OrangeHRM
- lecture recommandée
Directives d'exécution des tests
Faisons maintenant une liste de tout ce qui est important pour comprendre la phase d'exécution du test:
#1) Le construire (le code qui est écrit par l'équipe de développement est emballé dans ce qui est référencé à une version - ce n'est rien d'autre qu'un logiciel installable (AUT), prêt à être déployé dans l'environnement QA.) en cours de déploiement (en d'autres termes, installé et mis à disposition) dans l'environnement QA est l'un des aspects les plus importants qui doivent se produire pour que l'exécution du test démarre.
#deux) L'exécution du test se produit dans le Environnement QA . Pour s'assurer que le travail de l'équipe de développement sur le code ne se trouve pas au même endroit, où l'équipe d'assurance qualité effectue les tests, la pratique générale est d'avoir un environnement de développement et d'assurance qualité dédié. (Il existe également un environnement de production pour héberger l'application en direct).
Il s'agit essentiellement de préserver l'intégrité de l'application à différentes étapes du cycle de vie du SDLC. Sinon, idéalement, les 3 environnements sont de nature identique.
# 3) Taille de l'équipe de test n'est pas constante depuis le début du projet. Lorsque le plan de test est lancé, l'équipe peut simplement avoir un chef d'équipe. Lors de la phase de conception des tests, quelques testeurs se joignent à eux. L'exécution du test est la phase où l'équipe est à sa taille maximale.
# 4) L'exécution des tests se produit également dans au moins 2 cycles (3 dans certains projets). En règle générale, à chaque cycle, tous les cas de test (toute la suite de tests) seront exécutés. L'objectif du premier cycle est d'identifier les blocages, les défauts critiques et la plupart des défauts importants.
L'objectif du deuxième cycle est d'identifier les défauts élevés et moyens restants, de corriger les lacunes dans les scripts et d'obtenir des résultats.
# 5) La phase d'exécution du test comprend: Exécution des scripts de test + Maintenance des scripts de test (correction des lacunes dans les scripts) + Reporting (défauts, statut, métriques, etc.) Par conséquent, lors de la planification de cette phase, les horaires et les efforts doivent être estimés en prenant en considération tous ces aspects et pas seulement l'exécution du script.
# 6) Une fois le script de test terminé et l'AUT déployé - et avant le début de l'exécution du test, il y a une étape intermédiaire. C'est ce qu'on appelle le 'Examen de l'état de préparation aux tests (TRR)' . Il s'agit d'une sorte d'étape de transition qui mettra fin à la phase de conception du test et nous facilitera l'exécution du test.
Pour plus d'informations sur cette étape et un exemple de «liste de contrôle pour l'examen de la préparation aux tests», consultez ce lien: Liste de contrôle des tests logiciels
# 7) En plus du TRR, il y a peu de vérifications supplémentaires avant de nous assurer que nous pouvons aller de l'avant avec l'acceptation de la version actuelle qui est déployée dans l'environnement QA pour l'exécution des tests.
Ce sont les Tests de fumée et de santé mentale . Des informations détaillées sur ce que sont ces derniers sont disponibles sur: Qu'est-ce que le test de fumée et de santé mentale?
les fournisseurs de cloud computing proposent leurs services
# 8) Une fois les tests TRR, Smoke et Sanity terminés avec succès, le cycle de test commence officiellement.
# 9) Essais exploratoires serait effectuée une fois que la construction est prête pour les tests. Le but de ce test est de s'assurer que les défauts critiques sont supprimés avant que les niveaux de test suivants puissent commencer. Ce test exploratoire est effectué dans l'application sans aucun script de test ni documentation. Cela aide également à se familiariser avec l'AUT.
# dix) Tout comme les autres phases du STLC, le travail est également réparti entre les membres de l'équipe lors de la phase d'exécution des tests. La division peut être basée sur le module sage ou le nombre de cas de test ou tout autre élément qui pourrait avoir du sens.
#Onze) Le principal résultat de la phase d'exécution du test est sous la forme de rapports principalement, c'est-à-dire le rapport de défaut et le rapport sur l'état de l'exécution du test. Le processus détaillé de déclaration est disponible à l'adresse Rapports des exécutions de test.
Nouvelles colonnes dans le document de cas de test
Le document de scénario de test doit maintenant être développé avec les deux colonnes suivantes - Statut et résultat réel .
( Noter : Pour l'exécution des tests de projet en direct, nous avons ajouté et mis à jour ces colonnes avec les résultats de l'exécution des tests dans la feuille de calcul des cas de test fournie en téléchargement ci-dessous)
# 1) Colonne d'état
L'exécution de test n'est rien d'autre que, en utilisant les étapes de test sur l'AUT, en fournissant les données de test (telles qu'identifiées dans le document de cas de test) et en observant le comportement de l'AUT pour voir s'il satisfait ou non le résultat attendu.
Si le résultat attendu n'est pas atteint, cela peut être interprété comme un défaut. Et le statut du scénario de test devient «Échec» et si le résultat attendu est atteint, le statut est «Réussi». Si le scénario de test ne peut pas être exécuté pour quelque raison que ce soit (un défaut existant ou un environnement non compatible), le statut serait «Bloqué».
L'état d'un scénario de test qui doit encore être exécuté peut être défini sur Aucune exécution / non exécutée ou peut être laissé vide.
- Pour un scénario de test avec plusieurs étapes, si le résultat attendu d'une certaine étape (au milieu des étapes du scénario de test) n'est pas atteint, le statut du scénario de test peut être défini sur 'Échec' à cet endroit et les étapes suivantes n'ont pas besoin d'être exécutées.
- Le statut «Échec» peut être indiqué en rouge, si vous souhaitez attirer l'attention immédiatement dessus.
# 2) Colonne de résultat réel
Il s'agit d'un espace où nous, les testeurs, pouvons enregistrer l'écart du résultat attendu. Lorsque le résultat attendu est atteint (ou un cas de test dont le statut est «Réussi»), ce champ peut être laissé vide. Parce que si le résultat attendu est atteint, cela signifie que le résultat réel = le résultat attendu, ce qui signifie que sa réécriture dans la colonne de résultat réel sera une répétition et une redondance.
Une capture d'écran de l'écart peut être jointe à cette colonne pour une meilleure clarté du problème.
Résultats de l'exécution des tests pour le projet Live OrangeHRM
Prenons maintenant OrangeHRM et effectuons l'exécution du test en fonction des directives ci-dessus énumérées.
Voici quelques points à noter:
- Le modèle de scénario de test étendu.
- Les tests exploratoires indiqués doivent être effectués sans scripts de test. N'hésitez donc pas à tester l'application en parallèle comme bon vous semble.
- En raison des limites que nous avons dans la présentation du projet en direct sous la forme de contenu lisible, seule une quantité limitée de cas de test / fonctionnalités de l'application OrangeHRM est affichée dans l'exemple de modèle d'exécution de test. Encore une fois, n'hésitez pas à travailler plus pour l'expérience la plus pratique.
- Les suites de tests Sanity et Smoke sont également ajoutées au document, pour vous donner une idée du type de cas de test envisagés pour ces étapes.
- Les défauts ne sont pas encore enregistrés, même si l'état de certains cas de test est défini sur «Échec». En effet, la journalisation des défauts est le deuxième aspect le plus important / le plus couramment travaillé sur un aspect de notre vie de testeurs. Nous voulons donc en parler en détail dans le prochain article.
Cas de test avec résultats d'exécution:
comment exécuter des fichiers .jar windows 10
=> Cliquez ici pour télécharger le document Exécution du scénario de test.
Il contient - Résultat d'exécution des cas de test, tests de fumée, tests de santé mentale, test exploratoire - feuilles de calcul
Enfin, si un outil de gestion des tests a été utilisé pour créer et gérer le scénario de test, il peut également être utilisé pour l'exécution des tests. L'utilisation d'un outil facilite la création de rapports, mais sinon, le processus d'exécution des cas de test est le même. Veuillez consulter cet article pour avoir une idée de comment utiliser HP ALM pour l'exécution de cas de test .
(Cliquez sur l'image pour une vue agrandie)
Cela nous amène à la fin d'un autre segment intéressant du processus de test. Dans le prochain et dernier article de ce mini-cours de formation en ligne gratuit sur le contrôle qualité des tests de logiciels , nous examinerons les défauts en détail; récapitulez des sujets tels que «quand arrêter les tests», les mesures et l'approbation du contrôle qualité.
=> Formation QA Jour 6: Suivi des bogues, mesures de test et validation des tests
S'il vous plaît laissez-nous savoir comment nous faisons et restez à l'écoute pour le prochain article.
lecture recommandée
- Programme de cours de test de logiciels - Plan de formation détaillé du cours en ligne
- Quelques questions d'entretien intéressantes sur les tests de logiciels
- Commentaires et évaluations du cours de test de logiciels
- Comment rapporter intelligemment l'exécution des tests - (Télécharger le modèle de rapport d'état)
- Comment rédiger un document de stratégie de test (avec un exemple de modèle de stratégie de test)
- Exemple de modèle de plan de test logiciel avec format et contenu
- Différence exacte entre la vérification et la validation avec des exemples
- Métriques et mesures de test logiciel importantes - expliquées avec des exemples et des graphiques