Inleiding

de levensduur van een QA-Tester zal als onvolledig worden beschouwd als de termen “rooktest”, “Saniteitstest” en “regressietest” er niet in worden geïnfundeerd. Hoewel dit zijn een aantal regelmatig gebruikte termen, er zijn een aantal veel voorkomende misvattingen rond hen ook.

voordat we beginnen met de details van rook, gezond verstand en regressie testen en wat ze eigenlijk betekenen, laten we gaan door enkele veel voorkomende misvattingen en mythen om hen heen:

1. Rooktesten en gezondheidstesten zijn hetzelfde en kunnen door elkaar worden gebruikt : Dit is niet waar en mag nooit worden gedaan, waarom? dat zullen we in dit artikel bespreken.
2. Sanity Testing is gelijkwaardig aan acceptance testing: Acceptance Testing wordt gedaan om ervoor te zorgen dat de build voldoet aan alle eisen die de client heeft gespecificeerd voor de release, terwijl Sanity Testing wordt gedaan om ervoor te zorgen dat het product gezond is, rationeel voor meer gedetailleerde testen. Deze zijn en mogen niet onderling verwisseld worden.
3. Als Ik rooktest doe, kan ik het testen van gezond verstand overslaan: Rook testen is een zeer hoog niveau testen, zoals in, deze tests worden gedaan om ervoor te zorgen dat deze build is geschikt voor elk ander type van testen te beginnen. Bijvoorbeeld, dit kan gewoon een test zijn om ervoor te zorgen dat de build installeert en dan kan de Sanity Testing beginnen. Hoewel soms, de rook test cases worden uitgevoerd samen met Sanity Test cases, deze moeten niet worden verward om de ene en hetzelfde ding.
4. regressietest houdt geen verband met rook-of Saniteitstesten: in theorie is Saniteitstesten een subset van regressiestesten. Sommige regressietestgevallen met hoge prioriteit vormen gewoonlijk een saniteitstest.
5. als ik van plan ben om de volledige regressietestreeks uit te voeren – Ik hoef geen rooktest of saniteitstest uit te voeren: hoewel dit in sommige gevallen waar kan zijn omdat Saniteitstests toch een subset van regressietests zijn, is het toch raadzaam om eerst de saniteitstestgevallen uit te voeren en ze vervolgens te volgen met de rest van de regressietestgevallen.

In dit artikel zullen we proberen bovenstaande verwarring voor eens en voor altijd op te lossen.

voor het geval u meer wilt lezen over handmatig testen, raadpleeg dan de link hier.

Opmerking: Omdat we de term ‘Software Build’ vaak zullen gebruiken in het artikel, laten we het hier definiëren. ‘Software Build’ is een proces van het omzetten van broncode, in een gebruikerstoepassing, na meerdere revisies en code wijzigingen en Software Build omvat meerdere processen zoals, “Version Control, Code Quality & Compilation” en software build is ook het resultaat van dit bouwproces. In dit artikel wordt naar een build verwezen als een testbare versie van de software.

Smoke Testing

Smoke testing is een aanpak die gewoonlijk wordt uitgevoerd tijdens de eerste ontwikkelingsstadia van de Software Development Life Cycle(SDLC) om ervoor te zorgen dat de kernfunctionaliteiten van een programma prima werken zonder problemen. Het wordt uitgevoerd voordat gedetailleerde functionele tests worden gedaan op de software.

de belangrijkste bedoeling van rook testen is niet om diepe testen uit te voeren, maar om te controleren of de kern of de belangrijkste functionaliteiten van het programma of de software goed werken. Smoke testing is bedoeld om een slecht kapotte build in de eerste fase af te wijzen, zodat het testteam geen tijd verspilt met het installeren van & het testen van de software applicatie.

rooktest wordt ook wel Build verificatietest genoemd.

laten we een eenvoudig voorbeeld bekijken waar u een e-mailtoepassing krijgt om te testen. De belangrijke functies zouden zijn inloggen op de e-mailtoepassing, het samenstellen van een e-mail en het verzenden ervan, toch? En, in het geval dat de e-mail niet wordt verzonden, heeft het zin om andere functionaliteiten te testen, zoals Concepten, verwijderde berichten, archieven, enz? Dit betekent dat u de build moet laten vallen zonder verdere validatie. Dit heet Smoke testing.

het belangrijkste doel van de rooktest is het testen van de kritieke gebieden en niet van de volledige toepassing.

wanneer een rooktest moet worden uitgevoerd

• wanneer ontwikkelaars het QA-team een nieuwe build geven. Een frisse build betekent hier wanneer de build nieuwe wijzigingen heeft aangebracht door de ontwikkelaars.
• wanneer een nieuwe module aan de bestaande functionaliteit wordt toegevoegd.

automatisering & rooktest:

meestal is dit het type test dat wordt uitgevoerd voordat de werkelijke automatiseringstests kunnen worden uitgevoerd. Voor organisaties die continue tests hebben ingebouwd, staat rooktesten gelijk aan het succesvol installeren van de build voor het uitvoeren van testcases of het uitvoeren van de eerste testcase. Dit is dus geen type test dat opzettelijk geautomatiseerd is, maar als testautomatisering wordt ingevoerd, kan de testautomatisering alleen succesvol worden uitgevoerd als de software de rooktest heeft doorstaan. Of anders kan de eerste testcase die wordt uitgevoerd mislukken.

Sanity Testing

