Sanitytesten versus rooktesten: belangrijkste verschillen, voorbeelden en wanneer je ze moet gebruiken.

Rooktest versus sanitytest: vergelijkingstabel

Aspect	Rook testen	Sanity testen
Voornaamste doel	Controleer de stabiliteit van de build.	Controleer of de wijzigingen naar behoren werken.
strekking	Breed (hele aanvraag)	Smal (specifieke modules)
Diepte	Oppervlakkige tests	Grondige tests (gericht)
Verricht door	Ontwikkelaars of testers	Alleen voor testers
Bouwstatus	Initiële/instabiele builds	Relatief stabiele builds
Documentatie	Uitgeschreven en gedocumenteerd	Meestal zonder script
Testsubset	Acceptatietesten	Regressie Testing
Automatisering	Sterk aanbevolen	Kan handmatig of geautomatiseerd zijn.

Wat is een softwarebuild?

Als je een eenvoudig computerprogramma ontwikkelt dat slechts uit één broncodebestand bestaat, hoef je dit ene bestand alleen maar te compileren en te linken om een ​​uitvoerbaar bestand te produceren. Dit proces is eenvoudig. Meestal is dit echter niet het geval. Een typisch softwareproject bestaat uit honderden of zelfs duizenden broncodebestanden. Het maken van een uitvoerbaar programma uit deze bronbestanden is een gecompliceerde en tijdrovende taak. Je moet software gebruiken om een ​​uitvoerbaar programma te maken, en dit proces wordt 'software bouwen' genoemd.

Wat is rooktesten?

Smoketesten is een softwaretesttechniek die na de build van de software wordt uitgevoerd om te controleren of de kritieke functionaliteiten van de software naar behoren werken. Het wordt uitgevoerd voordat gedetailleerde functionele of regressietests worden uitgevoerd. Het primaire doel van smoketesten is om een ​​softwareapplicatie met defecten af ​​te wijzen, zodat het QA-team geen tijd verspilt aan het testen van een defecte softwareapplicatie.

Bij een rooktest worden testgevallen gekozen die de meest kritieke functionaliteit of component van het systeem dekken. Het doel is niet om alles tot in de puntjes te testen, maar om ervoor te zorgen dat de belangrijkste functionaliteiten van de softwareapplicatie correct werken. Een typische rooktest zou bijvoorbeeld controleren of de applicatie succesvol opstart, de gebruikersinterface responsief is, enzovoort.

Wat is gezond verstand testen?

Een sanity-test is een vorm van softwaretesten die wordt uitgevoerd nadat een softwarebuild is ontvangen, met kleine wijzigingen in de code of functionaliteit, om te controleren of de bugs zijn verholpen en er geen nieuwe problemen ontstaan ​​door deze wijzigingen. Het doel is om vast te stellen dat de voorgestelde functionaliteit in grote lijnen werkt zoals verwacht. Als een sanity-test mislukt, wordt de build afgewezen om te voorkomen dat er tijd en middelen worden verspild aan diepgaandere tests.

Het doel is niet om de volledige functionaliteit te verifiëren, maar om vast te stellen of de ontwikkelaar enige rationaliteit (gezond verstand) heeft toegepast bij het ontwikkelen van de software. Als uw wetenschappelijke rekenmachine bijvoorbeeld 2 + 2 = 5! als resultaat geeft, heeft het geen zin om geavanceerde functies zoals sin 30 + cos 50 te testen.

Geschiedenis en oorsprong van de termen

De term 'rooktest' is afkomstig uit de hardware- en elektronica-industrie. Wanneer ingenieurs een nieuwe printplaat voor het eerst inschakelden, keken ze of er rook vanaf kwam – een directe indicator van een fundamentele fout. Als er geen rook verscheen, kon de basistest worden voortgezet. Dit concept werd in de jaren 1980 door softwaretesters overgenomen om de initiële verificatie van een build te beschrijven.

"Sanity testing" daarentegen verwijst naar het controleren van de "redelijkheid" of rationaliteit van specifieke wijzigingen. De term benadrukt het verifiëren of de software zich na de aanpassingen op een verstandige, logische manier gedraagt ​​– in feite de vraag: "Heeft dit zin?"

Rooktesten versus sanitytesten versus regressietesten

Inzicht in hoe deze drie testtypen samenwerken is cruciaal voor een effectieve QA-strategie:

• Rook testen Dat komt eerst: het controleert of de build stabiel genoeg is om te testen.
• Sanity testen (indien van toepassing) — het bevestigt dat specifieke wijzigingen of oplossingen correct werken.
• Regressie Testing is de meest uitgebreide methode; deze zorgt ervoor dat nieuwe wijzigingen geen bestaande functionaliteit hebben verstoord.

