Good Mood

verken de verschillen tussen Smoke Testing en Sanity Testing in detail met voorbeelden:

In deze tutorial zullen we leren wat Sanity Testing en Smoke Testing is in Software Testing. We leren ook de belangrijkste verschillen tussen gezond verstand en rook testen met eenvoudige voorbeelden.

meestal raken we verward tussen de Betekenis van het testen van gezond verstand en het testen van rook. Ten eerste zijn deze twee testen veel “verschillend” en worden ze uitgevoerd tijdens verschillende stadia van een testcyclus.,

Sanity Testing

Sanity Testing wordt gedaan wanneer we als QA niet voldoende tijd hebben om alle testcases uit te voeren, of het nu gaat om Functionele Testen, UI, OS of Browser testen.

vandaar dat ik zou definiëren,

“Sanity testen als een test uitvoering die wordt gedaan om elke implementatie en de impact ervan te raken, maar niet grondig of diepgaand, het kan functionele omvatten, UI, versie, enz. testen afhankelijk van de implementatie en de impact ervan.”

vallen we niet allemaal in een situatie waarin we binnen een dag of twee moeten afmelden, maar de build voor testen is nog steeds niet vrijgegeven?,

Ah ja, ik wed dat u deze situatie ook minstens één keer in uw Software Test ervaring moet hebben meegemaakt. Nou, ik geconfronteerd met het veel omdat mijn project(s) waren meestal behendig en soms werden we gevraagd om het dezelfde dag te leveren. Oeps, Hoe kon ik de build binnen een stuk van uren testen en vrijgeven?

Ik werd soms gek omdat zelfs als het een kleine functionaliteit was, de implicatie enorm kon zijn. En als kers op de taart weigeren klanten soms gewoon om extra tijd te geven., Hoe kon ik het hele testen in een paar uur voltooien, elke functionaliteit verifiëren, Bugs en het vrijgeven?

het antwoord op al deze problemen was zeer eenvoudig, dat wil zeggen niets anders dan het gebruik van Sanity Testing strategy.

wanneer we dit testen voor een module of functionaliteit of een compleet systeem, worden de testcases voor uitvoering zodanig geselecteerd dat ze alle belangrijke stukjes en beetjes van hetzelfde raken, d.w.z. brede maar ondiepe testen.

soms wordt het testen zelfs willekeurig uitgevoerd zonder testcases., Maar vergeet niet, Sanity test moet alleen worden gedaan wanneer u een tekort aan tijd, gebruik dit nooit voor uw reguliere releases. Theoretisch is dit testen een deelverzameling van regressietests.

mijn ervaring

uit mijn 8+ jaar carrière in Software Testing, werkte ik 3 jaar in Agile methodologie en dat was de tijd dat ik meestal een sanity test gebruikte.

alle grote releases werden op een systematische manier gepland en uitgevoerd, maar soms werd gevraagd om kleine releases zo snel mogelijk te leveren., We kregen niet veel tijd om de testcases te documenteren, uit te voeren, de bugdocumentatie te doen, de regressie te doen en het hele proces te volgen.

vandaar dat het volgende Enkele van de belangrijkste aanwijzingen zijn die ik gebruikte om te volgen onder dergelijke situaties:

#1) Ga met de manager en het dev-team zitten wanneer ze de implementatie bespreken omdat ze snel moeten werken en daarom kunnen we niet verwachten dat ze ons afzonderlijk uitleggen.

Dit zou u ook helpen om een idee te krijgen over wat ze gaan implementeren, welk gebied het zal beïnvloeden etc.,, dit is een zeer belangrijk ding om te doen, omdat we soms gewoon niet beseffen de implicaties en of een bestaande functionaliteit zal worden belemmerd (in het slechtste geval).

#2) omdat u weinig tijd hebt, kunt u tegen de tijd dat het ontwikkelteam aan de implementatie werkt, de testcases ruwweg noteren in tools zoals Evernote, enz. Maar zorg ervoor dat je ze ergens schrijft, zodat je ze later kunt toevoegen aan de test case tool.,

