Få udviklere, mange kundekrav: sådan planlægger I testen

I et softwarehus med en håndfuld udviklere er det ikke nødvendigvis testen, der er den knappe ressource. Det er tiden til at forberede den, rette fundene og svare kunderne bagefter. Når flere kunder stiller hver deres krav, kan den tid forsvinde i parallelle opgaver. Planen hviler på tre valg: at I finder det fælles i kravene og opfylder det med én test, at tiden til rettelser bliver sat af før testen, og at dokumentationen bliver lavet én gang og brugt mange gange.

Ressourcen er udviklertiden, ikke testen

En penetrationstest af et SaaS-produkt kræver arbejde hos jer før, under og efter. Før testen skal der oprettes testkunder og konti, et testmiljø skal være klar, og omfanget skal beskrives. Under testen skal nogen kunne svare på spørgsmål. Efter testen skal fundene vurderes, rettes og efterprøves, og kunderne skal have deres dokumentation.

I et lille team er det de samme personer, der også bygger nye funktioner og retter fejl for kunderne. Derfor bør planen starte med et ærligt spørgsmål: hvor mange udviklerdage har vi realistisk til testen, og hvornår på året har vi dem? → Lanceringsdato og testvindue

Find fællesnævneren i kravene

Læg kundernes krav ved siden af hinanden. De ser forskellige ud, men kan vise sig at handle om det samme: en uafhængig test af det produkt, kunden bruger, inden for en vis tid, med fund rettet efter alvorlighed. Forskellene kan ligge i detaljer som rapportens alder, krav til testerens kvalifikationer eller ønsket om at se hele rapporten.

Skriv fællesnævneren ned som jeres egen standard for test. Den bliver grundlaget for den test, I bestiller, og for de svar, I giver. Krav, der går ud over standarden, tager I stilling til hver for sig: kan de opfyldes uden en ekstra test, kan de forhandles, eller er de så vigtige, at standarden skal ændres? → Flere kunder stiller forskellige krav · → Forhandling af sikkerhedskrav

Én test, der kan bruges af mange kunder

Bestil testen, så rapporten kan bruges over for alle kunder, og ikke kun den, der spurgte først. Det betyder et omfang, der dækker de dele af produktet, kunderne faktisk bruger, en tydelig beskrivelse af version og datoer og en form, der kan udleveres som resumé eller kundeversion.

Placer testen, så rapporten er aktuel, når flest kunder har brug for den. Har tre kunder fornyelse i foråret, er en test i vinter mere nyttig end en test i sommer. → Bestil til kundebrug

Sig nej til parallelle test, hvis I kan. Ønsker en kunde at teste selv, kan en henvisning til jeres egen test og et tilbud om en gennemgang spare jer for at forberede endnu en test i samme kvartal. Insisterer kunden, så lad det ske efter jeres faste regler. Hver ekstra test betyder nye testkonti, nye spørgsmål fra en tester og nye fund at vurdere, og det er tid, der går fra den plan, alle kunder har gavn af. → Kunden vil selv teste

Planlæg tiden til rettelser først

En fejl, der er let at begå i et lille team, er at bestille testen uden at sætte tid af til det, der kommer bagefter. Så står rapporten med åbne fund, mens udviklerne er bundet til en lancering, og kunderne får en rapport, der viser problemer uden en plan.

Sæt derfor et antal dage af i ugerne efter testen, før testen bestilles. Aftal på forhånd, hvilke alvorligheder der rettes med det samme, og hvilke der går i backloggen med en dato. Planlæg retesten med det samme, så den ligger, før rapporten skal bruges. → Fund i backloggen

Et tænkt eksempel: Et softwarehus med fire udviklere og et system til tilsyn på plejehjem har fået krav fra fem kunder. Kravene samles i én standard: en årlig test af webapplikation og API, høje fund rettet inden for en aftalt periode og et resumé til kunderne. Testen lægges i januar, to uger i februar sættes af til rettelser, og retesten ligger i marts, før tre kunder har fornyelse.

Spar tid på dokumentation og skemaer

Kundernes spørgeskemaer kan tage mere tid end testen. Lav et svarbibliotek med godkendte svar om test, rettelser og udvikling, og opdater det efter hver test. Saml de dokumenter, kunderne beder om, i en fast pakke, så de kan sendes uden at blive skrevet om. → Svarbibliotek · → Sikkerhedspakken

Automatiske kontroller i udviklingen kan fange en del fejl mellem testene og give jer noget at svare med, men de erstatter ikke den manuelle test, kunderne spørger efter. Den britiske NCSC beskriver penetrationstest som en måde at få sikkerhed for, at processerne for håndtering af sårbarheder virker, ikke som den primære måde at finde sårbarheder på. For et lille team betyder det, at den løbende hygiejne i udviklingen og den årlige test støtter hinanden. Jo færre kendte fejl der ligger, når testeren starter, jo mere af testtiden går til det, kun en manuel test kan finde, og jo færre fund skal rettes bagefter.

Hvad der påvirker omfanget

Når I skal bede om pris og tilbud, er det disse forhold, der afgør omfanget: hvor mange moduler og roller der skal med, om API og integrationer indgår, hvor mange testkunder der skal bruges for at afprøve adskillelsen, om retest skal med, og hvilken form rapporten skal have. Har I samlet kravene i én standard, er beskrivelsen hurtig at lave. Send den samme beskrivelse til de testere, I spørger, så tilbuddene kan sammenlignes på det samme grundlag. Oplys også, hvornår testen skal ligge, og hvornår rapporten senest skal bruges, så testeren kan sige, om tidsplanen er realistisk.

Det skal I lade være med

Bestille en test pr. kunde · find fællesnævneren og test én gang.
Bestille uden tid til rettelser · en rapport med åbne fund og ingen plan hjælper ingen.
Udvide omfanget til alt · test det, kunderne bruger.
Skrive skemasvar fra bunden hver gang · brug et godkendt bibliotek.
Lade den mest højlydte kunde bestemme tidspunktet · placer testen efter, hvornår flest har brug for den.

Hvad kan og ikke kan konkluderes

En samlet plan gør det muligt for et lille team at opfylde flere kunders krav med én test og én rapport. Den kan ikke få særkrav til at forsvinde, og den kan ikke skabe udviklertid, der ikke findes. Nogle kunder vil stadig kræve noget ekstra, og det skal vurderes for sig.

Tjekliste til planen

☐ Er kundernes krav samlet og sammenlignet?
☐ Er fællesnævneren skrevet ned som jeres egen standard?
☐ Ligger testen, så rapporten er aktuel, når kunderne skal bruge den?
☐ Er udviklertid til rettelser sat af før bestillingen?
☐ Er retesten planlagt?
☐ Findes der et svarbibliotek og en fast pakke til kunderne?

Kilder

NCSC: Penetration testing: penetrationstest som sikkerhed for, at håndteringen af sårbarheder virker, ikke som primær metode til at finde sårbarheder.

Senest gennemgået: oktober 2026.