Smoke testing versus sanity testing: wanneer gebruikt u welke?

De helft van de QA-teams gebruikt “smoke” en “sanity” als synoniemen. De andere helft voert daar discussies over tijdens de stand-ups. Beide groepen verliezen uren per sprint aan verkeerd gerouteerde tests, en de meesten hebben niet eens door dat dit gebeurt.

De verwarring gaat dieper dan alleen de terminologie. Kies de verkeerde testmethode en uw QA-ingenieurs besteden een uur aan het debuggen van een kortingscode terwijl het inlogproces sinds de ochtend-build al defect is. Kies de andere kant op en een smoke-test geeft stilletjes groen licht voor een release, waardoor een bug direct bij de klanten op maandagochtend terechtkomt. Het 2025 DORA Report toonde aan dat teams die levering versnellen met AI een verminderde stabiliteit ervaren wanneer hun onderliggende testdiscipline zwak is. Teams die die valkuil vermijden, combineren deze poorten meestal met een gestructureerde regressietest-aanpak die alles met elkaar verbindt.

Dit artikel geeft u direct de kern: smoke-testing controleert of de build draait, sanity-testing controleert of een specifieke wijziging werkt. Vervolgens leest u hoe u beide gebruikt zonder sprintcapaciteit te verspillen, en wat het werkelijk kost als teams de verkeerde keuze maken.

Wat smoke-testing werkelijk doet

Een smoke-test is de poortwachter, niet de testsuite zelf. Het beantwoordt één vraag: is deze build stabiel genoeg om te testen? Als inloggen niet werkt, de homepage een 500-foutmelding geeft of de databaseverbinding is weggevallen, dan brengt smoke-testing dit binnen tien minuten aan het licht. De build wordt afgekeurd en niemand in het proces verspilt verder tijd.

De discipline is belangrijker dan de definitie. Zodra een smoke-suite langer dan tien minuten duurt, verliezen engineers het vertrouwen en gaan ze eromheen werken. Houd het dus klein: vijf tot zeven kritieke paden, geen edge-cases, geen complexe validaties. Voor een e-commerce-build betekent dit meestal: de homepage laadt, inloggen werkt, zoeken levert resultaten op, een productpagina laadt, items kunnen aan de winkelwagen worden toegevoegd en het betaalproces start. Dat is de hele suite. Als een van deze stappen faalt, is de build bij voorbaat onbruikbaar.

Dit is ook waar automatisering zich terugbetaalt. Smoke-tests draaien bij elke merge naar main, elke deployment naar een nieuwe omgeving, elke nachtelijke build en elke overdracht van een release-candidate. Handmatige smoke-testing met die frequentie is een recept voor overgeslagen tests. Geautomatiseerde smoke-testing in CI/CD geeft het team binnen tien minuten een binair signaal en maakt QA-capaciteit vrij voor grondiger werk.

Een valkuil om in de gaten te houden: een geslaagde smoke-test betekent niet dat de build goed is. Het betekent dat de build testbaar is.

Wat sanity-testing werkelijk doet

Sanity-testing heeft een tegenovergestelde vorm. Waar smoke-tests breed over de hele applicatie heen testen, focust sanity-testing smal op één specifiek gebied waar zojuist iets is gewijzigd. Heeft een developer een bug in de kortingscode opgelost? Sanity dekt de kortingsflow, de herberekening van het totaalbedrag en de checkout-stap die daarvan afhankelijk is. Niets meer dan dat.

De trigger is altijd een doelgerichte wijziging: een bugfix, een configuratie-aanpassing, een kleine verbetering, een update van een externe integratie of een hotfix waar geen tijd is voor een volledige regressiecyclus. Sanity gaat ervan uit dat de build al stabiel is (de smoke-test is al geslaagd), dus de fundamentele controles worden overgeslagen. Er wordt direct gekeken naar: “werkt deze wijziging zoals verwacht en heeft het geen nabijgelegen functies kapotgemaakt?”

Sanity-testing is meestal handmatig. De reden is praktisch: wat getest moet worden verandert per build, waardoor gescripte sanity-suites binnen enkele weken verouderd zijn. Een QA-ingenieur die de wijziging begrijpt, presteert beter dan een gescripte suite die geschreven was voor de fix van de vorige sprint. De uitzondering zijn terugkerende gebieden met een hoog risico, zoals betalingen of authenticatie, waar maand na maand dezelfde soort patches verschijnen. Die zijn het waard om eenmalig te automatiseren.