#3) Houd uw testbed klaar volgens de implementatie en als u denkt dat er een rode vlag zoals een specifieke data creatie als een testbed tijd zal duren (en het is een belangrijke test voor de release), dan zet die vlaggen onmiddellijk en informeer uw manager of PO over de wegversperring.

alleen omdat de client zo snel mogelijk wil, betekent dit niet dat een QA zal vrijgeven, zelfs als het half getest is.,

#4) Maak een overeenkomst met uw team en manager dat u vanwege tijdgebrek alleen de bugs zult communiceren met het ontwikkelteam en het formele proces van toevoegen, waarbij het markeren van de bugs voor verschillende fasen in het bug tracking tool later zal worden gedaan om tijd te besparen.

#5) als het ontwikkelingsteam aan het eind test, probeer dan met hen te koppelen (dev-QA pairing genoemd) en doe een basisronde op hun setup zelf, dit zal helpen om het heen en weer van de build te voorkomen als de basisimplementatie faalt.,

#6) Nu u de build hebt, test u eerst de bedrijfsregels en alle use cases. U kunt tests zoals een validatie van een veld, navigatie, etc voor later houden.

#7) welke bugs je ook vindt, noteer ze allemaal en probeer ze samen aan de ontwikkelaars te rapporteren in plaats van individueel te rapporteren, omdat het voor hen gemakkelijk zal zijn om aan een stel te werken.

#8) Als u een vereiste hebt voor de Algemene prestatietest of Stress-of belastingtest, zorg er dan voor dat u een goed automatiseringskader voor hetzelfde hebt., Omdat het bijna onmogelijk is om deze handmatig te testen met een geestelijke Gezondheidstest.

#9) Dit is het belangrijkste deel, en inderdaad de laatste stap van je sanity test strategie – “wanneer je de release e-mail of het document opstelt, vermeld dan alle testcases die je hebt uitgevoerd, de bugs die gevonden zijn met een status marker en als er iets niet getest is vermeld het met de redenen” probeer een helder verhaal te schrijven over je testen die iedereen zal vertellen over wat getest, geverifieerd en wat niet is geweest.

Ik volgde dit religieus toen ik deze test gebruikte.,

laat me mijn eigen ervaring delen:

#1) We werkten aan een website en die werd gebruikt om advertenties te tonen op basis van de trefwoorden. De adverteerders gebruikten om het bod te plaatsen voor bepaalde zoekwoorden die een scherm had ontworpen voor hetzelfde. De standaard bod waarde gebruikt om te worden weergegeven als $ 0.25, die de bieder zelfs kon veranderen.

Er was nog een plaats waar dit standaard bod werd gebruikt om te verschijnen en het kon ook worden gewijzigd in een andere waarde. De klant kwam met een verzoek om de standaardwaarde te wijzigen van $0.25 naar $0.5, maar hij noemde alleen het voor de hand liggende scherm.,

tijdens onze brainstorm discussie vergaten we (?) over dit Andere scherm omdat het niet veel voor dat doel werd gebruikt. Maar tijdens het testen toen ik liep het basisgeval van het bod is $ 0.5 en gecontroleerd end to end, ik vond dat de cronjob voor hetzelfde was mislukt omdat op een plaats was het vinden van $0.25.

Ik heb dit gemeld aan mijn team en we hebben de wijziging doorgevoerd en het op dezelfde dag zelf succesvol afgeleverd.

#2) onder hetzelfde project (hierboven vermeld), werd ons gevraagd om een klein tekstveld toe te voegen voor opmerkingen/opmerkingen voor het bieden., Het was een zeer eenvoudige implementatie en we hebben ons ertoe verbonden om het op dezelfde dag te leveren.

vandaar, zoals hierboven vermeld, Ik testte alle zakelijke regels en use cases eromheen en toen ik wat validatietesten deed, vond ik dat toen ik een combinatie van speciale tekens invoerde zoals </>, de pagina crashte.

we dachten erover na en kwamen erachter dat de daadwerkelijke bieders in geen geval dergelijke combinaties zullen gebruiken. Daarom hebben we het uitgebracht met een goed opgestelde notitie over het probleem., De client accepteerde dat als een bug, maar stemde met ons in om het later te implementeren omdat het een ernstige bug was, maar niet een eerdere.

