Software is klaar om live te gaan wanneer het voldoet aan vooraf vastgestelde acceptatiecriteria op zowel functioneel als niet-functioneel vlak, en wanneer de resterende bekende risico’s bewust zijn geaccepteerd door de juiste stakeholders. Er bestaat geen universeel moment waarop software “af” is, maar er bestaat wel een duidelijk proces om die beslissing verantwoord te nemen. Als je twijfelt of jouw software aan de juiste criteria voldoet, neem dan gerust contact op met ons. In dit artikel beantwoorden we de meest gestelde vragen rondom de releasebeslissing, van acceptatiecriteria tot performance testen en alles daartussenin.
Welke criteria bepalen of software klaar is voor livegang?
Software is klaar voor livegang wanneer het voldoet aan de afgesproken acceptatiecriteria: alle kritieke functionaliteiten werken correct, de bekende fouten vallen binnen een acceptabel risiconiveau, en de niet-functionele eisen zoals snelheid en stabiliteit zijn gevalideerd. De releasecriteria moeten vooraf zijn vastgesteld, niet achteraf worden bepaald.
In de praktijk betekent dit dat een team voor de start van een sprint of testfase al moet definiëren wat “klaar” inhoudt. Denk aan het percentage geslaagde testgevallen, het maximale aantal openstaande bugs per prioriteit, en de minimale responstijd onder belasting. Zonder deze vooraf vastgestelde normen wordt de go-live beslissing een subjectieve discussie in plaats van een feitelijke afweging.
Goede acceptatiecriteria voor software zijn concreet en meetbaar. Vage formuleringen zoals “de software moet stabiel zijn” leiden tot discussie op het verkeerde moment. Formuleer criteria altijd als toetsbare uitspraken: “de applicatie verwerkt 500 gelijktijdige gebruikers zonder foutmeldingen” of “alle P1-bugs zijn opgelost voor livegang.”
Wat is het verschil tussen functioneel en niet-functioneel testen bij een release?
Functioneel testen controleert of de software doet wat het moet doen: voldoet de functionaliteit aan de specificaties? Niet-functioneel testen controleert hoe de software het doet: is het snel genoeg, stabiel genoeg en veilig genoeg? Beide vormen zijn noodzakelijk voor een verantwoorde releasebeslissing, maar worden in de praktijk nog te vaak ongelijk behandeld.
Bij functioneel testen draait het om gebruikersscenario’s, ketenintegraties en businesslogica. Werkt de bestelflow? Worden berekeningen correct uitgevoerd? Reageert het systeem zoals verwacht op uitzonderingen? Dit type testen is voor de meeste teams het meest vertrouwd.
Niet-functioneel testen omvat onder andere performance, beveiliging, bruikbaarheid en beschikbaarheid. Deze aspecten worden pas zichtbaar onder specifieke omstandigheden, zoals hoge belasting of onverwacht gebruikersgedrag. Een applicatie die functioneel perfect werkt, kan alsnog falen bij de eerste piekbelasting na livegang. Juist daarom is niet-functioneel testen een onmisbaar onderdeel van iedere softwarekwaliteitsstrategie voor deployment.
Hoe werkt een go/no-go beslissing in de praktijk?
Een go/no-go beslissing is een formeel moment waarop alle betrokken partijen, op basis van testresultaten en risicoanalyse, gezamenlijk besluiten of software klaar is voor livegang. Het is geen technische beslissing alleen, maar een gezamenlijke verantwoordelijkheid van business, IT en management.
In de praktijk verloopt dit via een gestructureerde meeting of checkpoint waarbij de volgende vragen centraal staan:
- Zijn alle acceptatiecriteria getoetst en gedocumenteerd?
- Wat zijn de openstaande bevindingen en wat is hun impact?
- Zijn de resterende risico’s geaccepteerd door de juiste beslisser?
- Is de uitrolstrategie en het rollback-plan gereed?
- Zijn de juiste stakeholders aanwezig en akkoord?
Een go/no-go beslissing werkt alleen goed als de testresultaten transparant en begrijpelijk zijn voor iedereen aan tafel, inclusief de business. Technisch jargon zonder context leidt tot beslissingen op onderbuikgevoel in plaats van op feiten. Heldere rapportages zijn daarom geen bijzaak, maar een kernonderdeel van het proces.
Wanneer is een bekende bug geen blokkade voor livegang?
Een bekende bug is geen blokkade voor livegang wanneer de impact ervan beperkt is, een workaround beschikbaar is, of het risico bewust en gedocumenteerd is geaccepteerd door een bevoegde beslisser. Niet elke fout hoeft opgelost te zijn voor software deployment, maar elke fout moet wel bewust zijn beoordeeld.
De sleutel ligt in prioritering. Bugs worden doorgaans ingedeeld op ernst (severity) en prioriteit. Een P1-bug die een kernproces blokkeert, is altijd een showstopper. Een P3-bug die slechts een kleine groep gebruikers raakt onder specifieke omstandigheden, kan worden meegenomen in een volgende release, mits dit expliciet is afgesproken.
Wat je wilt vermijden, is de situatie waarin bugs stilzwijgend worden genegeerd of ongedocumenteerd blijven. Iedere bekende fout die niet wordt opgelost voor livegang, moet zijn vastgelegd in een risicoregister met daarin de impact, de eigenaar en de geplande oplossing. Zo blijft de releasebeslissing verantwoord en traceerbaar.
Welke rol speelt performance testen in de releasebeslissing?
Performance testen bepaalt of software onder realistische belasting voldoet aan de gestelde eisen voor snelheid, stabiliteit en schaalbaarheid. Het is een onmisbaar onderdeel van de releasebeslissing, omdat performanceproblemen na livegang direct zichtbaar zijn voor eindgebruikers en moeilijk snel op te lossen zijn.
Een applicatie die functioneel correct werkt, kan bij hoge belasting volledig vastlopen. Performance testen simuleert die situaties vooraf, zodat bottlenecks worden ontdekt voordat ze in productie optreden. Denk aan laadtijden die oplopen bij gelijktijdige gebruikers, database queries die vertragen bij grote datasets, of integraties die time-outs veroorzaken onder druk.
Wij integreren performance testen zo vroeg mogelijk in het ontwikkelproces, wat ook wel Shift-Left performance testing wordt genoemd. Door dit niet te bewaren voor het einde van een project, maar structureel te testen tijdens de ontwikkeling, worden problemen eerder gevonden en goedkoper opgelost. Een zorgeloze teststrategie borgt dat performance nooit een verrassing is op het moment van de go-live beslissing.
Hoe voorkom je dat een livegang achteraf alsnog mislukt?
Een livegang mislukt achteraf wanneer risico’s niet zijn onderkend, monitoring ontbreekt, of het rollback-plan niet is getest. Je voorkomt dit door niet alleen te testen voor livegang, maar ook actief te monitoren na deployment en een concreet terugvalplan klaar te hebben staan.
De meest voorkomende oorzaken van een mislukte livegang zijn:
- Onvoldoende testen in een productie-achtige omgeving
- Geen of onvoldoende monitoring direct na deployment
- Ontbrekend of ongetest rollback-plan
- Onvoldoende afstemming tussen development, operations en business
- Acceptatiecriteria die niet overeenkomen met de werkelijke gebruiksomstandigheden
Een gecontroleerde uitrol, zoals een canary release of een gefaseerde uitrol naar een beperkte gebruikersgroep, verkleint het risico aanzienlijk. Zo kun je het gedrag van de software in productie observeren voordat alle gebruikers worden overgezet. Combineer dit met realtime monitoring en duidelijke escalatieprocedures, en je hebt een solide vangnet onder iedere releasebeslissing.
Wil je meer grip op de kwaliteit van jouw software voor en na livegang? Wij helpen organisaties met een aanpak die past bij hun situatie, van acceptatiecriteria tot performance testen en releasestrategie. Neem contact op en we denken graag met je mee.
Veelgestelde vragen
Hoe stel je acceptatiecriteria op als je dat nog nooit eerder hebt gedaan?
Begin met het inventariseren van de meest kritieke gebruikersscenario's en bedrijfsprocessen die de software moet ondersteunen. Formuleer vervolgens voor elk scenario een concrete, meetbare norm, zoals een maximale laadtijd, een minimaal slagingspercentage van testgevallen, of een maximaal aantal toegestane openstaande bugs per prioriteitsklasse. Betrek zowel de business als het technische team bij dit proces, zodat de criteria aansluiten bij de werkelijke gebruiksomstandigheden én technisch haalbaar zijn.
Wat als stakeholders het onderling niet eens worden tijdens de go/no-go beslissing?
Onenigheid tijdens een go/no-go meeting is vaak een signaal dat de acceptatiecriteria vooraf niet scherp genoeg zijn gedefinieerd of niet door iedereen zijn gedragen. Zorg er daarom voor dat criteria ruim vóór de releasedatum worden vastgesteld en formeel worden goedgekeurd door alle relevante partijen. Als er op het moment van de go/no-go toch discussie ontstaat, is het raadzaam om de beslissing te baseren op gedocumenteerde feiten en risicoanalyses in plaats van meningen, en indien nodig een escalatiepad te volgen naar een eindverantwoordelijke beslisser.
Hoe weet je of je testomgeving representatief genoeg is voor productie?
Een testomgeving is representatief als de infrastructuur, datahoeveelheden, integraties en gebruikersvolumes zoveel mogelijk overeenkomen met de productieomgeving. Controleer of de testdata realistisch is qua omvang en diversiteit, of externe koppelingen correct zijn gesimuleerd of beschikbaar zijn, en of de hardware- en netwerkconfiguratie vergelijkbaar is. Verschillen tussen test en productie zijn een van de meest voorkomende oorzaken van onverwachte problemen na livegang, dus documenteer bewust welke afwijkingen er zijn en wat de mogelijke impact daarvan is.
Hoe vaak moet je performance testen uitvoeren tijdens een project?
Idealiter voer je performance testen niet eenmalig uit aan het einde van een project, maar integreer je ze structureel in het ontwikkelproces, conform het Shift-Left principe. Dit betekent dat je al vroeg in de ontwikkeling basismetingen uitvoert en deze herhaalt bij elke significante wijziging in de architectuur, datastructuur of belastingsverwachting. Door performance continu te monitoren tijdens ontwikkeling, ontdek je regressies tijdig en voorkom je dat je vlak voor de livegang voor kostbare verrassingen komt te staan.
Wat moet er minimaal in een rollback-plan staan?
Een goed rollback-plan beschrijft stap voor stap hoe je de software terugzet naar de vorige stabiele versie, wie daarvoor verantwoordelijk is, en binnen welke tijdslimiet dit moet gebeuren. Neem ook op welke signalen of drempelwaarden aanleiding geven om het rollback-plan te activeren, zoals een bepaald foutenpercentage of een kritieke systeemuitval. Belangrijk is dat het rollback-plan niet alleen op papier bestaat, maar ook daadwerkelijk is getest in een acceptatieomgeving voordat de livegang plaatsvindt.
Welke veelgemaakte fouten moet je vermijden bij het opstellen van een risicoregister voor bugs?
De meest gemaakte fout is dat het risicoregister wordt ingevuld als formaliteit, zonder dat er een echte eigenaar of concrete oplossingsdatum aan elke bug wordt gekoppeld. Zorg ervoor dat elke openstaande bug in het register voorzien is van een beschrijving van de impact, de kans dat het probleem zich voordoet, een aangewezen verantwoordelijke en een realistisch tijdpad voor oplossing. Vermijd ook vage omschrijvingen van het risico; hoe specifieker het register, hoe beter de beslissers aan tafel een gefundeerde keuze kunnen maken.
Is een gefaseerde uitrol altijd de beste aanpak, of zijn er situaties waarin je beter in één keer live gaat?
Een gefaseerde uitrol, zoals een canary release, is in de meeste gevallen de veiligste strategie omdat je het gedrag van de software in productie kunt observeren voordat alle gebruikers worden blootgesteld aan eventuele problemen. Er zijn echter situaties waarin een big bang release de voorkeur verdient, bijvoorbeeld wanneer een gefaseerde uitrol technisch niet haalbaar is door tightly coupled systemen, of wanneer het zakelijk noodzakelijk is dat alle gebruikers tegelijkertijd overstappen, zoals bij een volledige platformvervanging. In dat geval is het extra belangrijk dat monitoring, rollback-plan en escalatieprocedures volledig op orde zijn vóór de livegang.
Deze inhoud is gegenereerd met behulp van AI en kan fouten bevatten.