Good Mood

explorez les différences entre les tests de fumée et les tests de santé mentale en détail avec des exemples:

dans ce tutoriel, nous allons apprendre ce que sont les tests de santé mentale 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 essais sont bien « différents” et sont réalisés au cours de différentes étapes d’un cycle d’essai.,

tests de santé mentale

Les tests de santé mentale sont effectués lorsque, en tant qu’Assurance Qualité, nous n’avons pas suffisamment de temps pour exécuter tous les cas de test, Qu’il s’agisse de tests fonctionnels, D’interface utilisateur, de système d’exploitation ou de navigateur.

Par conséquent, je définirais,

« Sanity Testing comme une exécution de test qui est faite pour toucher chaque implémentation et son impact mais pas complètement ou en profondeur, cela peut inclure fonctionnel, interface utilisateur, version, etc. tests en fonction de la mise en œuvre et de son impact.”

Ne pas nous tombons tous dans une situation où nous devons signer dans un jour ou deux, mais la version à tester est pas encore sorti?,

Ah oui, je vous parie que vous devez également avoir fait face à cette situation au moins une fois dans votre expérience de test de logiciel. Eh bien, j’y ai fait face beaucoup parce que mon(mes) projet (s) étaient pour la plupart agiles et parfois on nous a demandé de le livrer le jour même. Oups, Comment pourrais-je tester et libérer la build en quelques heures?

je devenais parfois fou parce que même si c’était une petite fonctionnalité, l’implication pourrait être énorme. Et comme cerise sur le gâteau, les clients refusent parfois simplement de donner du temps supplémentaire., Comment pourrais-je terminer l’ensemble des tests en quelques heures, vérifier toutes les fonctionnalités, les bogues et les libérer?

la réponse à tous ces problèmes était très simple, c’est-à-dire rien d’autre que d’utiliser une stratégie de test de santé mentale.

lorsque nous effectuons ce test pour un module ou une fonctionnalité ou un système complet, les cas de Test pour l’exécution sont sélectionnés de manière à toucher tous les bits importants du même test, c’est-à-dire des tests larges mais peu profonds.

parfois, le test est même effectué de manière aléatoire sans cas de test., Mais rappelez-vous, le test de santé mentale 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 tests de régression.

mon expérience

Sur mes 8+ années de carrière dans le test de logiciels, pendant 3 ans, je travaillais en méthodologie Agile et c’était l’époque où j’utilisais surtout un test de santé mentale.

Toutes les grandes versions ont été planifiées et exécutées de manière systématique, mais parfois, les 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.

Voici donc quelques-uns des conseils clés que je suivais dans de telles situations:

#1) asseyez-vous avec le gestionnaire et l’équipe de développement lorsqu’ils discutent de l’implémentation 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 à vous faire 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 parce que parfois nous ne réalisons tout simplement pas les implications et si une fonctionnalité existante va être entravée (au pire).

#2) 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 d’essai prêt selon l’implémentation et si vous pensez qu’il y a des drapeaux rouges comme une création de données spécifique si un banc d’essai prendra du temps (et c’est un test important pour la version), alors levez ces drapeaux immédiatement et informez votre gestionnaire ou PO du barrage routier.

juste parce que le client veut dès que possible, cela ne signifie pas qu’une QA sera libérée même si elle est à moitié testée.,

#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, de 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 à sa fin, essayez de les coupler (appelé appairage 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 construire, tester les règles et tous les cas d’utilisation première. Vous pouvez conserver des tests comme la validation d’un champ, la navigation, etc. pour plus tard.

#7) Quels que soient les bugs que vous trouvez, notez-les tous et essayez de les signaler 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 besoin des tests de Performance globale ou des tests de contrainte ou de charge, assurez-vous d’avoir un cadre d’automatisation approprié pour le même., Parce qu’il est presque impossible de les tester manuellement avec un test de santé mentale.