#3) onlangs werkte ik aan een mobiele app-project en we hadden een vereiste om de tijd van levering in de app te updaten volgens de tijdzone. Het werd niet alleen getest in de app, maar ook voor de webservice.

terwijl het ontwikkelteam aan de implementatie werkte, heb ik de automatiseringsscripts gemaakt voor het testen van de webservice en de DB-scripts voor het wijzigen van de tijdzone van het afleveringitem., Dit bespaarde mijn inspanningen en we konden binnen korte tijd betere resultaten bereiken.

Sanity Testing Vs Regression Testing

hieronder zijn enkele verschillen tussen de twee:

strategie voor het testen van mobiele apps

u vraagt zich vast af waarom ik het hier specifiek over mobiele apps heb?

de reden is dat OS en browserversie voor web-of desktop-apps niet veel verschillen en vooral de schermformaten standaard zijn. Maar met mobiele apps, de schermgrootte, het mobiele netwerk, de OS-versies, enz.beïnvloeden de stabiliteit, look en in het kort, het succes van uw mobiele app.,

daarom wordt een strategieformulering van cruciaal belang wanneer u deze test uitvoert op een mobiele app, omdat één fout u in grote problemen kan brengen. De tests moeten ook slim en voorzichtig worden uitgevoerd.

Hieronder volgen enkele aanwijzingen om u te helpen deze tests met succes uit te voeren op een ‘mobiele app’:

#1) analyseer eerst de impact van de OS-versie op de implementatie met uw team.

probeer antwoorden te vinden op vragen als, zal het gedrag verschillen tussen versies? Zal de implementatie werken op de laagst ondersteunde versie of niet?, Zullen er prestatieproblemen zijn bij de implementatie van versies? Is er een specifiek kenmerk van het besturingssysteem dat het gedrag van de implementatie kan beïnvloeden? etc.

#2) op de bovenstaande opmerking, analyseren voor de telefoon modellen ook dwz zijn er functies van de telefoon die van invloed zijn op de implementatie? Is de implementatie van gedrag-veranderen met GPS? Verandert het implementatiegedrag met de camera van de telefoon? etc. Als u merkt dat er geen impact, vermijd het testen op verschillende telefoonmodellen.,

#3) Tenzij er UI-wijzigingen zijn voor de implementatie adviseer ik om UI-testen op de minste prioriteit te houden, kunt u het team informeren (als u wilt) dat UI niet zal worden getest.

#4) om uw tijd te besparen, vermijd het testen op goede netwerken, omdat het duidelijk is dat de implementatie zal werken zoals verwacht op een sterk netwerk. Ik zou aanraden om te beginnen met testen op een 4G of 3G netwerk.

#5) Deze test moet in minder tijd worden uitgevoerd, maar zorg ervoor dat u minstens één veldtest doet, tenzij het slechts een UI-wijziging is.,

#6) als je moet testen op een matrix van verschillende besturingssystemen en hun versie, stel ik voor dat je het op een slimme manier doet. Kies bijvoorbeeld de laagste, medium en de nieuwste OS-versie paren voor het testen. U kunt in het release document vermelden dat niet elke combinatie wordt getest.

#7) op een vergelijkbare regel, voor UI implementatie sanity test, gebruik kleine, middelgrote en grote schermformaten om tijd te besparen. U kunt ook gebruik maken van een simulator en emulator.,

voorzorgsmaatregelen

het testen van de gezondheid wordt uitgevoerd wanneer u weinig tijd hebt en daarom is het niet mogelijk om elk testgeval uit te voeren en het belangrijkste is dat u niet genoeg tijd krijgt om uw testen te plannen. Om de schuld games te vermijden, is het beter om voorzorgsmaatregelen te nemen.

in dergelijke gevallen komen gebrek aan schriftelijke communicatie, testdocumentatie en miss outs vrij vaak voor.,

om ervoor te zorgen dat u hier niet ten prooi aan valt, moet u ervoor zorgen dat:

• nooit een build voor het testen accepteert totdat u geen schriftelijke eis krijgt die gedeeld wordt door de client. Het gebeurt dat klanten communiceren veranderingen of nieuwe implementaties mondeling of in de chat of een eenvoudige 1 liner in een e-mail en verwachten dat we dat behandelen als een vereiste. Dwing uw klant om een aantal basisfunctionaliteitspunten en acceptatiecriteria te bieden.
• Maak altijd ruwe notities van je testcases en bugs als je niet genoeg tijd hebt om ze netjes te schrijven. Laat deze nooit zonder papieren achter., Als er enige tijd is, deel het met je lead of team, zodat als er iets ontbreekt, ze het gemakkelijk kunnen aanwijzen.
• Als u en uw team weinig tijd hebben, moet u er dan voor zorgen dat de bugs in de juiste staat worden gemarkeerd in een e-mail? U kunt de volledige lijst met bugs naar het team e-mailen en de devs ze op de juiste manier markeren. Houd altijd de bal in het veld van de ander.
• als je Automation Framework klaar hebt, gebruik dat dan en vermijd handmatig testen, op die manier kun je in minder tijd meer behandelen.,
• vermijd het scenario van “release in 1 hour” tenzij u 100% zeker bent dat u in staat bent om te leveren.
• last but not the least, zoals hierboven vermeld, een gedetailleerde release e-mail opstellen waarin staat wat wordt getest, wat wordt weggelaten, redenen, risico ‘s, welke bugs worden opgelost, wat’ Latered ‘ zijn, enz.

Als QA moet u beoordelen wat het belangrijkste onderdeel van de implementatie is dat moet worden getest en wat de onderdelen zijn die kunnen worden weggelaten of basic-getest.,

zelfs in een korte tijd, plan een strategie over hoe je wilt doen en je zult in staat zijn om het beste te bereiken in het gegeven tijdsbestek.

Smoke Testing

Smoke Testing is geen uitputtende test, maar het is een groep tests die worden uitgevoerd om te controleren of de basisfuncties van die specifieke build goed werken zoals verwacht of niet. Dit is en moet altijd de eerste test worden gedaan op een ‘nieuwe’ build.,

wanneer het ontwikkelingsteam een build aan de QA geeft voor het testen, is het duidelijk niet mogelijk om de volledige build te testen en onmiddellijk te controleren of een van de implementaties bugs heeft of dat een van de werkende functionaliteit kapot is.

In het licht hiervan, hoe zal een QA ervoor zorgen dat de basisfunctionaliteiten goed werken?

het antwoord hierop is het uitvoeren van een rooktest.

zodra de tests als rooktest (in de testsuite) zijn gemarkeerd, wordt de build pas door de QA geaccepteerd voor diepgaande tests en/of regressie., Als een van de rooktests mislukt, wordt de build afgewezen en moet het ontwikkelingsteam het probleem oplossen en een nieuwe build uitbrengen om te testen.

theoretisch wordt de rooktest gedefinieerd als oppervlaktetests om te certificeren dat de bouw die door het ontwikkelingsteam aan het QA-team wordt geleverd, klaar is voor verdere tests. Deze tests worden ook uitgevoerd door het ontwikkelingsteam voordat de build aan het QA-team wordt vrijgegeven.

deze test wordt normaal gebruikt bij integratietests, systeemtests en Acceptatieniveaus. Behandel dit nooit als een vervanging voor de werkelijke end-to-end volledige testen., Het bestaat uit zowel positieve als negatieve tests, afhankelijk van de build implementatie.

voorbeelden van Rooktests

deze tests worden gewoonlijk gebruikt voor integratie -, acceptatie-en systeemtests.

In mijn carrière als QA, accepteerde ik altijd een build pas nadat ik een rooktest had uitgevoerd. Dus, laten we begrijpen wat een rooktest is vanuit het perspectief van al deze drie testen, met enkele voorbeelden.

#1) acceptatietest

wanneer een build aan de QA wordt vrijgegeven, moet een rooktest in de vorm van een acceptatietest worden uitgevoerd.,

in deze test is de eerste en belangrijkste rooktest het verifiëren van de verwachte basisfunctionaliteit van de implementatie. Als dit, je moet controleren of alle implementaties voor die specifieke build.

