smoke testing vs sanity testing
Explorez les différences entre les tests de fumée et les tests de santé mentale en détail avec des exemples:
Dans ce didacticiel, nous allons apprendre ce que sont les tests d'intégrité et les tests de fumée dans les tests logiciels. Nous apprendrons également les principales différences entre les tests de santé mentale et de fumée avec des exemples simples.
La plupart du temps, nous sommes confus entre la signification des tests de santé mentale et des tests de fumée. Tout d'abord, ces deux tests sont bien ' différent »Et sont effectués à différentes étapes d'un cycle de test.
Ce que vous apprendrez:
- Test de santé mentale
- Mon expérience
- Test de santé mentale et test de régression
- Stratégie de test des applications mobiles
- Des mesures de précaution
- Test de fumée
- Exemples de tests de fumée
- Importance dans la méthodologie SCRUM
- Test de fumée vs test d'acceptation de construction
- Cycle d'essai de fumée
- Qui devrait effectuer le test de fumée?
- Pourquoi devrions-nous automatiser les tests de fumée?
- Avantages et inconvénients
- Différence entre les tests de fumée et de santé mentale
- lecture recommandée
Test de santé mentale
Le test d'intégrité est effectué lorsque, en tant que QA, nous n'avons pas suffisamment de temps pour exécuter tous les cas de test, que ce soit Test fonctionel , UI, OS ou Browser Testing.
Par conséquent, je définirais,
«Le test d'intégrité en tant qu'exécution de test qui est effectuée pour toucher chaque implémentation et son impact, mais pas de manière approfondie ou approfondie, peut inclure des tests fonctionnels, d'interface utilisateur, de version, etc. en fonction de l'implémentation et de son impact.»
Ne tombons-nous pas tous dans une situation où nous devons signer dans un jour ou deux, mais la version de test n’est toujours pas publiée?
convertisseur gratuit youtube en mp4 pour mac
Ah oui, je vous parie que vous avez également dû faire face à cette situation au moins une fois dans votre expérience de test de logiciels. Eh bien, je l'ai beaucoup affronté parce que mes projets étaient pour la plupart agiles et parfois on nous a demandé de les livrer le jour même. Oups, comment puis-je tester et publier la version en quelques heures?
J'avais l'habitude de devenir fou parfois parce que même s'il s'agissait d'une petite fonctionnalité, l'implication pouvait être énorme. Cerise sur le gâteau, les clients refusent parfois tout simplement de donner du temps supplémentaire. Comment pourrais-je terminer l'ensemble des tests en quelques heures, vérifier toutes les fonctionnalités, Insectes et le libérer?
La réponse à tous ces problèmes était très simple, c'est-à-dire rien que d'utiliser Stratégie de test de santé mentale.
Lorsque nous testons un module ou une fonctionnalité ou un système complet, le Cas de test pour l'exécution sont sélectionnés de telle sorte qu'ils touchent tous les bits et morceaux importants du même test, c'est-à-dire un test large mais peu profond.
Parfois, les tests sont même effectués au hasard sans cas de test. Mais rappelles-toi, Le test d'intégrité ne doit être effectué que lorsque vous manquez de temps, ne l'utilisez jamais pour vos versions régulières. Théoriquement, ce test est un sous-ensemble de Les tests de régression .
Mon expérience
Sur plus de 8 ans de carrière dans le domaine des tests logiciels, pendant 3 ans, j'ai travaillé Méthodologie agile y et c'était le moment où j'ai surtout utilisé un test de santé mentale.
Toutes les grandes versions étaient planifiées et exécutées de manière systématique, mais parfois, de petites versions devaient être livrées le plus tôt possible. Nous n'avons pas eu beaucoup de temps pour documenter les cas de test, exécuter, faire la documentation des bogues, faire la régression et suivre l'ensemble du processus.
Par conséquent, voici quelques-uns des indicateurs clés que j'ai l'habitude de suivre dans de telles situations:
#1) Asseyez-vous avec le responsable et l'équipe de développement lorsqu'ils discutent de la mise en œuvre, car ils doivent travailler rapidement et nous ne pouvons donc pas nous attendre à ce qu'ils nous expliquent séparément.
Cela vous aiderait également à avoir une idée de ce qu'ils vont mettre en œuvre, de quel domaine cela affectera-t-il, etc., c'est une chose très importante à faire car parfois nous ne réalisons tout simplement pas les implications et s'il existe des fonctionnalités existantes va être gêné (au pire).
#deux) Comme vous manquez de temps, au moment où l'équipe de développement travaille sur l'implémentation, vous pouvez noter les cas de test à peu près dans des outils comme Evernote, etc. Mais assurez-vous de les écrire quelque part afin de pouvoir les ajouter plus tard à l'outil de cas de test.
# 3) Gardez votre banc de test prêt conformément à la mise en œuvre et si vous pensez qu'il y a des drapeaux rouges comme une création de données spécifiques si un banc de test prendra du temps (et c'est un test important pour la version), alors augmentez immédiatement ces drapeaux et informez votre responsable ou PO sur le barrage routier.
Ce n'est pas parce que le client le souhaite au plus vite que cela ne signifie pas qu'un contrôle qualité sera publié même s'il est à moitié testé.
# 4) Convenez avec votre équipe et votre manager qu'en raison du manque de temps, vous ne communiquerez les bogues qu'à l'équipe de développement et le processus formel d'ajout, le marquage des bogues pour les différentes étapes de l'outil de suivi des bogues sera effectué plus tard afin de gagner du temps .
# 5) Lorsque l'équipe de développement teste à la fin, essayez de s'associer avec eux (appelé appariement dev-QA) et faites un tour de base sur leur configuration elle-même, cela aidera à éviter les va-et-vient de la construction si l'implémentation de base échoue. .
# 6) Maintenant que vous avez la version, testez d'abord les règles métier et tous les cas d'utilisation. Vous pouvez conserver des tests comme la validation d'un champ, la navigation, etc. pour plus tard.
# 7) Quels que soient les bogues que vous trouvez, notez-les tous et essayez de les rapporter ensemble aux développeurs plutôt que de les signaler individuellement car il leur sera facile de travailler sur un tas.
# 8) Si vous avez une exigence pour l'ensemble Test de performance ou Test de stress ou de charge, puis assurez-vous que vous disposez d'un cadre d'automatisation approprié pour le même. Parce qu'il est presque impossible de les tester manuellement avec un test de cohérence.
# 9) Il s'agit de la partie la plus importante, et même de la dernière étape de votre stratégie de test de cohérence - «Lorsque vous rédigez le courrier électronique de publication ou le document, mentionnez tous les scénarios de test que vous avez exécutés, les bogues trouvés avec un marqueur de statut et s'il reste quelque chose non testé le mentionner avec les raisons ' Essayez d'écrire une histoire claire sur vos tests qui communiquera à tout le monde ce qui a été testé, vérifié et ce qui ne l'a pas été.
J'ai suivi cela religieusement lorsque j'utilisais ce test.
Laissez-moi partager ma propre expérience:
#1) Nous travaillions sur un site Web et il utilisait des annonces contextuelles basées sur les mots-clés. Les annonceurs avaient l'habitude de placer l'enchère pour des mots clés particuliers qui avaient un écran conçu pour les mêmes. Auparavant, la valeur de l'enchère par défaut était de 0,25 USD, ce que le soumissionnaire pouvait même modifier.
Il y avait un autre endroit où cette enchère par défaut s'affichait et pouvait également être remplacée par une autre valeur. Le client est venu avec une demande de modification de la valeur par défaut de 0,25 $ à 0,5 $, mais il n'a mentionné que l'écran évident.
Lors de notre discussion de brainstorming, nous avons oublié (?) Cet autre écran car il n’était pas beaucoup utilisé à cette fin. Mais en testant lorsque j'ai exécuté le cas de base de l'offre à 0,5 USD et vérifié de bout en bout, j'ai constaté que le cronjob pour la même chose échouait car à un endroit, il trouvait 0,25 USD.
J'ai signalé cela à mon équipe et nous avons fait le changement et l'avons livré avec succès le même jour.
#deux) Dans le cadre du même projet (mentionné ci-dessus), on nous a demandé d'ajouter un petit champ de texte pour les notes / commentaires pour l'appel d'offres. C'était une mise en œuvre très simple et nous nous sommes engagés à la livrer le jour même.
Par conséquent, comme mentionné ci-dessus, j'ai testé toutes les règles métier et les cas d'utilisation qui l'entourent et lorsque j'ai fait des tests de validation, j'ai constaté que lorsque j'ai entré une combinaison de caractères spéciaux comme, la page se plantait.
Nous y avons réfléchi et avons compris que les soumissionnaires réels n’utiliseraient en aucun cas de telles combinaisons. Par conséquent, nous l'avons publié avec une note bien rédigée sur le problème. Le client a accepté cela comme un bogue mais a accepté avec nous de l'implémenter plus tard car c'était un bogue grave mais pas un bogue antérieur.
# 3) Récemment, je travaillais sur un projet d'application mobile et nous devions mettre à jour l'heure de livraison indiquée dans l'application en fonction du fuseau horaire. Ce n'était pas seulement à tester dans l'application mais aussi pour le service Web.
Pendant que l'équipe de développement travaillait sur l'implémentation, j'ai créé les scripts d'automatisation pour le test du service Web et les scripts de base de données pour modifier le fuseau horaire de l'élément de livraison. Cela a sauvé mes efforts et nous avons pu obtenir de meilleurs résultats en peu de temps.
Test de santé mentale et test de régression
Voici quelques différences entre les deux:
S. Non. | Les tests de régression | Test de santé mentale |
---|---|---|
7 | Ces tests sont parfois programmés sur des semaines, voire des mois. | Cela s'étend principalement sur 2-3 jours maximum. |
1 | Les tests de régression sont effectués pour vérifier que le système complet et les corrections de bogues fonctionnent correctement. | Les tests d'intégrité sont effectués au hasard pour vérifier que chaque fonctionnalité fonctionne comme prévu. |
deux | Chaque plus petite partie est régressée dans ce test. | Il ne s’agit pas d’un test planifié et n’est effectué que lorsque le temps presse. |
3 | C'est un test bien élaboré et planifié. | Il ne s’agit pas d’un test planifié et n’est effectué que lorsque le temps presse. |
4 | Une suite de cas de test conçue de manière appropriée est créée pour ces tests. | Il peut ne pas être possible à chaque fois de créer les cas de test; un ensemble approximatif de cas de test est généralement créé. |
5 | Cela comprend une vérification approfondie des fonctionnalités, de l'interface utilisateur, des performances, des tests du navigateur / du système d'exploitation, etc., c'est-à-dire que chaque aspect du système est régressé. | Cela comprend principalement la vérification des règles métier, des fonctionnalités. |
6 | Il s'agit d'un test large et approfondi. | Il s'agit d'un test large et peu profond. |
Stratégie de test des applications mobiles
Vous devez vous demander pourquoi je mentionne spécifiquement les applications mobiles ici?
La raison en est que la version du système d'exploitation et du navigateur pour les applications Web ou de bureau ne varie pas beaucoup et en particulier les tailles d'écran sont standard. Mais avec les applications mobiles, la taille de l'écran, le réseau mobile, les versions du système d'exploitation, etc. affectent la stabilité, l'apparence et, en bref, le succès de votre application mobile.
Par conséquent, une formulation de stratégie devient essentielle lorsque vous effectuez ces tests sur une application mobile, car un échec peut vous causer de gros problèmes. Les tests doivent également être effectués intelligemment et avec prudence.
Voici quelques conseils pour vous aider à effectuer ce test avec succès sur une 'application mobile':
#1) Tout d'abord, analysez l'impact de la version du système d'exploitation sur l'implémentation avec votre équipe.
Essayez de trouver des réponses à des questions telles que: le comportement sera-t-il différent d'une version à l'autre? L'implémentation fonctionnera-t-elle sur la version la plus basse prise en charge ou non? Y aura-t-il des problèmes de performances pour la mise en œuvre des versions? Y a-t-il une caractéristique spécifique du système d'exploitation qui pourrait avoir un impact sur le comportement de l'implémentation? etc.
#deux) Sur la note ci-dessus, analysez également les modèles de téléphone, c'est-à-dire y a-t-il des fonctionnalités du téléphone qui auront un impact sur la mise en œuvre? La mise en œuvre du comportement change-t-elle avec le GPS? Le comportement de mise en œuvre change-t-il avec la caméra du téléphone? etc. Si vous constatez qu’il n’ya aucun impact, évitez de tester sur différents modèles de téléphone.
# 3) Sauf s'il y a des changements d'interface utilisateur pour l'implémentation, je recommanderais de garder les tests d'interface utilisateur sur la moindre priorité, vous pouvez informer l'équipe (si vous le souhaitez) que l'interface utilisateur ne sera pas testée.
# 4) Afin de gagner du temps, évitez de tester sur de bons réseaux car il est évident que la mise en œuvre va fonctionner comme prévu sur un réseau solide. Je recommanderais de commencer par des tests sur un réseau 4G ou 3G.
# 5) Ces tests doivent être effectués en moins de temps, mais assurez-vous de faire au moins un test sur le terrain, sauf s'il s'agit d'un simple changement d'interface utilisateur.
# 6) Si vous devez tester une matrice de différents OS et leur version, je vous suggère de le faire de manière intelligente. Par exemple, choisissez les paires de versions de système d'exploitation les plus faibles, les moyennes et les dernières pour les tests. Vous pouvez mentionner dans le document de version que toutes les combinaisons ne sont pas testées.
# 7) Sur une ligne similaire, pour le test de cohérence de la mise en œuvre de l'interface utilisateur, utilisez des tailles d'écran petites, moyennes et grandes pour gagner du temps. Vous pouvez également utiliser un simulateur et un émulateur.
Des mesures de précaution
Les tests d'intégrité sont effectués lorsque vous manquez de temps et par conséquent, il n'est pas possible pour vous d'exécuter chaque cas de test et, plus important encore, vous n'avez pas assez de temps pour planifier vos tests. Afin d'éviter les jeux de blâme, il vaut mieux prendre des mesures de précaution.
Dans de tels cas, le manque de communication écrite, la documentation du test et les manquements sont assez courants.
Pour ne pas en être la proie, assurez-vous que:
- N'acceptez jamais une construction pour le test tant que vous n'avez pas reçu d'exigence écrite partagée par le client. Il arrive que les clients communiquent des changements ou de nouvelles implémentations verbalement ou dans le chat ou une simple ligne 1 dans un e-mail et s'attendent à ce que nous traitions cela comme une exigence. Obligez votre client à fournir quelques points de fonctionnalités de base et des critères d'acceptation.
- Prenez toujours des notes approximatives de vos cas de test et de vos bogues si vous n'avez pas assez de temps pour les écrire proprement. Ne laissez jamais ces documents sans papiers. S'il reste du temps, partagez-le avec votre responsable ou votre équipe afin que, s'il manque quelque chose, ils puissent le signaler facilement.
- Si vous et votre équipe manquez de temps, assurez-vous que les bogues sont signalés dans l'état approprié dans un e-mail? Vous pouvez envoyer la liste complète des bogues à l'équipe et demander aux développeurs de les marquer de manière appropriée. Gardez toujours la balle dans le camp de l’autre.
- Si tu as Framework d'automatisation prêt, utilisez-le et évitez de faire Test manuel , de cette façon en moins de temps, vous pouvez couvrir plus.
- Évitez le scénario de «libération dans 1 heure» à moins d'être sûr à 100% de pouvoir livrer.
- Dernier point mais non le moindre, comme mentionné ci-dessus, rédigez un e-mail de publication détaillé communiquant ce qui est testé, ce qui est laissé de côté, les raisons, les risques, les bogues résolus, ce qui est «postérieur», etc.
En tant que QA, vous devez juger quelle est la partie la plus importante de l'implémentation qui doit être testée et quelles sont les parties qui peuvent être laissées de côté ou testées de base.
meilleur site de convertisseur youtube en mp3
Même dans un court laps de temps, planifiez une stratégie sur la façon dont vous voulez faire et vous serez en mesure de réaliser le meilleur dans le laps de temps donné.
Test de fumée
Les tests de fumée ne sont pas des tests exhaustifs, mais c'est un groupe de tests qui sont exécutés pour vérifier si les fonctionnalités de base de cette version particulière fonctionnent correctement comme prévu ou non. C’est et doit toujours être le premier test à effectuer sur une «nouvelle» version.
Lorsque l'équipe de développement publie une version au QA pour les tester, il n'est évidemment pas possible de tester la version entière et de vérifier immédiatement si l'une des implémentations présente des bogues ou si l'une des fonctionnalités fonctionnelles est cassée.
À la lumière de cela, comment un QA s'assurera-t-il que les fonctionnalités de base fonctionnent correctement?
La réponse à cela sera d'effectuer un Test de fumée .
Une fois que les tests sont marqués comme des tests Smoke (dans la suite de tests) réussis, alors seulement la construction est acceptée par le QA pour des tests approfondis et / ou une régression. Si l'un des tests de fumée échoue, la version est rejetée et l'équipe de développement doit résoudre le problème et publier une nouvelle version pour test.
Théoriquement, le test de fumée est défini comme un test au niveau de la surface pour certifier que la version fournie par l'équipe de développement à l'équipe d'assurance qualité est prête pour des tests supplémentaires. Ce test est également effectué par l'équipe de développement avant de publier la version à l'équipe d'assurance qualité.
Ces tests sont normalement utilisés dans les tests d'intégration, les tests système et les tests de niveau d'acceptation. Ne considérez jamais cela comme un substitut au test complet de bout en bout. . Il comprend des tests positifs et négatifs en fonction de l'implémentation de la construction.
Exemples de tests de fumée
Ce test est normalement utilisé pour l'intégration, l'acceptation et Test du système .
Dans ma carrière en tant que QA, j'ai toujours accepté une construction seulement après avoir effectué un test de fumée. Alors, voyons ce qu'est un test de fumée du point de vue de ces trois tests, avec quelques exemples.
# 1) Test d'acceptation
Chaque fois qu'une version est publiée pour le contrôle qualité, un test de fumée sous la forme d'un Test d'acceptation devrait être fait.
Dans ce test, le premier et le plus important test de fumée consiste à vérifier la fonctionnalité de base attendue de l'implémentation. Comme ça, vous devriez vérifier toutes les implémentations pour cette version particulière.
Prenons les exemples suivants comme implémentations effectuées dans une construction pour comprendre les tests de fumée pour ceux-ci:
- Implémentation de la fonctionnalité de connexion pour permettre aux pilotes enregistrés de se connecter avec succès.
- Implémentation de la fonctionnalité de tableau de bord pour afficher les itinéraires qu'un conducteur doit exécuter aujourd'hui.
- Implémentation de la fonctionnalité pour afficher un message approprié si aucune route n'existe pour un jour donné.
Dans la version ci-dessus, au niveau de l'acceptation, le test de fumée signifie vérifier que les trois implémentations de base fonctionnent correctement. Si l'un de ces trois éléments est cassé, le contrôle qualité doit rejeter la construction.
# 2) Test d'intégration
Ce test est généralement effectué lorsque les modules individuels sont mis en œuvre et testés. Dans le Test d'intégration niveau, ce test est effectué pour s'assurer que toutes les fonctionnalités d'intégration de base et de bout en bout fonctionnent correctement comme prévu.
Il peut s'agir de l'intégration de deux modules ou de tous les modules ensemble, donc la complexité du test de fumée variera en fonction du niveau d'intégration.
Considérons les exemples suivants d'implémentation d'intégration pour ce test:
- Implémentation de l'intégration des modules d'itinéraire et d'arrêts.
- Implémentation de l'intégration de la mise à jour de l'état d'arrivée et refléter la même chose sur l'écran des arrêts.
- Implémentation de l'intégration du ramassage complet jusqu'aux modules de fonctionnalité de livraison.
Dans cette version, le test de fumée vérifiera non seulement ces trois implémentations de base, mais pour la troisième implémentation, quelques cas vérifieront également l'intégration complète. Cela aide beaucoup à découvrir les problèmes qui sont introduits dans l'intégration et ceux qui sont passés inaperçus par l'équipe de développement.
# 3) Test du système
Comme son nom l'indique, au niveau du système, le test de fumée comprend des tests pour les flux de travail les plus importants et les plus couramment utilisés du système. Cela n'est fait qu'une fois que le système complet est prêt et testé, et ce test au niveau du système peut également être appelé test de fumée avant le test de régression.
Avant de commencer la régression du système complet, les fonctionnalités de base de bout en bout sont testées dans le cadre du test de fumée. La suite de tests de fumée pour le système complet comprend des cas de test de bout en bout que les utilisateurs finaux vont utiliser très fréquemment.
Cela se fait généralement à l'aide d'outils d'automatisation.
Importance dans la méthodologie SCRUM
De nos jours, les projets suivent à peine la méthodologie Waterfall dans la mise en œuvre des projets, la plupart des projets suivent Agile et SCRUM seul. Comparé à la méthode traditionnelle en cascade, le test de fumée est très respecté dans SCRUM et Agile.
J'ai travaillé 4 ans chez SCRUM . Et comme nous savons que dans SCRUM, les sprints sont de durée plus courte et il est donc extrêmement important de faire ces tests, afin que les builds ayant échoué puissent être immédiatement signalés à l'équipe de développement et corrigés également.
Voici quelques emporter sur l'importance de ce test dans SCRUM:
- Sur le sprint de quinze jours, la mi-temps est allouée au QA mais parfois les builds au QA sont retardés.
- Dans les sprints, il est préférable pour l'équipe que les problèmes soient signalés à un stade précoce.
- Chaque histoire a un ensemble de critères d'acceptation, donc tester les 2-3 premiers critères d'acceptation est égal au test de fumée de cette fonctionnalité. Les clients refusent la livraison si un seul critère échoue.
- Imaginez ce qui se passera si l’équipe de développement vous a livré la version dans deux jours et qu’il ne vous reste que trois jours pour la démo et que vous rencontrez un échec des fonctionnalités de base.
- En moyenne, un sprint a des histoires allant de 5 à 10, par conséquent, lorsque la construction est donnée, il est important de s'assurer que chaque histoire est implémentée comme prévu avant d'accepter la construction dans le test.
- Lorsque le système complet doit être testé et régressé, un sprint est dédié à l'activité. Une quinzaine de jours peut-être un peu moins pour tester l'ensemble du système, il est donc très important de vérifier les fonctionnalités les plus basiques avant de commencer la régression.
Test de fumée vs test d'acceptation de construction
Les tests de fumée sont directement liés aux tests d'acceptation de construction (BAT).
Dans BAT, nous faisons les mêmes tests - pour vérifier si la construction n'a pas échoué et que le système fonctionne correctement ou non. Parfois, il arrive que lors de la création d’une build, certains problèmes soient introduits et lorsqu’elle est livrée, la build ne fonctionne pas pour le contrôle qualité.
Je dirais que BAT fait partie d'un contrôle de fumée parce que si le système échoue, comment pouvez-vous en tant que QA accepter la construction pour le test? Pas seulement les fonctionnalités, le système lui-même doit fonctionner avant que le contrôle qualité ne procède à des tests approfondis.
Cycle d'essai de fumée
L'organigramme suivant explique le cycle d'analyse de la fumée.
Une fois qu'une build est déployée sur un QA, le cycle de base suivi est que si le test de fumée réussit, la build est acceptée par l'équipe QA pour des tests supplémentaires, mais si elle échoue, la build est rejetée jusqu'à ce que les problèmes signalés soient résolus.
Cycle d'essai
Qui devrait effectuer le test de fumée?
Toute l’équipe n’est pas impliquée dans ce type de tests pour éviter le gaspillage de temps de tous les QA.
Le test de fumée est idéalement effectué par le responsable QA qui décide en fonction du résultat de transmettre la construction à l'équipe pour des tests supplémentaires ou de la rejeter. Ou en l’absence du chef de file, les responsables de l’assurance qualité peuvent eux-mêmes effectuer ces tests.
Parfois, lorsque le projet est à grande échelle, un groupe de contrôle qualité peut également effectuer ces tests pour vérifier s'il y a des bouchons. Mais ce n'est pas le cas dans le cas de SCRUM car SCRUM est une structure plate sans Leads ou Managers et chaque testeur a ses propres responsabilités vis-à-vis de ses histoires.
Par conséquent, les contrôleurs de qualité individuels effectuent ces tests pour les histoires dont ils sont propriétaires.
Pourquoi devrions-nous automatiser les tests de fumée?
Ce test est le premier test à effectuer sur une version publiée par l'équipe ou les équipes de développement. Sur la base des résultats de ces tests, des tests supplémentaires sont effectués (ou la construction est rejetée).
La meilleure façon de faire ces tests est d'utiliser un outil d'automatisation et de planifier l'exécution de la suite de fumée lors de la création d'une nouvelle version. Vous vous demandez peut-être pourquoi devrais-je «Automatiser la suite de tests de fumée»?
Regardons le cas suivant:
Supposons que vous soyez à une semaine de votre sortie et que sur les 500 scénarios de test au total, votre suite de tests de fumée comprend 80 à 90. Si vous commencez à exécuter manuellement tous ces cas de test 80-90, imaginez combien de temps vous faudra-t-il? Je pense 4-5 jours (minimum).
Mais si vous utilisez l'automatisation et créez des scripts pour exécuter tous ces cas de test 80-90, idéalement, ceux-ci seront exécutés dans 2-3 heures et vous aurez instantanément les résultats avec vous. Cela ne vous a-t-il pas fait gagner un temps précieux et vous a-t-il permis d’obtenir des résultats en moins de temps?
Il y a 5 ans, je testais une application de projection financière, qui prenait des informations sur votre salaire, vos économies, etc., et projetait vos impôts, économies, bénéfices en fonction des règles financières. Parallèlement à cela, nous avons eu une personnalisation pour les pays qui dépendent du pays et de ses règles fiscales utilisées pour changer (dans le code).
Pour ce projet, j'avais 800 cas de test et 250 étaient des cas de test de fumée. Avec l'utilisation de Selenium, nous pourrions facilement automatiser et obtenir les résultats de ces 250 cas de test en 3-4 heures. Cela nous a non seulement permis de gagner du temps, mais nous a montré dès que possible les bouchons.
Par conséquent, à moins qu'il ne soit impossible d'automatiser, prenez l'aide de l'automatisation pour ces tests.
Avantages et inconvénients
Jetons d'abord un coup d'œil aux avantages car il a beaucoup à offrir par rapport à ses quelques inconvénients.
Avantages:
- Facile à réaliser.
- Réduit le risque.
- Les défauts sont identifiés à un stade très précoce.
- Économise des efforts, du temps et de l'argent.
- Fonctionne rapidement s'il est automatisé.
- Moins de risques et de problèmes d'intégration.
- Améliore la qualité globale du système.
Désavantages:
- Ce test n'est pas égal ou ne remplace pas un test fonctionnel complet.
- Même après la réussite du test de fumée, vous pouvez trouver des bugs showstopper.
- Ce type de test est le mieux adapté si vous pouvez automatiser sinon beaucoup de temps est consacré à l'exécution manuelle des cas de test, en particulier dans les projets à grande échelle ayant environ 700 à 800 cas de test.
Des tests de fumée doivent absolument être effectués sur chaque build car ils mettent en évidence les principaux échecs et les problèmes à un stade très précoce. Cela s'applique non seulement aux nouvelles fonctionnalités mais aussi à l'intégration de modules, à la résolution de problèmes et à l'improvisation. C'est un processus très simple à réaliser et à obtenir le résultat correct.
Ce test peut être considéré comme le point d'entrée pour un test fonctionnel complet de la fonctionnalité ou du système (dans son ensemble). Mais avant ça, l'équipe d'AQ doit être très claire sur les tests à effectuer en tant que tests de fumée . Ces tests peuvent minimiser les efforts, gagner du temps et améliorer la qualité du système. Il tient une place très importante dans les sprints car le temps dans les sprints est moindre.
Ces tests peuvent être effectués à la fois manuellement et à l'aide d'outils d'automatisation. Mais le meilleur moyen est d'utiliser des outils d'automatisation pour gagner du temps.
Différence entre les tests de fumée et de santé mentale
La plupart du temps, nous sommes confus entre la signification des tests de santé mentale et des tests de fumée. Tout d'abord, ces deux tests sont bien ' différent »Et effectué à différentes étapes d'un cycle de test.
S. Non. | Test de fumée | Test de santé mentale |
---|---|---|
1 | Le test de fumée signifie vérifier (de base) que les implémentations effectuées dans une construction fonctionnent correctement. | Les tests d'intégrité permettent de vérifier que les fonctionnalités nouvellement ajoutées, les bogues, etc. fonctionnent correctement. |
deux | Il s'agit du premier test de la version initiale. | Fait lorsque la construction est relativement stable. |
3 | Fait à chaque construction. | Fait sur les builds stables après la régression. |
Voici une représentation schématique de leurs différences:
TEST DE FUMÉE
- Ce test est né dans le Matériel tester la pratique consistant à allumer un nouveau matériel pour la première fois et à le considérer comme un succès s'il ne prend pas feu et ne fume pas. Dans l'industrie du logiciel, ce test est une approche superficielle et large dans laquelle tous les domaines de l'application sans entrer dans trop de profondeur, sont testés.
- Un test de fumée est scénarisé, soit à l'aide d'un ensemble de tests écrits, soit d'un test automatisé
- Un test de fumée est conçu pour toucher chaque partie de l'application de manière superficielle. C'est peu profond et large.
- Ces tests sont effectués pour s'assurer que les fonctions les plus cruciales d'un programme fonctionnent, mais ne se soucient pas des détails les plus fins. (Tels que la vérification de la construction).
- Ce test est un bilan de santé normal de la construction d'une application avant de la tester en profondeur.
TEST DE SANTE
- Un test de cohérence est un test de régression étroit qui se concentre sur un ou quelques domaines de fonctionnalité. Les tests de santé mentale sont généralement étroits et approfondis.
- Ce test est généralement non scripté.
- Ce test est utilisé pour déterminer qu'une petite section de l'application fonctionne toujours après une modification mineure.
- Ce test est un test superficiel, il est effectué chaque fois qu'un test superficiel est suffisant pour prouver que l'application fonctionne selon les spécifications. Ce niveau de test est un sous-ensemble des tests de régression.
- Il s'agit de vérifier si les exigences sont remplies ou non, en vérifiant d'abord toutes les fonctionnalités.
J'espère que vous êtes clair sur les différences entre ces deux types de tests logiciels vastes et importants. N'hésitez pas à partager vos réflexions dans la section commentaires ci-dessous !!
lecture recommandée
- Meilleurs outils de test de logiciels 2021 [Outils d'automatisation des tests QA]
- Différence entre les tests de bureau, client-serveur et Web
- Test fonctionnel vs test non fonctionnel
- Téléchargement de l'e-book 'Testing Primer'
- Test alpha et test bêta (un guide complet)
- Guide de test de portabilité avec des exemples pratiques
- Types de tests logiciels: différents types de tests avec des détails
- Test fonctionnel vs test de performance: doit-il être fait simultanément?