04 nov 2026 Smoketest: de snelle check die zegt of een build het testen waard is

In het kort: Een smoketest is een korte set controles op je belangrijkste functies, direct na een build of een deployment. Binnen een paar minuten weet je of de software opstart, reageert en zijn hoofdtaken kan doen. Faalt de smoketest, dan heeft dieper testen nog geen zin. Automatiseer hem, houd hem klein en draai hem in elke omgeving.

Weinig dingen kosten een tester zo nutteloos een ochtend als dit. Er staat een nieuwe build in de testomgeving, de regressierun start, en twee uur later is elke test rood. De oorzaak was een ontbrekende instelling waardoor het inloggen niet werkte. Een check van twee minuten had dat gevonden voordat iemand begon. Die check van twee minuten is een smoketest. Het is een van de goedkoopste tests die je kunt hebben, en een van de meest vergeten.

Wat is een smoketest?

Een smoketest is een snelle, oppervlakkige controle of de belangrijkste onderdelen van je software überhaupt werken. Hij draait direct na een nieuwe build of een deployment, voordat iemand tijd steekt in diepere tests. De naam komt uit de hardware: zet je een nieuw apparaat aan en komt er rook uit, dan hoef je niet verder te testen. Bij software is de rook een login die faalt, een pagina die niet laadt of een betaaldienst die niet antwoordt. De ISTQB-woordenlijst omschrijft het als een deel van de tests dat de hoofdfuncties afdekt, om te bepalen of verder testen zin heeft. In het Engels heet het smoke testing, of ook wel een build verification test. Een smoketest zoekt geen subtiele bugs. Hij beantwoordt één vraag: is deze build het testen waard, of kan deze release blijven staan? Omdat dat antwoord snel moet komen, blijft hij klein. Meestal draait hij in een paar minuten.

Het SRE-boek van Google beschrijft smoketests op dezelfde manier: eenvoudige controles op kritiek gedrag, die een kapotte build vroeg tegenhouden.

Wat is het verschil tussen een smoketest, sanity test en regressietest?

Elk beantwoordt een andere vraag, op een andere diepte. Een smoketest controleert of de hele build leeft. Een sanity test controleert of één specifieke wijziging of oplossing werkt, nadat de smoketest is geslaagd. Een regressietest controleert of alles wat eerder werkte, nog steeds werkt. De termen lopen vaak door elkaar. Spreek daarom in je team af wat je met elk bedoelt. Deze tabel laat de gebruikelijke verdeling zien.

Ze bouwen op elkaar voort. Faalt de smoketest, dan heeft het geen zin om aan de andere te beginnen. Onze uitleg over de regressietest gaat over de diepste laag.

Wat hoort er in een smoketest?

Neem de paar dingen op die je bedrijf niet kan missen, en controleer ze oppervlakkig van begin tot eind. Denk aan wat je binnen het uur een release zou laten terugdraaien. Die lijst is meestal kort. Bij een webshop is dat bijvoorbeeld inloggen, zoeken, iets in de winkelwagen leggen en de betaalpagina bereiken. Bij een intern systeem is het inloggen, een dossier openen en een wijziging opslaan. Deze onderdelen heeft bijna elke smoketest nodig.

• Opstarten en inloggen. De applicatie laadt en een testgebruiker kan inloggen.
• De hoofdprocessen, oppervlakkig. Elk kritiek proces krijgt één snelle doorloop, zonder alle varianten.
• De koppelingen eromheen. Betaling, voorraad, e-mail en andere gekoppelde systemen geven antwoord.
• Belangrijke pagina’s en diensten. De pagina’s en API’s die de meeste gebruikers raken, reageren zonder fouten.