Als sanity faalt, wordt de fix afgekeurd, maar de rest van de build blijft doorgaans in gebruik. Dat is het structurele verschil tussen smoke- en sanity-testing, en dat is waarom het onderscheid in de praktijk uitmaakt: smoke-fouten leggen de hele build plat, sanity-fouten leggen slechts een onderdeel ervan plat.

Smoke-testing vs. sanity-testing in vogelvlucht

Wanneer de twee naast elkaar worden gezet, wordt het onderscheid tussen smoke- en sanity-testing duidelijk. De onderstaande tabel is de vergelijking die elke QA-lead uiteindelijk wel een keer op een whiteboard schetst. Gebruik dit als referentie.

Het patroon is simpel zodra u het ziet: smoke is breedte, sanity is diepte. Haal ze door elkaar en u verspilt uren.

De 30-seconden beslisregel

Het hele debat over smoke testing versus sanity testing komt neer op één regel: gebruik smoke testing wanneer u een nieuwe build heeft en niet weet of deze überhaupt werkt. Gebruik sanity testing wanneer u een stabiele build heeft en één specifieke wijziging moet verifiëren.

Vier snelle voorbeelden van de regel in de praktijk:

• Nieuwe build opgeleverd vanuit development → smoke
• Losse bugfix doorgevoerd op een build die diezelfde ochtend al door de smoke test kwam → sanity
• Vrijdagmiddag-hotfix op een build die al in productie is → sanity, strikt afgebakend
• Grote refactor doorgevoerd die 14 bestanden raakte → eerst smoke, daarna sanity op elke gewijzigde module

Dat is de volledige beslisboom. De aanleiding is wat er veranderd is, niet hoe lang geleden het veranderd is en ook niet hoe zeker de ontwikkelaar is van de fix.

Waar regression testing in het plaatje past

Smoke en sanity zijn poortwachters. Regression is de volledige controle die bevestigt dat de rest van de applicatie nog steeds werkt nadat alles al is goedgekeurd. Smoke draait bij elke build, sanity draait na elke gerichte wijziging, regression draait elke nacht of vóór een release.

De relatie is hiërarchisch. Sanity is technisch gezien een subset van regression: het hergebruikt testgevallen uit de regression-suite, maar beperkt deze tot het gewijzigde gebied. De problemen ontstaan wanneer teams de twee als dezelfde suite behandelen. Een “sanity test” die zes uur duurt voor een hotfix is geen sanity test meer, maar een regression-cyclus met een sanity-label, waardoor het team het snelheidsvoordeel verliest dat sanity juist de moeite waard maakte.

De drie lagen werken samen: smoke bewaakt de build, sanity bewaakt de wijziging, regression bewaakt de release. Slaat u een laag over, dan komen de kosten elders naar boven.

Wanneer gebruikt u wat, met praktijkvoorbeelden

Theorie is eenvoudig. Het lastige is de juiste beslissing nemen wanneer een ontwikkelaar om 16:30 uur een PR in Slack dropt. Hier zijn de patronen die we het meest zien en de juiste aanpak voor elk scenario.

Een ontwikkelaar heeft een refactor gemerged die 14 bestanden raakte. De build is nieuw en de impact is groot. Draai eerst smoke, want alles zou kapot kunnen zijn. Als dit slaagt, draai dan sanity op elke module die door de refactor is geraakt. Sla de volledige regression over, tenzij de release op handen is.

Er is een bugfix doorgevoerd voor een enkele inlogfout. De build zelf is dezelfde die die ochtend door de smoke test kwam. Smoke is niet opnieuw nodig, omdat het fundament niet is veranderd. Draai sanity op de inlogflow en de twee flows die daarvan afhankelijk zijn (wachtwoordherstel, accountvergrendeling). Tien minuten werk, geen uur.

Een vrijdagmiddag-hotfix moet live voor een checkout-bug. De build is dezelfde die in productie draait, met één gerichte wijziging. Sanity is hier de juiste keuze, strikt afgebakend op het checkout-pad. Smoke zou kostbare tijd verspillen aan flows die sinds vorige week niet zijn veranderd.

Een nachtelijke build is vanuit main opgeleverd met tien gemergde PR’s. Geautomatiseerde smoke testing draait eerst, daarna volgt de volledige regression ‘s nachts. Dit is de cadans waarbij automatisering zichzelf terugbetaalt.

Een externe payment API is geüpgraded. Dit is een fundamentele integratie, dus smoke testing dekt dit af (start de app nog op, laadt de checkout nog), daarna dekt sanity de betaalflows in de diepte af.

Een designer heeft een CSS-wijziging doorgevoerd. Het is verleidelijk om testen volledig over te slaan. Doe dit niet. Draai sanity op de betreffende schermen en verifieer of de authenticatie nog steeds werkt, want fouten in CSS-specificiteit kunnen inlogflows echt kapotmaken.

