Udviklerne og testeren: skal de tale sammen undervejs?

Under en pentest af et softwareprodukt opstår der spørgsmål, som kun udviklerne kan svare på: hvordan en funktion er tænkt, hvorfor en side opfører sig mærkeligt, eller om en fejl skyldes testmiljøet. Kontakt mellem udviklere og tester er derfor normalt en fordel, så længe den foregår gennem et aftalt kontaktpunkt, og så længe rapporten stadig beskriver det produkt, kunderne bruger, og ikke et produkt, der blev rettet til undervejs.

Spørgsmålet er altså ikke, om de skal tale sammen, men hvordan, om hvad, og hvad der skal stå i rapporten om det.

Hvorfor kontakten gør testen bedre

En tester, der står helt alene med produktet, bruger tid på at gætte. Hvad er forskellen på de to administratorroller? Er det meningen, at en bruger kan se andre brugere i samme organisation? Er den fejlside et tegn på en svaghed, eller er testmiljøet bare ustabilt? Hvert svar fra en udvikler kan spare timer, og de timer kan bruges på det, kunderne faktisk interesserer sig for.

Den britiske NCSC anbefaler, at der under testen er en teknisk kontaktperson til rådighed hele tiden, som kan nås med kort varsel, så testeren kan melde alvorlige fund og få løst forhindringer. NCSC anbefaler også, at personer med teknisk kendskab til systemet er med, når testen afgrænses. For et softwarehus er det typisk en udvikler eller en teknisk ansvarlig for produktet.

Kontakten handler også om sikkerhed i selve testen. Opdager testeren noget, der kan påvirke kunderne i produktionen, skal der være en person, der kan tage imod det med det samme. → Kontaktpunkt for sikkerhed

Ét kontaktpunkt, ikke hele teamet

Hvis alle udviklere kan skrive til testeren, bliver det svært at holde styr på, hvad der er sagt, og hvad der er ændret. Et fast kontaktpunkt løser det. Det kan være en udvikler med bred viden om produktet eller den tekniske ansvarlige. Kontaktpunktet henter svar hos de andre, når det er nødvendigt.

Aftal på forhånd:

Hvem kontaktpunktet er · og en stedfortræder, hvis testen strækker sig over flere uger.
Hvordan der kommunikeres · en fast kanal, så spørgsmål og svar kan genfindes.
Hvornår kontaktpunktet kan nås · i testens arbejdstid og ved alvorlige fund også uden for.
Hvad der kræver eskalation · fx et fund, der rammer data hos rigtige kunder.

Kontaktpunktet er også den, der kender planen for udrulninger under testen. → Kodefrys under testen

Hvad udviklerne bør svare på

Spørgsmål fra testeren kan handle om, hvordan produktet er tænkt. Dem bør udviklerne svare på åbent: forventet adfærd, rollernes formål, hvilke data der hører til hvilken kunde, og hvordan integrationer er sat op. Svarene gør testen mere præcis, og de ændrer ikke på, hvad testeren kan finde.

Andre spørgsmål kræver mere omtanke. Hvis testeren spørger, om en bestemt funktion kontrollerer rettigheder, kan et svar i den ene retning få testeren til at springe den over. Lad hellere testeren undersøge det selv. Udviklerne kan fortælle, hvordan noget er ment, men det er testerens opgave at finde ud af, om det virker sådan.

Kunderne har en interesse i netop den grænse. Når en kunde læser rapporten, går kunden ud fra, at testeren har dannet sig sin egen mening om produktet. Hvis rapporten eller metodeafsnittet nævner, at testeren havde adgang til udviklerne, er det ikke nødvendigvis et problem for kunden. Det bliver først et problem, hvis kontakten har ført til, at dele af produktet ikke blev undersøgt, uden at det fremgår. Det er derfor en god idé, at afgrænsningen og eventuelle ændringer i den står skrevet, og at de ikke aftales mundtligt mellem en udvikler og testeren midt i forløbet. → Kildekode til testeren

Rettelser under testen og rapportens troværdighed

Den største risiko ved tæt kontakt er, at udviklerne retter fund, mens testen står på. Det er naturligt at ville lukke en alvorlig svaghed med det samme, og ved fund, der kan ramme kunderne i produktionen, kan det være den rigtige beslutning. Men det skal fremgå af rapporten.

Rettes et fund undervejs, bør rapporten stadig nævne det, og samtidig sige, at det blev rettet i testperioden, og om testeren har efterprøvet rettelsen. Ellers ser kunderne en rapport, der er pænere end produktet var, og det er ikke det, en rapport skal bruges til. Kunder, der senere opdager, at fund er fjernet fra rapporten, får grund til at tvivle på resten. → Åbne fund i rapporten

Aftal derfor med testeren, før testen starter, hvordan rettelser i testperioden håndteres og beskrives. Det er også en del af aftalen om, hvilken version der testes. → Hyppige udrulninger: hvilken version?

Afslutningen er en samtale for sig

Når testen er slut, er en gennemgang af fundene med udviklerne ofte den mest værdifulde time i hele forløbet. Her kan testeren forklare, hvad fundene betyder, og udviklerne kan stille spørgsmål til, hvordan de kan rettes. Gennemgangen er ikke en forhandling om alvorlighed. Er I uenige i en vurdering, kan det noteres, men det er testerens vurdering, der står i rapporten. → Forklar fundene til kunden

Et tænkt eksempel: et softwarehus med et system til håndtering af medlemskaber får under testen et spørgsmål om, hvorfor foreningsadministratorer kan se kontingentoplysninger for andre foreninger i samme forbund. Kontaktpunktet bekræfter, at det kun skal gælde forbundets egne administratorer. Testeren undersøger det nærmere og finder en svaghed i rollemodellen. Den meldes med det samme, softwarehuset beslutter at rette den i testperioden, og rapporten beskriver både fundet, rettelsen og testerens efterprøvning.

Det skal I lade være med

Lade hele teamet tale med testeren · brug et fast kontaktpunkt.
Fortælle testeren, hvad der ikke behøver at blive testet · lad afgrænsningen styre det.
Rette fund i stilhed · rettelser i testperioden skal stå i rapporten.
Forhandle om alvorlighed i afslutningen · uenighed noteres, den ændrer ikke vurderingen.
Lade testeren vente dagevis på svar · det koster testtid, som kunne være brugt på produktet.

Hvad kan og ikke kan konkluderes

God kontakt mellem udviklere og tester giver en mere præcis test, men den ændrer ikke på, hvad rapporten kan bruges til. Rapporten beskriver det, testeren fandt i den testede version. Rettelser undervejs gør produktet bedre, men de skal fremgå, så kunderne kan se, hvordan produktet var, da testen begyndte.

Tjekliste før testen

☐ Er der udpeget et kontaktpunkt og en stedfortræder?
☐ Er der aftalt en fast kanal til spørgsmål og svar?
☐ Ved kontaktpunktet, hvad der skal eskaleres, og til hvem?
☐ Er det aftalt, hvordan rettelser i testperioden beskrives i rapporten?
☐ Er der sat tid af til en gennemgang af fundene med udviklerne?

Kilder

NCSC (UK): Penetration testing: en teknisk kontaktperson bør være til rådighed hele tiden under testen, og personer med teknisk kendskab til systemet bør deltage i afgrænsningen.

Senest gennemgået: oktober 2026.