Lanceringsdato og testvindue: undgå, at testen bremser releasen

I et softwarehus kan lanceringsdatoen være lovet til kunder, partnere eller salget, længe før nogen har tænkt på pentesten. Når testen så bliver bestilt, er der kun ét vindue tilbage: de sidste dage før lanceringen. Løsningen er at lade releaseplanen styre testen fra begyndelsen, så testvinduet, tiden til rettelser og en eventuel retest står i planen på samme måde som udvikling og kvalitetssikring.

En test, der er planlagt ind, bremser ikke nødvendigvis en release. Det er den test, der bliver presset ind til sidst, der gør.

Hvorfor testen ender i klemme

Pentesten har to egenskaber, der gør den svær at presse. Den kræver en version, der er færdig nok til at blive testet, og den giver fund, der skal rettes, før resultatet er brugbart. Begge dele tager tid, og ingen af dem kan begynde, før det foregående er gjort.

I en almindelig projektplan bliver det let til en kæde: udviklingen bliver forsinket, testen rykker, og tiden til rettelser forsvinder, fordi lanceringsdatoen står fast. Penetrationtest.dk beskriver den situation fra køberens side, når testen ligger lige før go live uden tid til rettelser. For et softwarehus er udfordringen en anden: releases kommer igen og igen, og testen skal passe ind i en rytme, ikke i et enkelt projekt. Se penetrationtest.dk.

Den britiske NCSC skriver i sin vejledning om sikker udvikling, at sikkerhedstest ikke bør stå i vejen for løbende levering. Det er et godt princip at planlægge efter: testen skal være en del af rytmen, ikke en bremse på den.

Regn baglæns fra lanceringen

Begynd med lanceringsdatoen og regn baglæns. Planen har fire trin, og hvert trin skal have sin egen tid:

Version klar til test · den del af produktet, der skal testes, er færdig nok til, at testen giver mening.
Testvinduet · den periode, testeren arbejder i, aftalt med testeren i god tid.
Rettelser · tid til at rette de fund, der skal være rettet før lanceringen.
Retest · efterprøvning af de vigtigste rettelser, hvis kunderne skal have et retestbevis ved lanceringen.

Trinnene kan overlappe lidt. Alvorlige fund kan blive meldt under testen og kan rettes, mens testeren arbejder videre. Men tiden til rettelser kan ikke fjernes helt. Et softwarehus med faste releases kan med fordel bruge den næste release efter testen som rettelsesrelease, så der altid er et kendt tidspunkt, hvor rettelserne når ud til kunderne. Hvor meget tid der skal afsættes, afhænger af produktet og af, hvor mange og hvor store fund I må forvente. → Penetrationstest af en ny funktion

Testen behøver ikke ligge lige før lanceringen

Mange softwarehuse tror, at testen skal ligge så tæt på lanceringen som muligt for at dække den endelige version. Det er sjældent nødvendigt. En test, der ligger tidligere, på en version, hvor det sikkerhedsmæssigt vigtige er færdigt, giver mere tid til rettelser. Ændringer efter testen kan vurderes og eventuelt testes afgrænset.

Det kræver, at I ved, hvilke dele af releasen der er vigtige for sikkerheden. Login, roller, adskillelsen mellem kunder og nye veje ind bør være færdige, når testen begynder. Brugerfladens udseende, tekster og rapporter kan ofte vente. → Ændringer, der kræver en ny test

Når lanceringen ikke kan flytte sig

Nogle datoer ligger fast. En kunde har en kontrakt med en startdato, en lovgivning træder i kraft, eller en messe er booket. Så skal I vælge, hvad der skal ofres, hvis tiden ikke slår til. Mulighederne er typisk:

Lancér i trin · slå den nye funktion til for få kunder eller uden de mest følsomme dele, og udvid, når testen og rettelserne er på plads.
Begræns testen · test det vigtigste grundigt i stedet for alt overfladisk, og test resten senere.
Lancér med kendte fund · kun efter en beslutning hos produktejeren og ledelsen, og med en plan for rettelserne.

Det sidste valg kræver ærlighed over for kunderne. Hvis de spørger, om funktionen var testet ved lanceringen, og der var åbne fund, skal svaret afspejle det. → Åbne fund i spørgeskemaet

Testvinduet er en aftale med testeren

En tester har andre opgaver, og et testvindue skal bookes. Når releaseplanen ændrer sig, skal testvinduet følge med, og det kræver, at testeren får besked i god tid. Aftal derfor fra starten, hvad der sker, hvis versionen ikke er klar på den aftalte dag: skal testen flyttes, eller skal den begynde på det, der er færdigt?

Aftal også, hvordan testeren melder alvorlige fund under testen, så udviklerne kan gå i gang med det samme. Det er en af de mest effektive måder at vinde tid på. → Udviklerne og testeren

Testens længde og forberedelse afhænger af produktets størrelse, af hvor meget der er nyt, og af om der skal være en retest før lanceringen. De forhold bestemmer omfanget og dermed → pris og tilbud. Skal testen bestilles med kort varsel, fordi planen er skredet, er hastesager hos Nielco IT mulige, men de koster ekstra.

Et tænkt eksempel

Et softwarehus med et system til bestilling af skolemad har lovet kommunerne en ny betalingsfunktion til skolestart. Produktejeren regner baglæns fra skolestart og lægger retesten først, derefter en periode til rettelser og forrest selve testvinduet, alle med en tidsramme, udviklerne og testeren har sagt god for. Betalingsflowet og rollerne for forældre og skoler skal være færdige før testen, mens kvitteringernes udseende og statistikken kan komme bagefter. Da udviklingen bliver forsinket, flyttes testvinduet, og tiden til rettelser skæres lidt ned, men retesten bevares, fordi kommunerne har bedt om et retestbevis. Den nye plan sendes samme dag til testeren, så vinduet kan flyttes, uden at der opstår et hul.

Det skal I lade være med

Planlægge releasen uden testen · så ender testen i de sidste dage.
Vente på den endelige version · test det sikkerhedsmæssigt vigtige, når det er færdigt.
Skære tiden til rettelser væk · så er testens fund kun til orientering.
Lancere med åbne alvorlige fund uden en beslutning · det skal være et valg, ikke et uheld.
Flytte testvinduet uden at sige det til testeren · så står I uden tester, når versionen er klar.

Hvad kan og ikke kan konkluderes

En test, der er planlagt ind i releasen, giver tid til at rette og efterprøve før lanceringen. Den dækker den version, der blev testet, og ikke ændringer efter testen. Lanceres der i trin eller med kendte fund, skal kunderne kunne se, hvad der var testet, og hvad der var åbent.

Tjekliste til releaseplanen

☐ Står testvinduet, rettelser og retest i releaseplanen?
☐ Er det klart, hvilke dele der skal være færdige før testen?
☐ Er testvinduet aftalt med testeren, og ved testeren, hvad der sker ved forsinkelse?
☐ Er der aftalt, hvordan alvorlige fund meldes under testen?
☐ Er det besluttet, hvad der ofres, hvis lanceringsdatoen ikke kan flytte sig?