Hyppige udrulninger: hvilken version skal testes?

Når et produkt udrulles hver uge eller hver dag, er der ikke én oplagt version at teste: der er den, kunderne bruger i dag, den, der bliver klar i næste release, og den, udviklerne arbejder på lige nu. Det rigtige valg er som regel den version, kunderne vil bruge i det meste af den periode, rapporten skal dække, og ikke nødvendigvis den, der er nyest på testdagen.

Valget betyder noget, fordi kunderne læser rapporten som en beskrivelse af det produkt, de har. Er der for stor afstand mellem den testede version og den, de bruger, mister rapporten værdi i salget.

De versioner, I kan vælge imellem

Et softwarehus med hyppige udrulninger kan have tre kandidater:

Produktionen, som den er · det, kunderne bruger på testdagen. Rapporten passer til nuet, men forældes hurtigt, hvis der er større ændringer på vej.
Den kommende release · en version, der er færdig og venter på at blive udrullet. Rapporten passer til det, kunderne snart får, men testen skal ske i et andet miljø end produktionen.
Udviklingsgrenen · den nyeste kode. Den er ikke altid stabil nok til en test, der skal bruges over for kunder.

Den tredje er normalt ikke et godt valg til en rapport, kunderne skal se. Den kan være relevant til en tidlig, afgrænset test af en ny funktion, men det er en anden slags test med et andet formål. → Penetrationstest af en ny funktion

Kig fremad, ikke kun på testdagen

En rapport bruges i måneder efter testen. Hvis en større ændring er planlagt kort efter testen, vil rapporten i det meste af sin levetid beskrive en version, kunderne ikke længere bruger. Så kan det være bedre at vente med testen eller at teste den kommende release.

Omvendt bør testen ikke udskydes, hver gang der er noget nyt på vej. Et produkt i løbende udvikling har altid noget på vej. Kriteriet er, om det, der er på vej, ændrer det, testen skal undersøge: login, roller, adskillelsen mellem kunderne og vejene ind. Er det kun brugerflade og rapporter, kan I teste produktionen, som den er.

Se også på kalenderen hos kunderne. Hvis flere store kunder fornyer deres aftaler på samme tid af året, eller hvis en kunde har bedt om en ny rapport til en bestemt dato, bør den testede version være den, de vil bruge på det tidspunkt. Det er en grund mere til, at produktejeren og de kundeansvarlige er med, når versionen vælges, og ikke kun udviklerne og testeren. → Et årshjul for sikkerhedstest → Ændringer, der kræver en ny test

Miljøet skal passe til versionen

Vælger I den kommende release, skal den testes et sted, hvor den ligner det, kunderne vil få. NIST’s ramme for sikker softwareudvikling, SSDF, anbefaler at tage højde for den infrastruktur og teknologi, softwaren skal bruges med i produktionen, når test planlægges. For et SaaS-produkt betyder det, at testmiljøet bør have samme opsætning af login, rettigheder og adskillelse som produktionen. → Et staging-miljø til testen

Vælger I produktionen, er miljøet givet, men så skal I tage hensyn til de kunder, der bruger den samtidig. Det kræver aftaler om testkonti, testdata og hvilke handlinger testeren må udføre, og ofte en eller flere separate testlejere, som ingen rigtige kunder har adgang til.

Når kunderne ikke er på samme version

Mange SaaS-produkter har alle kunder på samme version. Men nogle har kunder på forskellige udgaver, fx fordi store kunder får opdateringer senere, eller fordi nogle funktioner er slået til for nogle kunder og ikke for andre. Så er spørgsmålet ikke kun, hvilken version der testes, men hvilken kundes oplevelse rapporten beskriver.

Vælg den version, de fleste kunder er på, eller den, der snart bliver standard, og skriv i rapporten, hvilke udgaver der ikke var med. Er der funktioner, der kun er slået til for nogle kunder, skal det besluttes, om de er med i testen. → Funktioner for nogle kunder

Har I en ældre version, der stadig kører hos nogle kunder, er det en sag for sig, hvad I tester og lover for den. → En gammel version med kunder

Versionen skal kunne genfindes

Uanset valget skal rapporten kunne knyttes til præcis den version, der blev testet. Det kræver, at versionen har et navn, I bruger internt, og at navnet står i rapporten. Hvis I ikke bruger versionsnumre, kan datoen for udrulningen eller en betegnelse for releasen gøre samme nytte. Det vigtige er, at I om et halvt år kan sige, hvilken kode testeren mødte, og hvilke ændringer der er kommet siden. → Version og testdatoer

Hvis der udrulles i testperioden, er det også et spørgsmål om, hvordan ændringerne håndteres, mens testen står på. Det er beskrevet for sig. → Kodefrys under testen

Et tænkt eksempel

Et softwarehus med et system til planlægning af hjemmepleje udruller hver uge. Den årlige test skal begynde om en måned, og om seks uger kommer en release med en ny model for adgang på tværs af kommunale distrikter. Hvis testen dækker produktionen, som den er, beskriver rapporten den gamle model, og kommunerne vil spørge til den nye. Softwarehuset beslutter at teste den kommende release i et testmiljø med samme opsætning som produktionen. Testen rykkes en smule, så den nye adgangsmodel er færdig. Rapporten angiver releasens betegnelse og den dato, den blev udrullet til kunderne, så kommunerne kan se, at rapporten beskriver det system, de faktisk bruger.

Det skal I lade være med

Teste udviklingsgrenen til en rapport til kunderne · den er ikke altid stabil nok.
Teste produktionen lige før en stor ændring · så forældes rapporten med det samme.
Udskyde testen, hver gang der er noget nyt på vej · der er altid noget på vej.
Glemme at skrive versionen i rapporten · så kan den ikke kobles til produktet.
Teste den kommende release i et miljø, der ikke ligner produktionen · så beskriver rapporten et andet produkt.

Hvad kan og ikke kan konkluderes

Rapporten beskriver den version og det miljø, testeren arbejdede i. Er det den kommende release, gælder resultatet for den, så længe den udrulles uden væsentlige ændringer. Det siger ikke noget om senere ændringer eller om versioner, som nogle kunder stadig bruger, men som ikke var med.

Tjekliste til valg af version

☐ Er det vurderet, om større ændringer er på vej kort efter testen?
☐ Er der valgt mellem produktionen og den kommende release med en begrundelse?
☐ Ligner testmiljøet produktionen i det, testen skal undersøge?
☐ Er det besluttet, hvilke kundeversioner og funktioner der er med?
☐ Står versionens betegnelse i rapporten?

Kilder

NIST SP 800-218, Secure Software Development Framework, PW.8.2, eksempel 4: tag højde for den infrastruktur og teknologi, softwaren skal bruges med i produktionen, når test planlægges.

Senest gennemgået: oktober 2026.