De koppelingen schieten er het vaakst bij in. Bij klanten zien we vaak dat een nieuwe koppeling één keer zorgvuldig wordt getest, bij de livegang. Daarna komt hij nooit in de regressietests of sanity tests terecht. Breekt een latere wijziging de verbinding, dan merkt niemand het tot een klant het merkt. Een snelle controle via de API, de laag waarop systemen gegevens uitwisselen, vangt dat in een paar seconden af.

Wat erbuiten blijft, telt net zo zwaar. Geen randgevallen, geen lange datacontroles, geen zeldzame instellingen. Die horen in de regressieset. Elke test die je toevoegt, maakt de smoketest trager, en snelheid is juist het hele punt.

Hoe houd je een smoketest bruikbaar?

Automatiseer hem, draai hem na elke deployment, en laat hem nooit falen zonder echte reden. Een smoketest die iemand met de hand moet starten, schiet erbij in als de tijd krap is. En juist dan heb je hem nodig. Draai hem in elke omgeving: test, acceptatie en productie. Gebruik in productie testaccounts en testbestellingen die geen echte klanten of echt geld raken. Spreek af wat er gebeurt als hij faalt: de deployment stopt, of de release gaat terug.

Het grootste risico is een smoketest die willekeurig faalt. Wordt hij een paar keer rood zonder echt probleem, dan gaan mensen hem negeren. Dan beschermt hij niets meer. Behandel een onbetrouwbare smoketest als een dringende bug, en repareer of verwijder de test nog dezelfde dag. In ons stuk over flaky tests lees je de gebruikelijke oorzaken. Het onderzoek van DORA naar test automation zegt hetzelfde: een test is pas nuttig als een fout op een echt probleem wijst.

Wees ook duidelijk over wat een smoketest niet kan. Groen betekent dat de build niet kapot is. Het betekent niet dat de build goed is. Diepere regressietests moeten nog steeds draaien. Exploratief testen door mensen vindt nog steeds wat geen script controleert. En acceptatietesten door je gebruikers uit de business bepalen nog steeds of een wijziging past bij hoe zij werken.

Wat betekent dit voor je team?

Een eerste smoketest schrijven kost een dag of twee. Hem goed houden is het doorlopende werk. Elke nieuwe functie of koppeling kan veranderen wat kritiek is. Logins veranderen, testaccounts verlopen, en een stabiele test begint willekeurig te falen. In veel teams is dat werk van niemand, dus de smoketest raakt langzaam verouderd. Dan zit je weer twee uur in een regressierun voordat je het merkt.

Dat doorlopende werk hoort bij wat we doen met Test Automation as a Service. Samen met je team zetten we smoketests en een regressieset op die je kritieke processen en de koppelingen eromheen afdekken. Je tests draaien elke nacht, en wij houden ze betrouwbaar. Je krijgt een stabiele testset waar je team op kan vertrouwen, die niet van één persoon afhangt. Je team houdt de regie over wat er live gaat.

Een eerste stap voor deze week: schrijf de vijf dingen op waarvoor je een release binnen het uur zou terugdraaien. Kijk dan welke daarvan je team na elke deployment automatisch test.

Veelgestelde vragen

Wat is het verschil tussen een smoketest en een sanity test?

Een smoketest controleert of de hele build op basisniveau werkt. Een sanity test controleert of één specifieke wijziging of oplossing werkt. Meestal draai je eerst de smoketest, daarna de sanity test.

Hoe lang mag een smoketest duren?

Minuten, geen uren. Veel teams mikken op minder dan tien of vijftien minuten. Duurt hij langer, dan is hij waarschijnlijk uitgegroeid tot een regressieset en moeten er tests uit.

Draai je een smoketest ook in productie?

Ja, direct na elke release. Gebruik testaccounts en testbestellingen die geen echte klanten of echt geld raken. Zo weet je het snelst of je de release laat staan of terugdraait.

Wie schrijft de smoketests?

Testers en developers samen, met input uit de business over wat kritiek is. Testers weten wat vaak breekt, developers weten wat er veranderde, en de business weet wat niet mag stilvallen.