laten we de volgende voorbeelden als implementaties in een build nemen om de rooktests voor die te begrijpen:

• implementeerde de aanmeldfunctionaliteit om de geregistreerde stuurprogramma ‘ s toe te staan succesvol in te loggen.
• implementeerde de dashboard functionaliteit om de routes te tonen die een driver vandaag moet uitvoeren.,
• implementeerde de functionaliteit om een passend bericht te tonen als er voor een bepaalde dag geen routes bestaan.

in de bovenstaande build, op het acceptatieniveau, zal de rooktest betekenen om te controleren of de drie basisimplementaties goed werken. Als een van deze drie gebroken is, dan moet de QA de build afwijzen.

#2) integratietest

Deze test wordt meestal uitgevoerd wanneer de afzonderlijke modules worden geïmplementeerd en getest., In het Integration Testing level wordt deze test uitgevoerd om ervoor te zorgen dat alle basisintegratie en end-to-end functionaliteiten prima werken zoals verwacht.

Het kan de integratie van twee of alle modules samen zijn, zodat de complexiteit van de rooktest varieert afhankelijk van het niveau van integratie.

laten we de volgende voorbeelden van integratie-implementatie voor deze test bekijken:

• implementeerde de integratie van route-en stopmodules.
• heeft de integratie van de update van de aankomststatus geïmplementeerd en geeft hetzelfde weer op het stops-scherm.,
• implementeerde de integratie van complete pick-up tot de delivery functionaliteit modules.

in deze build zal de rooktest niet alleen deze drie basisimplementaties verifiëren, maar voor de derde implementatie zullen ook enkele gevallen de volledige integratie verifiëren. Het helpt veel om uit te vinden van de problemen die krijgen geïntroduceerd in de integratie en degenen die onopgemerkt door het ontwikkelingsteam ging.

#3) systeemtest

zoals de naam al aangeeft, omvat de rooktest voor systeemniveau tests voor de belangrijkste en meest gebruikte workflows van het systeem., Dit wordt pas gedaan nadat het volledige systeem klaar is & getest, en deze tests voor systeemniveau kunnen ook rooktests worden genoemd vóór regressietests.

voordat met de regressie van het complete systeem wordt begonnen, worden de basiskenmerken van het einde tot het einde getest als onderdeel van de rooktest. De rook Test suite voor het complete systeem bestaat uit de end-to-end testcases die de eindgebruikers zeer vaak gaan gebruiken.

Dit wordt meestal gedaan met behulp van automatiseringstools.,

belang in SCRUMMETHODOLOGIE

tegenwoordig volgen de projecten nauwelijks de Watervalmethodologie bij de uitvoering van projecten, meestal volgen alle projecten alleen Agile en SCRUM. In vergelijking met de traditionele waterval methode, rook testen heeft hoge waarden in SCRUM en Agile.

Ik heb 4 jaar in SCRUM gewerkt. En zoals we weten in SCRUM zijn de sprints van kortere duur en daarom is het van groot belang om deze test te doen, zodat de mislukte builds direct kunnen worden gemeld aan het ontwikkelingsteam en ook kunnen worden gerepareerd.,

Hieronder volgen enkele gegevens over het belang van deze tests in SCRUM:

• van de twee weken durende sprint wordt de rust toegewezen aan de QA, maar soms worden de bouwwerken naar de QA vertraagd.
• in sprints is het het beste voor het team dat de problemen in een vroeg stadium worden gemeld.
• elk verhaal heeft een reeks acceptatiecriteria, dus het testen van de eerste 2-3 acceptatiecriteria is gelijk aan het testen van rook van die functionaliteit. Klanten wijzen de levering af als een enkel criterium niet werkt.,
• stel je eens voor wat er zal gebeuren als het 2 dagen is dat het ontwikkelingsteam je de build heeft geleverd en er nog maar 3 dagen over zijn voor de demo en je een basisfunctionaliteitfout tegenkomt.
• gemiddeld heeft een sprint verhalen variërend van 5-10, dus wanneer de build wordt gegeven is het belangrijk om ervoor te zorgen dat elk verhaal wordt geà mplementeerd zoals verwacht voordat de build in het testen wordt geaccepteerd.
• wanneer het volledige systeem moet worden getest en gecorrigeerd, wordt een sprint aan de activiteit gewijd., Twee weken misschien iets minder om het hele systeem te testen, daarom is het erg belangrijk om de meest basale functionaliteiten te controleren voordat u begint met de regressie.

