Ny kundeportal: hvornår skal penetrationstesten ligge?

I mange portalprojekter dukker penetrationstesten først op, når udviklingen er færdig og budgettet næsten brugt. Testen bør i stedet være en planlagt aktivitet i projektet, placeret efter de væsentlige funktioner er bygget og før portalen åbnes for kunderne, med tid til rettelser imellem.

Det præcise tidspunkt afhænger af, hvordan projektet er skruet sammen. Et projekt med én samlet udgivelse har ét naturligt vindue. Et projekt, hvor portalen udgives i etaper, kan have brug for en første test og senere afgrænsede test af nye dele. Indholdet af selve testen, altså roller, funktioner og integrationer, er beskrevet i → Penetrationstest af webapplikationer.

Skriv testen ind i projektplanen fra start

Når testen står i projektplanen fra begyndelsen, bliver den en del af tidsplanen, budgettet og aftalen med udviklingsleverandøren. Når den tilføjes til sidst, konkurrerer den med lanceringsdatoen, og det er sjældent testen, der vinder.

Placér tre aktiviteter i planen: selve testen, en periode til rettelser og en efterprøvning af de vigtigste rettelser. Mellem dem bør der være plads til det uventede. Et enkelt alvorligt fund i adskillelsen mellem kunders oplysninger kan kræve ændringer flere steder i portalen.

Planen bør også vise forberedelsen. Testkonti for de forskellige roller, adgang til det rigtige miljø, en kontaktperson hos leverandøren og en beslutning om tidsrum skal være klar, før testeren begynder. → Før penetrationstesten

Hvor lang tid hver aktivitet tager, kan ikke siges generelt. Det afhænger af portalens størrelse, antallet af roller og integrationer og testens dybde. → Hvor lang tid tager en penetrationstest?

For tidligt: der er ikke noget at teste

En test, der ligger for tidligt, rammer en portal, hvor vigtige dele mangler. Rollerne er måske ikke færdige, integrationen til ERP-systemet er ikke koblet på, og den måde kunder logger ind på, er stadig til diskussion. Resultatet bliver en vurdering af en mellemtilstand, som ikke længere findes, når portalen åbner.

Et tegn på, at det er for tidligt, er, når udviklingsleverandøren ikke kan sige, hvilke funktioner der er færdige. Et andet er, når testkonti for alle roller endnu ikke kan oprettes. I den situation er det bedre at vente eller at begrænse testen til de dele, der faktisk ligger fast.

Tidlige sikkerhedsaktiviteter har stadig værdi. En gennemgang af arkitekturen eller af adskillelsen mellem kunder kan finde designfejl, mens de er billige at ændre. Det er bare en anden opgave end penetrationstesten af den færdige portal.

For sent: rettelserne rammer lanceringen

En test, der ligger for sent, giver ingen plads til at rette. Så står projektet med et valg mellem at udskyde åbningen eller åbne med kendte fejl. Begge dele er dyrere end at have planlagt tid til rettelser fra begyndelsen. → Testen ligger lige før lanceringen uden tid til at rette

Et tegn på, at det er for sent, er, når der ikke er nogen udviklere tilbage på projektet efter testperioden. Et andet er, når lanceringsdatoen allerede er meldt ud til kunderne. Sørg for, at udviklingsleverandøren har kapacitet reserveret til rettelser i perioden efter testen.

Et tredje tegn er, når testen skal foregå samtidig med kundernes accepttest eller med flytningen af data fra det gamle system. Så deler testeren miljø, kontaktpersoner og opmærksomhed med andre aktiviteter, og både resultatet og tidsplanen bliver sværere at styre. Læg testen, så den har sit eget vindue.

Portaler, der udgives i etaper

Mange portaler åbner med en grundpakke og får nye funktioner løbende. Her er spørgsmålet ikke kun, hvornår den første test skal ligge, men også, hvornår en ny del er væsentlig nok til at blive testet.

En første test bør dække de dele, der er åbne ved den første udgivelse, med særlig vægt på login, roller og adskillelse mellem kunder. Senere test kan afgrænses til nye funktioner, nye roller eller nye integrationer. Det kræver, at nogen holder øje med, hvad hver udgivelse ændrer, og om ændringen berører det, den første test undersøgte. → Scope i en penetrationstest

Undgå at lade en etape gå i drift med en helt ny type data eller en ny gruppe af brugere uden at overveje en test. Når portalen eksempelvis åbner for kundernes egne medarbejdere med egne rettigheder, er det en ændring, der kan påvirke adskillelsen.

En enkel regel i projektet kan hjælpe. Lad hver udgivelsesbeskrivelse indeholde et kort punkt om sikkerhed: berører udgivelsen login, roller, kunders data eller forbindelser til andre systemer? Hvis svaret er ja, tager systemejeren stilling til, om der skal testes, før udgivelsen åbnes. Det kræver ikke en ny test hver gang, men det sikrer, at beslutningen bliver truffet bevidst og ikke glider ud, fordi ingen spurgte.

Hvem i projektet ejer testen?

Projektlederen bør eje planlægningen af testen, mens systemejeren tager stilling til resultatet. Den fordeling er vigtig, fordi projektet slutter, mens portalen fortsætter. Fund, der ikke rettes før lanceringen, skal overdrages til en ejer i driften med en klar plan. Udviklingsleverandøren står for rettelserne, men bør ikke selv bestille eller vurdere testen af sit eget arbejde.

Aftalen med udviklingsleverandøren bør derfor beskrive, at der gennemføres en uafhængig test, hvornår den ligger, og hvordan fund rettes. Hvem betaler for rettelser af fejl, der burde have været undgået, og hvem betaler for ændringer, der skyldes nye ønsker? Det er bedre at have svaret i kontrakten end at forhandle det, når rapporten ligger på bordet. → Hvem retter fundene?

Det skal I lade være med

At tilføje testen, når budgettet er brugt · Testen og rettelserne skal være planlagt og afsat fra start.
At teste en mellemtilstand · Vent, til roller, login og integrationer ligger fast.
At lægge testen uden rettetid bagefter · Fundene skal kunne rettes og efterprøves før åbningen.
At glemme nye etaper · En ny brugergruppe eller en ny type data kan kræve en ny test.
At lade leverandøren vurdere sit eget arbejde · Testen bør bestilles og vurderes af jer.
At udskyde aftalen om rettelser · Fordelingen af arbejde og betaling hører hjemme i kontrakten.

Hvad kan og ikke kan konkluderes

En test placeret på det rigtige tidspunkt kan vise, hvordan portalen står, når kunderne får adgang, og give tid til at rette det vigtigste først. Den giver projektet et dokumenteret grundlag for beslutningen om at åbne.

Den kan ikke dække etaper, der udgives senere, og den siger ikke noget om de ændringer, portalen gennemgår i drift. → Retest efter penetrationstest