Sanity testing is een soort test die wordt uitgevoerd om te controleren of een softwareproduct correct werkt wanneer een nieuwe module of functionaliteit wordt geïmplementeerd in een bestaand product. Sanity testing is een software testtechniek die een snelle evaluatie van de kwaliteit van de software release doet om te bepalen of het in aanmerking komt voor verdere rondes van het testen of niet.

Sanity testing wordt meestal uitgevoerd na het ontvangen van een vrij stabiele software build of soms wanneer een software build kleine veranderingen in de code of functionaliteit kan hebben ondergaan. Het besluit of end-to-end testen van een softwareproduct verder moet worden uitgevoerd of niet.

Sanity testing is ook een Surface Level Testing die helpt bij het bepalen of de softwarebouw goed genoeg is om het door te geven naar het volgende testniveau.

waarom een Saniteitstest uitvoeren

• om de conformiteit van nieuw toegevoegde functionaliteiten en functies in bestaande code te verifiëren en te valideren.
• om ervoor te zorgen dat de ingevoerde wijzigingen geen invloed hebben op andere bestaande functionaliteiten van het product.
• om te besluiten dat verdere tests al dan niet kunnen worden uitgevoerd.

wanneer het uitvoeren van Sanity Testing

• Build wordt ontvangen na veel regressies of als er een kleine verandering in de code.
• de build wordt ontvangen na bug fixing.
• vlak voor de implementatie op productie.

Automation& Sanity Testing:

In overweging nemend, wordt Sanity Testing beschouwd als een subset van regressietests, dit zijn de testgevallen die geautomatiseerd kunnen worden. Een aanbevolen aanpak is om deze testcases uit te voeren voordat u de complete regressie test suite uitvoert. Het voordeel is dat als er fouten in de sanity test cases, dan fouten kunnen worden gemeld eerder vroeger dan later.

regressie testen

regressie testen is de verificatie van” bugfixes of veranderingen in de eis ” en ervoor te zorgen dat ze geen invloed hebben op andere functionaliteiten van de toepassing. Regressie testen is effectief op automatisering en meestal uitgevoerd na een aantal wijzigingen zijn aangebracht in de software te bouwen na vereiste wijzigingen of bug fixes.

zodra de Saniteitstest van de gewijzigde functionaliteit is voltooid, moeten alle getroffen functies van de toepassing volledig worden getest. Dit heet regressie testen.

wanneer bugfixes worden gedaan in de bestaande software, moeten sommige testscenario ‘ s worden uitgevoerd om de Bugfixes te verifiëren. Naast deze, het QA team moet ook de getroffen gebieden te controleren, op basis van de code veranderingen. In regressie testen, zullen al die testscenario ‘ s moeten worden uitgevoerd, om te zorgen voor gerelateerde functionaliteiten.

wanneer regressietesten uitgevoerd moeten worden

• na wijziging van de Code volgens de vereiste wijzigingen
• nadat enkele nieuwe functies aan de toepassing zijn toegevoegd
• nadat enkele bugfixes zijn opgenomen in de build

automatisering & regressietesten:

Regressietestgevallen zijn eigenlijk de ideale testgevallen voor automaat. Meestal, wanneer een organisatie begint met automatisering, dit zijn de testcases die eerst worden geautomatiseerd. Als regressietests een activiteit is die veel tijd in beslag neemt voor uw testers en dezelfde testgevallen meerdere keren worden herhaald, is het tijd dat u ook aan automatisering begint te denken.

Als u op zoek bent naar een tool die u kan helpen aan de slag te gaan op uw automatiseringsreis, dan moet u er ook voor zorgen dat u het juiste tool kiest. Een tool die ook kan bieden u ROI op de inspanningen geïnvesteerd. Wij hebben de gids die u daar kan helpen:

10 Points to Help You Choose the Right Test Automation Tool

Differences Between Smoke vs Sanity vs Regression Testing

belangrijke punten

• smoke and sanity testing helpt het QA team tijd te besparen door snel te testen om er zeker van te zijn dat een toepassing goed werkt of niet. Ook zorgt het ervoor dat het product in aanmerking komt voor verdere tests. Terwijl regressie testen helpt bij het verbeteren van het vertrouwen over de softwarekwaliteit na een bepaalde verandering. Vooral, dat de code wijzigingen zijn niet van invloed op verwante gebieden.

• De rooktest wordt uitgevoerd door zowel het dev-team als het QA-team en kan worden beschouwd als een subset van strenge tests. Terwijl beide Sanity & regressietests alleen door het QA-team worden uitgevoerd. Ook, gezondheid testen kan worden beschouwd als een subset van acceptatie testen.

• De rooktest wordt uitgevoerd in de eerste fase van SDLC, om de Kernfuncties van een toepassing te controleren. Terwijl Sanity & regressietests worden uitgevoerd in de laatste fase van SDLC, om de belangrijkste functionaliteiten van een toepassing te controleren.

• volgens de vereiste van het testen & time availability, kan het QA team Sanity, Smoke & regressietests moeten uitvoeren op hun software build. In dergelijke gevallen worden eerst Rooktests uitgevoerd, gevolgd door Saniteitstests & vervolgens wordt op basis van de beschikbaarheid van de tijd een regressietest gepland.

in de praktijk moeten alle QA-teams rook -, Saniteits-en regressietests uitvoeren. Al deze testtypen hebben een vooraf gedefinieerd aantal testcases dat meerdere keren wordt uitgevoerd. Deze repetitieve uitvoering maakt ze ook een ideale kandidaat voor testautomatisering. Bij het zoeken naar automatisering, wordt u aanbevolen om een tool die u ROI biedt op automatisering vanaf de eerste stadia te gebruiken. Testsigma is zo ‘ n hulpmiddel.