Mindre kunder kan købe på funktioner og pris, mens den første store erhvervskunde kommer med en indkøbsafdeling, en sikkerhedsfunktion og et krav om dokumentation. Hvornår produktet skal testes, afhænger af tre ting: hvornår i salget kravet bliver afgørende, hvor færdigt produktet er, og hvor lang tid I skal bruge på at håndtere det, testen finder.
Det korte svar er: test, når den version, kunden skal bruge, er stabil nok til at blive vurderet, og så tidligt, at der er tid til rettelser, før kunden skal se resultatet. I praksis betyder det tit, at testen planlægges, mens salget stadig er i dialog, og ikke først når kontrakten ligger klar.
Et nyt slags spørgsmål i salget
Hos de første kunder har sikkerhed måske været et punkt på et møde, hvor en udvikler fortalte om login og backup. Den store kunde stiller spørgsmålet anderledes. Der kommer et skema, et bilag til kontrakten eller en leverandørpolitik, og svarene skal kunne dokumenteres.
For softwarehuset kan det være første gang, nogen udefra skal se på produktet med sikkerhedsbriller. Det giver både en mulighed og en risiko. Muligheden er, at testen bliver et fast fundament for de næste salg. Risikoen er, at den bliver presset ind på et tidspunkt, hvor ingen har tid til at handle på resultatet. → Startup uden sikkerhedsfunktion
Hvornår kravet bliver afgørende
Spørg tidligt i salget, hvornår kunden skal bruge dokumentationen. Nogle kunder vil se den, før de går i gang med en pilot. Andre kræver den først før drift, eller før de lægger rigtige data i produktet. Det er tre forskellige datoer, og de giver tre forskellige planer.
Hvis kunden kan acceptere en plan med dato i stedet for en færdig rapport ved underskrift, får I mere luft. Spørg, om det er muligt, og få aftalen skrevet ind. Uden den aftale risikerer I, at salget venter på et dokument, der ikke findes endnu. → Aftalen venter på en pentestrapport
Tre placeringer af testen
- Før salget går i gang · I tester på eget initiativ og har en rapport klar, når kravet kommer. Det kræver, at I tør bruge tid og penge, før kunden er sikker.
- Under forhandlingen · Testen bestilles, når det står klart, at kunden er seriøs. Det giver en kort tidsplan, men en rapport, der passer til netop den kundes ønsker.
- Før kunden går i drift · Kunden underskriver med et forbehold, og testen gennemføres, før rigtige data lægges ind. Det kræver, at forbeholdet er tydeligt beskrevet.
Ingen af placeringerne er rigtig for alle. Valget afhænger af, hvor mange lignende kunder der er i pipelinen, hvor sikkert salget er, og hvor meget af teamets tid I kan undvære i den periode. Har I flere store kunder på vej, taler det for at teste uden at vente på den første. → At vente, til kunden spørger
Hvad skal være klar i produktet først
En test giver mest, når den rammer en version, der ligner det, kunden kommer til at bruge. Hvis kernefunktionerne stadig ændres hver uge, beskriver rapporten et produkt, der snart ikke findes.
Se især på de dele, der handler om adgang og adskillelse: login, roller, kundernes adskillelse fra hinanden og de administrative funktioner, jeres egne medarbejdere bruger. Er de på plads, kan testen sige noget, der holder ud over næste release. Er de under ombygning, kan det betale sig at vente på den nye model. → Scope for et SaaS-produkt
Sørg også for et miljø, hvor testen kan foregå uden at ramme rigtige kunder, og for testkonti i de roller, kunden får. Den forberedelse tager tid i et lille team og bør med i planen. Tænk også på, hvem der skal være til rådighed for testeren under forløbet. Hvis den eneste udvikler, der kender rollemodellen, er på ferie i testugen, går der tid tabt med spørgsmål, som ingen kan svare på.
Første test af et produkt kan finde noget
Når et produkt testes første gang, er det ikke usædvanligt, at der kommer fund, som ingen i teamet havde forudset. Det er en del af grunden til at teste og ikke et tegn på, at noget er gået galt. Men det betyder, at planen skal have plads til at vurdere fundene, rette de vigtigste og eventuelt få dem efterprøvet.
Beslut på forhånd, hvem der prioriterer fundene, og hvordan de kommer ind i udviklernes arbejde. Ellers ender de alvorlige fund i samme kø som de næste funktioner, kunden også venter på. → Fund i backloggen
Kunden som en del af planen
Den store kunde kan være en samarbejdspartner i planlægningen. Fortæl, at det er første eksterne test af produktet, hvornår den ligger, og hvad kunden får at se bagefter. En åben plan er ofte lettere for kunden at arbejde med end et hastigt bestilt dokument. Spørg samtidig, om kunden har særlige ønsker til testen, for eksempel bestemte roller eller en integration til kundens egne systemer. Det er lettere at få dem med nu end at bestille en ekstra test senere.
Pas på med at love, at testen bliver gentaget med et fast interval, før I ved, om det kan bæres. Det løfte følger med ind i kontrakten. Generelt om den første test af et system kan I læse på penetrationtest.dk.
Det skal I lade være med
- At teste en version, der står foran en ombygning · Rapporten bliver forældet, før kunden har læst den.
- At lægge testen lige før underskriften · Der er ingen tid til at rette det, testen finder.
- At glemme miljø og testkonti · Forberedelsen er en del af tidsplanen.
- At love faste intervaller for tidligt · Et løfte til den første store kunde bliver let standard for alle.
- At lade fundene konkurrere med nye funktioner uden en beslutning · Nogen skal prioritere.
Hvad kan og ikke kan konkluderes
En test af produktet før den første store kunde kan give jer et dokumenteret udgangspunkt og vise kunden, hvordan I håndterer resultatet. Den kan danne grundlag for svar til de næste kunder, så længe produktet ikke har ændret sig væsentligt.
Den kan ikke vise, at produktet er klar til alle kunders krav. Hver ny kunde kan stille spørgsmål, som den første test ikke dækkede.
Tjekliste før den første store kunde
- ☐ Ved I, hvornår kunden skal bruge dokumentationen?
- ☐ Er det afklaret, om en plan med dato kan accepteres?
- ☐ Er login, roller og adskillelse stabile i den version, der testes?
- ☐ Er der et testmiljø og testkonti i kundens roller?
- ☐ Har planen plads til rettelser og efterprøvning?
- ☐ Er det besluttet, hvem der prioriterer fundene?
- ☐ Har I undgået at love faste intervaller, I ikke har besluttet?
Kilder
- CREST: indkøbs- og implementeringsvejledninger: vejledninger om indkøb og planlægning af penetrationstest.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler om pentestrapporten
Læs også: Lanceringsdato og testvindue · Få udviklere, mange kundekrav
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest af SaaS hos Nielco IT