En release betragtes som klar til idriftsættelse, når følgende kriterier er opfyldt:
Automatiseret regressionstest
- Alle testcases med status "Implementeret" er afviklet
- 0 fejl med severity Kritisk eller Høj
- Kendte fejl med severity Medium eller Lav er dokumenteret og accepteret af Product Owner
Manuel test (RFC'er in scope)
- Alle RFC'er markeret "in scope" i testplanen er afviklet
- Testresultat er dokumenteret i Jira
- 0 uafklarede fejl uden en beslutning om accept eller udsættelse
Definition af severity-niveauer
| Severity | Definition | Eksempel |
|---|---|---|
| Kritisk | Systemet er utilgængeligt eller data er korrupt. Ingen workaround. | Service returnerer fejl på alle kald |
| Høj | Kernefunktionalitet virker ikke korrekt. Workaround mulig men uacceptabel i produktion. | Forkerte data returneres for specifik brugertype |
| Medium | Funktionalitet påvirket men workaround acceptabel kortsigtet. | Fejl i ikke-kritisk felt der ikke påvirker kerneopslag |
| Lav | Kosmetisk fejl eller mindre afvigelse uden funktionel konsekvens. | Forkert formatering i svarbesked |
GO/NO-GO beslutningsproces
Beslutningstager: Test Manager og Release Manager udsteder en formel GO/NO-GO anbefaling baseret på exit-kriterierne. Den endelige beslutning om idriftsættelse træffes af Product Owner.
Proces:
- Test Manager dokumenterer testresultat og severity på alle åbne fejl i testplanen
- Test Manager udsteder skriftlig GO eller NO-GO anbefaling med begrundelse
- Ved NO-GO: Release stoppes. Fejl overdrages til vedligeholdelsesleverandør som Bug
- Ved GO med forbehold: Accepterede fejl dokumenteres eksplicit i testplanen med PO-signoff
- Beslutning og begrundelse arkiveres i Jira på testplanen
Non-negotiable: En release må aldrig idriftsættes med en Kritisk fejl uanset tidspres eller andre hensyn. Dette kræver ikke yderligere godkendelse – det er et absolut stop.