rooktest Vs Build Acceptance Testing

rooktest houdt rechtstreeks verband met Build Acceptance Testing (BBT).

in BAT doen we dezelfde testen – om te controleren of de build niet is mislukt en of het systeem goed werkt of niet. Soms gebeurt het dat wanneer een build wordt gemaakt, sommige problemen worden geïntroduceerd en wanneer het wordt geleverd, de build werkt niet voor de QA.,

Ik zou zeggen dat BAT een onderdeel is van een rookcontrole, want als het systeem faalt, hoe kun je als QA de build accepteren voor het testen? Niet alleen de functionaliteiten, het systeem zelf moet werken voordat de QA ‘ s verder gaan met diepgaande testen.

Rooktestcyclus

in het volgende stroomschema wordt de Rooktestcyclus toegelicht.

zodra een build wordt ingezet voor een QA, volgt de basiscyclus dat als de rooktest slaagt, de build door het QA-team wordt geaccepteerd voor verdere tests, maar als het mislukt, de build wordt geweigerd totdat de gerapporteerde problemen zijn opgelost.,

testcyclus

wie moet de rooktest uitvoeren?

niet het hele team is betrokken bij dit type tests om verspilling van tijd van alle QA ‘ s te voorkomen.

Rooktests worden idealiter uitgevoerd door de QA-leider die op basis van het resultaat beslist of de build aan het team moet worden doorgegeven voor verdere tests of moet worden afgewezen. Of bij afwezigheid van de lood, kunnen de QA ‘ s zelf ook deze test uitvoeren.

soms, wanneer het project een grootschalig project is, kan een groep van QA deze test ook uitvoeren om te controleren of er showstoppers zijn., Maar dit is niet het geval in het geval van SCRUM, want SCRUM is een platte structuur zonder Leads of Managers en elke tester heeft zijn eigen verantwoordelijkheden ten opzichte van hun verhalen.

daarom voeren individuele QA ‘ s deze test uit voor de verhalen die zij bezitten.

waarom zouden we rookproeven automatiseren?

deze test is de eerste test die wordt uitgevoerd op een build die door het ontwikkelteam(s) is uitgebracht. Op basis van de resultaten van deze tests wordt verder getest (of de build wordt afgewezen).,

de beste manier om deze test uit te voeren is door een automatiseringsprogramma te gebruiken en de rook suite te plannen om te draaien wanneer een nieuwe build wordt gemaakt. Waarom zou ik de rook test suite automatiseren?

laten we eens kijken naar het volgende geval:

stel dat u een week verwijderd bent van uw vrijlating en van de in totaal 500 testcases bestaat uw rooktest suite uit 80-90. Als je al deze 80-90 testcases handmatig gaat uitvoeren, stel je dan voor hoeveel tijd je nodig hebt? Ik denk 4-5 dagen (minimum).,

maar als u automatisering gebruikt en scripts maakt om al deze 80-90 testcases uit te voeren, worden deze idealiter in 2-3 uur uitgevoerd en hebt u de resultaten direct bij u. Heeft het niet bespaart uw kostbare tijd en geven u de resultaten over de build-in veel minder tijd?

5 jaar geleden, was ik het testen van een financiële projectie app, die input nam over uw salaris, besparingen, enz., en geprojecteerd uw belastingen, besparingen, winst, afhankelijk van de financiële regels. Samen met dit, we hadden maatwerk voor landen die afhankelijk zijn van het land en de fiscale regels gebruikt om te veranderen (in de code).,

voor dit project had ik 800 testcases en 250 waren rook testcases. Met het gebruik van Selenium, konden we gemakkelijk automatiseren en krijgen de resultaten van die 250 testgevallen in 3-4 uur. Het bespaarde niet alleen onze tijd, maar toonde ons zo snel mogelijk over de showstoppers.