Wat het kost als u dit verkeerd aanpakt

De meeste teams meten de kosten van een verkeerde testbeslissing niet, omdat het verlies verborgen zit in de normale sprintcapaciteit. Het uit zich als “QA is traag” of “we missen continu release-deadlines”, terwijl het werkelijke probleem is dat er uren worden besteed aan het testen van de verkeerde laag. Het patroon verergert wanneer teams AI-gegenereerde code toevoegen aan een gebrekkige testdiscipline: de Stack Overflow Developer Survey van 2025 toonde aan dat 45% van de ontwikkelaars zegt dat het debuggen van AI-gegenereerde code meer tijd kost dan verwacht, en 66% noemt “bijna goed, maar net niet” oplossingen als hun grootste frustratie. Het verwarren van smoke- en sanity testing levert dezelfde soort verborgen belasting op: uren die op werk lijken, maar in feite rework zijn.

Sanity draaien op een onstabiele build

Het scenario: een ontwikkelaar pusht om 9 uur ‘s ochtends een fix voor een bug in de kortingscode. QA pakt dit op, begint direct met sanity testing op de kortingsflow, besteedt een uur aan het valideren van edge cases, en ontdekt rond 10:15 uur dat de inlogservice op dezelfde build 500-fouten geeft, en dat is al sinds de merge van die ochtend het geval.

Dat uur is verloren, inclusief de cognitieve belasting van het debuggen op de verkeerde laag. De QA-ingenieur moet nu wachten op een nieuwe build, de omgeving resetten en opnieuw beginnen. Vermenigvuldig dit met het aantal keren dat dit patroon zich in een sprint herhaalt en u verliest per cyclus het grootste deel van een dag. De oplossing is mechanisch: smoke bewaakt elke nieuwe build voordat sanity ermee aan de slag gaat. Geen uitzonderingen.

Smoke draaien wanneer u sanity nodig heeft

Het omgekeerde scenario is gevaarlijker omdat de wijziging dan live gaat. Een ontwikkelaar lost een bug in de kortingscode op. QA draait de smoke-suite, die controleert of inloggen werkt, de homepage laadt en het checkout-proces start. Alles slaagt. De fix gaat live.

De daadwerkelijke bug in de kortingscode zat nooit in het pad van de smoke-suite, omdat smoke niet diep in de kortingsflow duikt. Klanten lopen er maandagochtend tegenaan. Nu is het een productie-incident, geen testcyclus, en de kosten zijn zojuist gestegen van QA-uren naar engineering-uren, plus support-tickets en een deuk in het vertrouwen. Dit is precies het type falen dat een goede DORA Change Failure Rate verandert in een slechte. Sanity is bedoeld om dit soort bugs te vangen. Het overslaan ervan omdat “smoke slaagde” is de meest voorkomende versie van de verwarring tussen sanity- en smoke testing, en de duurste.

De checklist voor het QA-team

De les is operationeel, niet theoretisch. Houd deze checklist naast uw huidige QA-proces en het grootste deel van de kosten door verkeerd uitgevoerde tests verdwijnt.

Vóór elke build:

• De smoke-suite draait automatisch in CI/CD, duurt minder dan tien minuten en beslaat vijf tot zeven kritieke paden
• Als smoke faalt, wordt de build afgewezen en vindt er geen verdere testing op plaats
• Smoke-suites worden per kwartaal beoordeeld en bijgewerkt wanneer kritieke functies veranderen

Na elke gerichte wijziging:

• Identificeer wat er is veranderd en welke flows hieraan grenzen
• Draai sanity alleen binnen die scope, niet op de hele applicatie
• Documenteer de sanity-scope in de pull request zodat de volgende persoon weet wat wel en niet is afgedekt
• Automatiseer sanity pas wanneer hetzelfde gebied herhaaldelijk wordt gepatcht

Vóór elke release:

• Volledige regression draait op een build die al door de smoke- en sanity-poorten is gekomen
• Sanity vervangt nooit de regression voor een release candidate
• Release-vertrouwen komt voort uit het slagen van alle drie de lagen, niet uit het goed slagen van slechts één ervan

Nog één keer de regel: smoke bewaakt de build, sanity bewaakt de wijziging, regression bewaakt de release. De meeste vertragingen in QA komen doordat de verkeerde test wordt gedraaid. De oplossing is niet een nieuwe tool, maar discipline in welke test welke vraag beantwoordt. Wilt u dat een team met ervaring in honderden opgeleverde projecten meekijkt naar uw QA-proces? Neem contact met ons op.