Zie het als een trechter: rooktesten vormen de brede opening die snel instabiele builds eruit filtert, sanity-testen richten zich op specifieke wijzigingen en regressietesten zorgen voor een grondige dekking van het hele systeem.

Praktisch voorbeeld: een e-commerce-applicatie

Neem bijvoorbeeld een e-commercewebsite die een nieuwe versie krijgt met een bugfix voor het winkelwagensysteem:

Rooktest: De kwaliteitscontrole (QA) controleert eerst of de website laadt, gebruikers kunnen inloggen, producten correct worden weergegeven, de zoekfunctie werkt en het afrekenproces start. Dit duurt ongeveer 15-30 minuten.

Gezond verstandstest: Nadat de rooktest is geslaagd, richten de testers zich specifiek op de functionaliteit van het winkelwagentje: artikelen toevoegen, aantallen bijwerken, artikelen verwijderen en berekeningen controleren. Deze gerichte test duurt ongeveer 30-60 minuten.

Als beide tests slagen, gaat het team verder met volledige regressietests, die afhankelijk van de complexiteit van de applicatie enkele uren of dagen kunnen duren.

Wanneer rooktesten gebruiken en wanneer een sanity test?

Gebruik rooktesten wanneer:

• Een nieuwe softwareversie wordt geïmplementeerd in de testomgeving.
• Je moet snel essentiële functionaliteiten zoals inloggen, navigatie en gegevensstroom kunnen controleren.
• Vaststellen of de build stabiel genoeg is voor verdere gedetailleerde tests.
• Integratie in CI/CD-pipelines voor geautomatiseerde buildverificatie

Gebruik sanity-testen wanneer:

• Kleine codewijzigingen, bugfixes of functieverbeteringen worden doorgevoerd.
• Controleren of specifieke wijzigingen naar behoren werken
• De build is al relatief stabiel gebleken uit eerdere rooktests.

Voordelen en beperkingen

Voordelen

• Snelle identificatie van kritieke problemen: Beide methoden identificeren snel problemen die de tests zouden kunnen stilleggen.
• Efficiënt gebruik van hulpbronnen: Teams verspillen geen tijd aan gedetailleerde tests van fundamenteel gebrekkige builds.
• Vroegtijdige detectie van defecten: Door problemen in een vroeg stadium op te sporen, worden de totale reparatiekosten verlaagd.
• Snellere releasecycli: Een efficiënte gatekeeping maakt snellere iteratie en implementatie mogelijk.

Beperkingen

• Beperkte dekking: Geen van beide testtypen biedt een volledig overzicht van de gehele applicatie.
• Mogelijk worden verborgen bugs over het hoofd gezien: Integratieproblemen of uitzonderlijke gevallen kunnen onopgemerkt blijven.
• Geen vervanging voor een volledige test: Ze dienen als snelle filters, niet als vervanging voor regressietesten.

Beste praktijken voor implementatie

Voor rookproeven:

• Automatiseer rooktests en integreer ze in je CI/CD-pipeline voor elke build.
• Beperk de testsuite tot de kritieke functionaliteiten en laat deze niet te groot worden.
• Werk de rooktests bij telkens wanneer kritieke functies worden toegevoegd of gewijzigd.

Voor een controle op de betrouwbaarheid:

• Bekijk altijd de wijzigingsdocumentatie voordat u scenario's voor sanity tests maakt.
• Concentreer de testinspanningen op de gewijzigde gebieden en de direct daaraan verbonden functionaliteiten.
• Gebruik verkennende testtechnieken om onverwachte problemen aan het licht te brengen.

Veel voorkomende fouten te vermijden

• De twee testtypen door elkaar halen: Rooktesten zijn breed en oppervlakkig; een grondige controle op de realiteit is beperkt en diepgaand.
• Het overslaan van rooktesten om tijd te besparen: Dit leidt vaak tot verspilde moeite aan instabiele builds.
• Rooktesten te uitgebreid maken: Dit ondermijnt het nut van snelle verificatie.
• Verdergaan na mislukkingen: Als een van beide testtypen mislukt, stop dan en los de problemen op voordat u verdergaat.

Aanbevolen hulpmiddelen voor rook- en betrouwbaarheidstesten

• Selenium Webstuurprogramma: Industriestandaard voor automatisering van webapplicatietests
• TestNG/JUnit: Testframeworks voor het organiseren en uitvoeren van geautomatiseerde tests
• Jenkins/GitHub Actions: CI/CD-tools voor geautomatiseerde build- en testuitvoering
• Cypress: Modern, ontwikkelaarsvriendelijk end-to-end testframework
• Postman/REST Assured: API-testtools voor backend-smoketests

Veelgestelde vragen