neem daarom, tenzij het onmogelijk is om te automatiseren, de hulp van automatisering voor deze test.

voor-en nadelen

laten we eerst eens kijken naar de voordelen omdat het veel te bieden heeft in vergelijking met de weinige nadelen.

voordelen:

• Eenvoudig uit te voeren.
• vermindert het risico.,
• defecten worden in een zeer vroeg stadium vastgesteld.
• bespaart inspanningen, tijd en geld.
• loopt snel als het geautomatiseerd is.
• minste integratierisico ‘ s en-problemen.
• verbetert de algehele kwaliteit van het systeem.

nadelen:

• deze test is niet gelijk aan of vervangt volledige functionele tests.
• zelfs nadat de rooktest is geslaagd, kunt u showstopper bugs vinden.,
• dit type testen is het beste geschikt als u anders veel tijd besteed aan het handmatig uitvoeren van de testcases, vooral in grootschalige projecten met ongeveer 700-800 testcases.

Rooktesten moeten zeker op elke build worden uitgevoerd, aangezien het in een zeer vroeg stadium de belangrijkste storingen en showstoppers aan het licht brengt. Dit geldt niet alleen voor nieuwe functionaliteiten, maar ook voor de integratie van modules, het oplossen van problemen en improvisatie. Het is een zeer eenvoudig proces om uit te voeren en het juiste resultaat te krijgen.,

deze tests kunnen worden behandeld als het startpunt voor volledige functionele tests van functionaliteit of systeem (als geheel). Maar daarvoor moet het QA-team heel duidelijk zijn over welke tests als rooktest moeten worden gedaan. Dit testen kan de inspanningen minimaliseren, tijd besparen en de kwaliteit van het systeem verbeteren. Het heeft een zeer belangrijke plaats in sprints als de tijd in sprints is minder.

deze tests kunnen zowel handmatig als met behulp van automatiseringstools worden uitgevoerd. Maar de beste en geprefereerde manier is om automatiseringstools te gebruiken om tijd te besparen.,

verschil tussen het testen van rook en het testen van de gezondheid

meestal raken we verward tussen de Betekenis van het testen van de gezondheid en het testen van rook. Ten eerste zijn deze twee testen veel “verschillend” en uitgevoerd tijdens verschillende stadia van een testcyclus.

Hieronder volgt een schematische weergave van hun verschillen:

SMOKE TESTING

• deze testen zijn ontstaan in de hardwaretestpraktijk waarbij een nieuw stuk hardware voor de eerste keer wordt ingeschakeld en het als een succes wordt beschouwd als het niet in brand en rook vliegt. In de software-industrie, dit testen is een oppervlakkige en brede aanpak waarbij alle gebieden van de toepassing zonder te diep, wordt getest.,
• een rooktest wordt scripted, hetzij met behulp van een geschreven reeks tests of een geautomatiseerde test
• een rooktest is ontworpen om elk deel van de toepassing op een vluchtige manier te raken. Het is ondiep en breed.
• deze test wordt uitgevoerd om er zeker van te zijn of de meest cruciale functies van een programma werken, maar niet met de fijnere details. (Zoals build verificatie).
• deze test is een normale gezondheidscontrole bij het bouwen van een applicatie alvorens deze grondig te testen.,

SANITEITSTEST

• een saniteitstest is een smalle regressietest die zich richt op een of enkele functionaliteitsgebieden. Het testen van de geestelijke gezondheid is meestal smal en diep.
• Deze test is meestal niet gechript.
• deze test wordt gebruikt om te bepalen dat een klein gedeelte van de toepassing na een kleine wijziging nog steeds werkt.
• deze test is een vluchtige test, die wordt uitgevoerd wanneer een vluchtige test voldoende is om aan te tonen dat de toepassing volgens de specificaties functioneert. Dit niveau van testen is een subset van regressietests.,
• Dit is om te controleren of aan de vereisten wordt voldaan of niet, waarbij alle functies eerst breed-worden gecontroleerd.