Antwoord.

Het organiseren van handmatig testen op de releasedatum is een geheel aan maatregelen voor het snel en effectief opsporen van defecten in de voorbereidende versie van het product, met de focus op de meest kritieke en vaak gebruikte functies.

Achtergrond van de vraag: In het verleden gingen releases vaak gepaard met "nachtelijke spoedopdrachten": testers haastten zich om alles na te kijken, wat leidde tot verminderde kwaliteit van het testen, bugs "vlogen" naar productie, en middelen werden inefficiënt besteed. Het werd geleidelijk opgemerkt dat door duidelijke prioritering betere resultaten in kortere tijd kunnen worden behaald.

Probleem: Beperkte tijd voor testen voor de release staat geen algehele controle toe, daarnaast neemt de menselijke factor toe — vermoeidheid, haast, stress. Kritieke bugs duiken vaak pas na de release op, wat de reputatie van het product ondermijnt en chaos in het team creëert.

Oplossing:

Samen met het bedrijfsleven, analisten, en developers de kritische en zakelijke belangrijke scenario's beoordelen.
Een releasechecklijst opstellen met zogenaamde "snijdende" scenario's — diegene die het meest worden gebruikt of risicovol zijn.
Een laatste smoke- en sanity-test handmatig uitvoeren: het opstarten van het systeem, inloggen, het plaatsen van bestellingen, betalingen, enzovoort controleren.
Duidelijk de verantwoordelijkheden afbakenen: wie verantwoordelijk is voor testdata, wie voor rapportages van ontdekte defecten, wie voor communicatie met de developers.

Kernkenmerken:

Prioritering van bugs: kritische defecten eerst opsporen en escaleren.
Gebruik van korte, snel uitvoerbare testcases en checklists.
Vlotte communicatie met het ontwikkelingsteam voor snelle correcties.

Vragen met een knipoog.

Is het mogelijk om "extra voorzichtig" te zijn en de hele applicatie handmatig te testen voor de release?

Nee, er is meestal geen tijd voor volledige handmatige testing — een weloverwogen benadering met focus op sleutelscenario's geeft betere resultaten.

Moet je voor de release "kleine" bugs rapporteren, zodat het team er vooraf van op de hoogte is?

Nee, in de release modus moeten alleen kritieke en blokkades defecten worden geëscaleerd, minder significante problemen kunnen worden geclassificeerd als known issues en na de release worden opgepakt.

Is het verplicht om gedetailleerde testcases handmatig te schrijven voor de release?

Nee, vaak is het eenvoudiger en sneller om met checklists of mini-scripts van testcases te werken, wat het mogelijk maakt om snel door relevante scenario's te gaan.

Veelvoorkomende fouten en anti-patterns

Het uitstellen van testen tot het laatste moment — waardoor alles in haast wordt gedaan met kwaliteitsverlies als resultaat.
Het controleren van zelden gebruikte of minder belangrijke scenario's ten koste van kritieke.
Het ontbreken van een laatste smoke/sanity test vlak voor de release.

Voorbeeld uit de praktijk

Negatieve case

De release-test wordt 's nachts uitgevoerd, terwijl enkele documenten vluchtig worden gecontroleerd; ze vergeten de kritische betalingsflow. De volgende dag kunnen gebruikers in massale mate hun bestelling niet betalen.

Voordelen:

Hoge snelheid van controle.

Nadelen:

Kritische bug werd gemist.
Risico's van stress in het midden van de nacht, misgelopen communicatie met developers.

Positieve case

Voor de release wordt de focus alleen gelegd op kritische scenario's (inloggen, betaling, bestelling bevestigen, integratie met partners). De resultaten worden door de checklist gehaald, bugs worden onmiddellijk geëscaleerd.