#9) c’est la partie la plus importante, et en fait la dernière étape de votre stratégie de test de santé mentale – « lorsque vous rédigez l’e-mail de publication ou le document, mentionnez tous les cas de test que vous avez exécutés, les bogues trouvés avec un marqueur d’état et si quelque chose n’a pas été testé, mentionnez-le avec les raisons” essayez d’écrire une histoire claire sur vos tests qui transmettra à tout le monde ce qui a été testé, vérifié et ce qui n’a pas été.

j’ai suivi cela religieusement quand j’utilisais ce test.,

Permettez-moi de partager ma propre expérience:

#1) Nous avons travaillé sur un site web et utilisé pour afficher des annonces 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 le même. La valeur de l’enchère par défaut était affichée à 0,25$, que le soumissionnaire pouvait même modifier.

Il y avait un autre endroit où cette enchère par défaut s’affichait et elle pouvait également être changée en une autre valeur. Le client est venu avec une demande de changer 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é (?) à propos de cet autre écran car il n’a pas été beaucoup utilisé à cette fin. Mais lors des tests lorsque j’ai exécuté le cas de base de l’enchère étant de 0,5 $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$.

j’ai signalé cela à mon équipe et nous avons fait le changement et l’avons livré avec succès le même jour.

#2) 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 les enchères., 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 autour et quand 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 s’est

nous y avons réfléchi et avons compris que les enchérisseurs 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 la question., Le client a accepté cela comme un bogue mais a convenu avec nous de l’implémenter plus tard car il s’agissait d’un bogue grave mais pas antérieur.

#3) Récemment, je travaillais sur un projet d’application mobile, et nous avions l’obligation de mettre à jour l’Heure de livraison indiquée dans l’application selon le fuseau horaire. Il ne devait pas seulement être testé 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 changer 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.

la santé mentale de Test Vs Tests de Régression

etant Donné ci-dessous sont quelques différences entre les deux:

la Stratégie Pour l’Application Mobile de Test

Vous devez vous demander pourquoi je le mentionne spécifiquement sur les applications mobiles d’ici?

la raison en est que les versions du système d’exploitation et du navigateur pour les applications web ou de bureau ne varient 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 critique lorsque vous effectuez ce test sur une application mobile, car un échec peut vous poser de gros problèmes. Les tests doivent ê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 performance pour l’implémentation des versions? Existe-t-il une fonctionnalité spécifique du système d’exploitation qui pourrait avoir un impact sur le comportement de l’implémentation? etc.

#2) 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 l’appareil photo du téléphone? etc. Si vous constatez qu’il n’y a pas d’impact, évitez de tester sur différents modèles de téléphones.,

#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 l’implémentation va fonctionner comme prévu sur un réseau solide. Je recommanderais de commencer par tester sur un réseau 4G ou 3G.

#5) Ce test doit être effectué 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 la plus basse, moyenne et la dernière version du système d’exploitation à tester. Vous pouvez mentionner dans le document de publication que toutes les combinaisons ne sont pas testées.

#7) sur une ligne similaire, pour le test de santé mentale de l’implémentation de L’interface utilisateur, utilisez des tailles d’écran petites, moyennes et grandes pour gagner du temps. Vous pouvez également utiliser un simulateur et l’émulateur.,

mesures de précaution

Les tests de santé mentale sont effectués lorsque vous manquez de temps et qu’il ne vous est donc pas possible d’exécuter chaque cas de test et, surtout, vous n’avez pas assez de temps pour planifier vos tests. Afin d’éviter les jeux de blâme, il est préférable de prendre des mesures de précaution.

dans de tels cas, le manque de communication écrite, la documentation des tests et les ratés sont assez courants.,

pour vous assurer que vous ne tombez pas en proie à cela, assurez-vous que:

• N’acceptez jamais une compilation pour les tests tant que vous n’avez pas reçu une 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 un simple 1 liner dans un e-mail et s’attendent à ce que nous traitions cela comme une exigence. Obligez votre client à fournir des points de fonctionnalité 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 suffisamment de temps pour les écrire proprement. Ne laissez jamais ces sans-papiers., S’il y a un certain temps, partagez-le avec votre chef 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 marqués dans l’état approprié dans un e-mail? Vous pouvez envoyer la liste complète des bogues à l’équipe et faire en sorte que les développeurs les marquent de manière appropriée. Gardez toujours la balle dans la Cour de l’autre.
• Si vous avez un Framework D’automatisation prêt, Utilisez-le et évitez de faire des tests manuels, de cette façon, en moins de temps, vous pouvez couvrir plus.,
• Évitez le scénario de « libération dans 1 heure » sauf si vous êtes sûr à 100% que vous serez en mesure de livrer.
• enfin, 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, quels bogues sont résolus, ce qui est « tardif », etc.

en tant qu’assurance qualité, 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.,

même en peu 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 délai imparti.

Smoke Testing

Smoke Testing n’est pas un test exhaustif, mais il s’agit d’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 devrait toujours être le premier test à faire sur les ‘nouveaux’ construire.,

lorsque l’équipe de développement publie une build dans L’assurance qualité pour les tests, il n’est évidemment pas possible de tester la build 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 de travail est cassée.

à la lumière de cela, comment une assurance qualité s’assurera-t-elle 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 ont été marqués comme des tests de fumée (dans la suite de tests), ce n’est qu’alors que la génération est acceptée par L’assurance qualité pour des tests approfondis et / ou une régression., Si l’un des tests smoke échoue, la génération est rejetée et l’équipe de développement doit résoudre le problème et publier une nouvelle génération pour les tests.

théoriquement, le test de fumée est défini comme un test au niveau de la surface pour certifier que la construction fournie par l’équipe de développement à l’équipe D’Assurance Qualité est prête pour d’autres tests. Ce test est également effectué par l’équipe de développement avant de publier la version à L’équipe D’Assurance Qualité.

Ce test est normalement utilisé dans les tests D’intégration, les tests de système et les tests de niveau D’acceptation. Ne traitez jamais cela comme un substitut au test complet de bout en bout., Il comprend des tests positifs et négatifs en fonction de la mise en œuvre de la construction.

exemples de tests de fumée

Ce test est normalement utilisé pour L’intégration, L’acceptation et les tests du système.

dans ma carrière en tant qu’AQ, j’ai toujours accepté une construction seulement après avoir effectué un test de fumée. Alors, comprenons 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 construction est libérée à L’AQ, un test de fumée sous la forme d’un test d’acceptation doit être effectué.,

dans ce test, le premier et le plus important test de fumée est de vérifier la fonctionnalité de base attendue de l’implémentation. Comme ceci, vous devez vérifier toutes les implémentations pour cette construction particulière.

prenons les exemples suivants comme implémentations effectuées dans une version pour comprendre les tests de fumée pour ceux-ci:

• implémenté la fonctionnalité de connexion pour permettre aux pilotes enregistrés de se connecter avec succès.
• implémenté la fonctionnalité de tableau de bord pour afficher les routes qu’un pilote doit exécuter aujourd’hui.,
• a implémenté 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 signifiera vérifier que les trois implémentations de base fonctionnent correctement. Si l’un de ces trois est cassé, alors L’assurance qualité devrait rejeter la construction.

#2) Test D’intégration

Ce test est généralement effectué lorsque les modules individuels sont implémentés et testés., Au niveau des tests D’intégration, ces tests sont effectués 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, d’où 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émenté L’intégration des modules route et stops.
• implémenté l’intégration de la mise à jour de l’état d’arrivée et de refléter la même chose sur l’écran des arrêts.,
• a implémenté l’intégration de modules complets de ramassage jusqu’à la livraison.

dans cette version, le test smoke vérifiera non seulement ces trois implémentations de base, mais pour la troisième implémentation, quelques cas vérifieront également une intégration complète. Il aide beaucoup à trouver les questions qui introduit dans l’intégration et ceux qui passaient inaperçus par l’équipe de développement.

