Retest efter rettelser i en ny release

I et softwareprodukt bliver fund ikke nødvendigvis rettet alene. Rettelsen kommer ud i en ny release sammen med nye funktioner, opdaterede komponenter og andre ændringer, og så er spørgsmålet, hvad retesten egentlig bekræfter. Svaret hviler på to ting: retesten skal ske i den version, kunderne faktisk får, og den bekræfter kun de fund, der bliver efterprøvet, ikke resten af releasen.

Det lyder enkelt, men forskellen mellem den rettede version og den testede version er netop det, en opmærksom kunde vil spørge ind til.

Hvorfor releasen gør retesten anderledes

I en klassisk test af et internt system retter driften fundene i det samme system, og testeren kan efterprøve dem kort efter. I et SaaS-produkt går rettelsen gennem jeres udviklingsforløb: kode, kodegennemgang, test, staging og udrulning. Først når den er ude hos kunderne, er fundet rettet for dem. Indtil da er fundet åbent, uanset hvor langt rettelsen er nået internt.

Det giver tre mulige tidspunkter for retesten: i udviklingsmiljøet, i staging før udrulning eller i produktionen efter udrulning. De siger ikke det samme. Kun den sidste viser, at rettelsen er nået helt ud. De to første kan stadig være nyttige, men så skal I vide, at den version, der blev efterprøvet, er den samme, der senere blev rullet ud. → Hyppige udrulninger: hvilken version skal testes?

Hvad retesten dækker, og hvad den ikke dækker

En retest er en målrettet kontrol af bestemte fund. Testeren prøver, om svagheden stadig kan udnyttes på samme måde, og om rettelsen holder over for oplagte varianter. Det er ikke en ny test af produktet.

Når rettelserne kommer i en release med meget andet, skal kunden vide det. Den nye release kan indeholde nye funktioner, som ingen har testet, og ændringer, der påvirker dele af produktet, som var i orden ved den oprindelige test. Retestbeviset kan derfor sige, at bestemte fund er lukket i en bestemt version. Det kan ikke sige, at hele versionen er testet. → Retestbevis til kunden

Er releasen stor, eller berører den den samme del af produktet som fundene, kan det være værd at udvide retesten med en kort gennemgang af det nye. Det er en vurdering, I træffer med testeren ud fra, hvor meget der er ændret. → Ændringer, der kræver en ny test

Planlæg retesten ind i releaseplanen

Det er lettest at få retesten til at passe, når den er tænkt ind fra starten. Aftal med testeren, hvornår I forventer, at rettelserne er ude, og om retesten skal ske i staging eller produktion. Aftal også, hvad der sker, hvis en release bliver forsinket, så retesten ikke ender med at blive aflyst eller udført på en forkert version.

Nogle fund kan rettes i en mindre hotfix-release, mens andre kræver et større stykke arbejde, der først kommer med i en senere version. Så kan retesten deles op, eller I kan vente til alle alvorlige fund er rettet. Det første giver hurtigere dokumentation for de vigtigste fund. Det andet giver ét samlet bevis. Hvilken vej der passer, afhænger af, hvad kunderne venter på. En kunde, der har stillet krav om dokumentation før et salg, kan foretrække et hurtigt bevis for de alvorlige fund frem for et komplet bevis senere. → Fund i backloggen

Datoer og versioner i dokumentationen

Kunderne skal kunne se, hvad der blev testet hvornår. Det gælder i særlig grad, når der er en oprindelig test og en retest i en anden version. Skriv både versionen og datoen for den oprindelige test og for retesten, og skriv, hvilke fund retesten omfattede. → Version og testdatoer

Fund, der ikke blev efterprøvet, eller som ikke var rettet ved retesten, skal fremgå som åbne. Det er bedre, at kunden ser det i dokumentationen, end at de opdager det ved at spørge. → Åbne fund i rapporten

Kunder på en ældre version

Har I kunder, der kører en ældre version, eller installationer hos kunder, som ikke opdateres samtidig, er rettelsen ikke nået ud til dem, selv om retesten bekræfter, at den virker. Den del skal I selv kunne forklare: hvilke kunder har rettelsen, og hvad gør I for dem, der ikke har. → En gammel version, der stadig har kunder

Den generelle side af retesten, set fra en virksomhed, der har fået testet egne systemer, er beskrevet på penetrationtest.dk.

Et tænkt eksempel

Et softwarehus får en rapport med to alvorlige fund og en håndfuld mindre. Det ene alvorlige fund kan rettes hurtigt og kommer ud i en lille release ugen efter. Det andet kræver, at en del af rettighedsstyringen bygges om, og kommer først med i den næste store release to måneder senere sammen med et nyt rapportmodul.

Softwarehuset aftaler to retest med testeren. Den første efterprøver det hurtige fund i produktionen dagen efter udrulning. Den anden efterprøver det andet alvorlige fund og de mindre fund, der er nået at blive rettet. Fordi releasen også rummer det nye rapportmodul, som bruger den ombyggede rettighedsstyring, beder softwarehuset testeren om at kigge kort på modulets roller samtidig.

Kunden, der ventede på dokumentationen, får først et kort brev om det første fund og senere et samlet retestbevis med begge versioner og datoer. Det nye modul står som en særskilt, afgrænset gennemgang og ikke som en del af retesten.

Det skal I lade være med

Retteste i udviklingsmiljøet og kalde det rettet hos kunderne · rettelsen er først rettet, når den er ude.
Lade retestbeviset ligne en ny test · det dækker kun de efterprøvede fund.
Glemme versionen i dokumentationen · kunden skal kunne se, hvad der blev testet.
Udskyde retesten, til ingen husker fundene · jo længere tid, jo flere ændringer at tage højde for.
Skjule fund, der ikke nåede med · de skal stå som åbne.
Overse kunder på ældre versioner · de har ikke fået rettelsen, selv om den virker.

Hvad kan og ikke kan konkluderes

En retest kan bekræfte, at bestemte fund ikke længere kan udnyttes i en bestemt version på et bestemt tidspunkt. Den kan ikke bekræfte, at resten af releasen er uden svagheder, og den siger intet om versioner, der ikke blev efterprøvet.

Tjekliste til retesten i en ny release

☐ Er det aftalt, i hvilket miljø og hvilken version retesten sker?
☐ Er retesten lagt ind i releaseplanen?
☐ Er det vurderet, om nye ændringer i releasen kræver mere end en retest?
☐ Fremgår version og dato for både test og retest?
☐ Står fund, der ikke blev efterprøvet eller rettet, som åbne?
☐ Ved I, hvilke kunder der endnu ikke har rettelsen?

Kilder

NCSC (UK): Penetration testing: en penetrationstest siger noget om forholdene på testtidspunktet, og en planlagt test erstatter ikke den løbende sikkerhedstest af systemet.

Senest gennemgået: oktober 2026.