Antwoord.

Achtergrond van de vraag:

Smoke-testing ("rooktest") is ontstaan als een snelle manier om de functionaliteit van een systeem na een build te controleren. Het doel is om ervoor te zorgen dat kritieke functies werken en de applicatie geschikt is voor verdere, diepgaandere controles. Bij handmatig testen worden smoke-tests meestal direct na de release van een nieuwe versie van het product uitgevoerd.

Probleem:

De grootste uitdaging is de beperkte tijd en de noodzaak om echt belangrijke controles te selecteren. Vaak controleren testers te veel (verspillen middelen) of laten ze kritiek dingen achterwege, waardoor er "gaten" in de release kunnen zitten.

Oplossing:

Een goede organisatie van smoke-testing bestaat uit het selecteren van een strikt minimaal aantal scenario's die de belangrijkste gebruikersstromen dekken. Deze controles moeten duidelijk, snel en reproduceerbaar zijn. Bijvoorbeeld:

- Succesvolle inlog van de gebruiker
- Mogelijkheid om de belangrijkste functie uit te voeren (bijvoorbeeld een aankoop doen)
- Betaling uitvoeren en bevestiging ontvangen

Belangrijke kenmerken:

Smoke-tests dekken alleen de levensbelangrijke functies
Snelle uitvoering, wat cruciaal is bij frequente releases
Alle scenario's worden handmatig uitgevoerd volgens een vooraf goedgekeurde checklist

Vragen met een twist.

Kan smoke-testing worden beschouwd als een volwaardige vervanging voor regressietests?

Nee, smoke-testing is gericht op "werkt - werkt niet" voor sleutel-functies. Voor het opsporen van ernstige, maar niet-evidente bugs is altijd een volledige regressie nodig.

Wat te doen als ten minste één smoke-test niet is geslaagd? Moet de testing doorgaan?

Nee, verdere testing heeft geen zin - het team meldt het probleem, de release wordt geblokkeerd totdat de bug is opgelost.

Moeten smoke-tests checks voor edge-case scenario's bevatten?

Nee, smoke-tests zijn niet bedoeld om randgevallen te verifiëren. Ze zijn alleen bedoeld om de mogelijkheid van het functioneren van de belangrijkste productfuncties te bevestigen.

Typische fouten en anti-patronen

Het uitvoeren van overbodige tests die niet cruciaal zijn voor de functionaliteit
Gebrek aan documentatie over smoke-tests (tester "houdt alles in zijn hoofd")
Het negeren van voor de hand liggende problemen voor de "rapportage"

Voorbeeld uit het leven

Negatieve case

De smoke-test werd uitgevoerd met een uitgebreide checklist die onbelangrijke functies omvatte. Dit kostte veel tijd, waardoor de release een halve dag werd vertraagd.

Voordelen:

Verschillende onopvallende bugs gevonden.

Nadelen:

Vertraging van de release
Middelen en tijd verspild aan onbelangrijke controles

Positieve case

De smoke-test was alleen gericht op de meest kritische scenario's. Een blokkering bug werd snel ontdekt en het team werd op de hoogte gesteld — de release werd stopgezet tot de fix.