#3) Test du système

comme son nom l’indique, pour le 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., Ceci n’est fait qu’après que le système complet est prêt & testé, et ce test au niveau du système peut également être appelé test de fumée avant test de régression.

avant de commencer la régression du système complet, les caractéristiques 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.

Ceci est habituellement fait avec l’aide d’outils d’automatisation.,

Importance dans la méthodologie SCRUM

de nos jours, les projets ne suivent guère la méthodologie Waterfall dans la mise en œuvre des projets, la plupart du temps tous les projets suivent Agile et SCRUM uniquement. Par rapport à la méthode traditionnelle en cascade, les tests de fumée sont très appréciés dans SCRUM et Agile.

j’ai travaillé pendant 4 ans dans SCRUM. Et comme nous savons que dans SCRUM, les sprints sont de durée plus courte et qu’il est donc extrêmement important de faire ces tests, afin que les builds défaillants puissent immédiatement être signalés à l’équipe de développement et corrigés.,

Voici quelques points à retenir sur l’importance de ce test dans SCRUM:

• sur le sprint de quinze jours, la mi-temps est allouée à L’AQ mais parfois les builds à L’AQ sont retardés.
• Dans les sprints, c’est mieux pour l’équipe que les problèmes sont 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 à tester la fumée de cette fonctionnalité. Les clients rejettent la livraison si un seul critère échoue.,
• imaginez ce qui se passera si c’est 2 jours que l’équipe de développement vous a livré la build et qu’il ne reste que 3 jours pour la démo et que vous rencontrez un échec de fonctionnalité 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 les tests.
• lorsque le système complet doit être testé et régressé, un sprint est dédié à l’activité., Une quinzaine 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 élémentaires 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 (MTD).

dans BAT, nous faisons le même test – pour vérifier si la construction n’a pas échoué et que le système fonctionne correctement ou non. Parfois, il arrive que lorsqu’une génération est créée, certains problèmes sont introduits et lorsqu’elle est livrée, la génération ne fonctionne pas pour L’Assurance 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 QU’Assurance Qualité accepter la construction pour les tests? Pas seulement les fonctionnalités, le système lui-même doit fonctionner avant que L’assurance qualité ne procède à des tests approfondis.

cycle D’essai de fumée

l’organigramme suivant explique le Cycle d’essai de fumée.

Une fois qu’une génération est déployée dans une assurance qualité, le cycle de base suivi est que si le test smoke réussit, la génération est acceptée par l’équipe D’assurance qualité pour des tests supplémentaires, mais si elle échoue, la génération est rejetée jusqu’à ce que les problèmes signalés soient résolus.,

Cycle d’essai

qui doit effectuer l’essai de fumée?

Ce n’est pas toute l’équipe qui est impliquée dans ce type de test pour éviter le gaspillage de temps de tous les tests D’Assurance Qualité.

Les tests de fumée sont idéalement effectués par le responsable de L’assurance qualité qui décide en fonction du résultat de transmettre la construction à l’équipe pour Ou en l’absence de plomb, les QA eux-mêmes peuvent également effectuer ces tests.

parfois, lorsque le projet est à grande échelle, un groupe D’assurance qualité peut également effectuer ces tests pour vérifier la présence de showstoppers., Mais ce n’est pas le cas dans le cas de SCRUM car SCRUM est une structure plate sans Leads ni Managers et chaque testeur a ses propres responsabilités envers ses histoires.

par conséquent, les QA individuels effectuent ce test pour les histoires qu’ils possèdent.

Pourquoi devrions-nous automatiser les tests de fumée?

Ce test est le premier à être effectué sur une version publiée par l’équipe de développement. Sur la base des résultats de ce test, d’autres tests sont effectués (ou la génération est rejetée).,

La meilleure façon d’effectuer ce test est d’utiliser un outil d’automatisation et de planifier la fumée suite à exécuter lorsqu’une nouvelle version est créée. Vous pensez peut-être Pourquoi devrais-je « automatiser la suite de tests de fumée”?

examinons le cas suivant:

disons que vous êtes à une semaine de votre sortie et que sur le total de 500 cas de test, votre suite de tests de fumée comprend 80 à 90. Si vous commencez à exécuter tous ces cas de test 80-90 manuellement, imaginez combien de temps prendrez-vous? Je pense que 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 en 2-3 heures et vous aurez les résultats avec vous instantanément. Cela n’a-t-il pas permis d’économiser votre temps précieux et de vous donner les résultats sur l’intégration beaucoup moins de temps?

Il y a 5 ans, je testais une application de projection financière, qui prenait des informations sur votre salaire, votre épargne, etc., et projeté 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’ai eu 800 cas de test et 250 étaient des cas de test de fumée. Avec L’utilisation du sélénium, nous pourrions facilement automatiser et obtenir les résultats de ces 250 cas de test en 3-4 heures. Il a non seulement sauvé notre temps, mais nous a montré dès que possible sur les showstoppers.

par conséquent, à moins qu’il ne soit impossible d’automatiser, prenez l’aide de l’automatisation pour ce test.

avantages et inconvénients

examinons d’abord les avantages car il a beaucoup à offrir par rapport à ses quelques inconvénients.

les Avantages:

• Facile à effectuer.
• Réduit le risque.,
• Les défauts sont identifiés très tôt.
• économise des efforts, du temps et de l’argent.
• s’Exécute rapidement s’il est automatisé.
• moins de risques et de problèmes d’intégration.
• Améliore la qualité globale du système.

Inconvénients:

• Ce test n’est pas égal à ou un substitut pour compléter les tests fonctionnels.
• même après la réussite du test de fumée, vous pouvez trouver des bugs showstopper.,
• ce type de test est mieux adapté si vous pouvez automatiser autrement 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.

Les tests de fumée devraient certainement être effectués sur chaque construction, car ils soulignent les défaillances majeures et les obstacles à un stade très précoce. Cela s’applique non seulement à de nouvelles fonctionnalités, mais aussi à l’intégration de modules, fixation 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 le test fonctionnel complet de la fonctionnalité ou du système (dans son ensemble). Mais avant cela, l’équipe D’AQ devrait ê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.

Ce test peut être effectué à la fois manuellement et également à l’aide d’outils d’automatisation. Mais la meilleure façon et préférée est d’utiliser des outils d’automatisation pour gagner du temps.,

différence entre la fumée et les tests 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 essais sont bien « différents” et réalisés à différentes étapes d’un cycle d’essai.

Voici une représentation schématique de leurs différences:

test de fumée

• Ce test est né de la pratique de test de matériel consistant à allumer un nouveau matériel pour la première fois et à le considérer comme un succès s’il Dans l’industrie du logiciel, ce test est une approche superficielle et large par laquelle tous les domaines de l’application sans entrer dans trop profond, est testé.,
• Un test de fumée est scripté, soit à l’aide d’une série de tests ou un test automatique
• Un test de Fumée est conçu pour toucher chaque partie de l’application d’une manière superficielle. Il est peu profond et large.
• Ce test est effectué pour s’assurer que les fonctions les plus cruciales d’un programme fonctionnent, mais ne se soucient pas des détails les plus fins. (Comme la vérification de construction).
• Ce test est un bilan de santé normal pour la construction d’une application avant de la tester en profondeur.,

test de santé mentale

• Un test de santé mentale est un test de régression étroite qui se concentre sur un ou quelques domaines de fonctionnalité. Les tests de santé mentale sont généralement étroits et profonds.
• Ce test est généralement non scénarisé.
• Ce test est utilisé pour déterminer qu’une petite partie 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 de tests de régression.,
• Il s’agit de vérifier si les exigences sont satisfaites ou non, en vérifiant d’abord toute la largeur des fonctionnalités.