Testdata i udvikling og staging: undgå kopier af rigtige kunder

Det korte svar

Opret et lille, versionsstyret sæt fiktive testdata, som dækker normale forløb, grænsetilfælde og forskellige roller. Lad hvert ikke-produktionsmiljø starte fra disse data. Hvis en konkret test ikke kan gennemføres uden produktionsdata, skal I dokumentere nødvendigheden, tage det mindst mulige udsnit, reducere identifikation før kopien forlader produktion og give testmiljøet passende adgang, logning, opdatering, overførsel og sletning.

Find alle steder hvor testdata allerede ligger

Begynd med et inventar. Problemet er sjældent kun én staging-database. En eksport kan være downloadet til en udviklercomputer, pakket som CI-artifact, indsat i en supportsag eller sendt til et AI-værktøj for at forklare en fejl. Hver kopi har sin egen adgang, levetid og leverandørkæde.

Registrér for hver kopi: formål, datatyper, miljø, leverandør, region, adgang, oprettelsesdato, slettefrist og ejer. Ukendte kopier er et fund – ikke dokumentation.

Vælg data efter den konkrete test

Realisme kommer ofte fra datasættets form og relationer, ikke fra rigtige personer. Beskriv først hvad testen skal bevise, og vælg derefter den mindst følsomme datakilde, der kan give et troværdigt svar.

Syntetiske data

Fiktive personer og hændelser uden én-til-én-kopi fra produktion. Brug dem som standard til udvikling og automatiske tests.

Anonymiserede data

Ingen må kunne identificeres, heller ikke ved kombination med andre rimeligt tilgængelige oplysninger. Det kræver en konkret vurdering.

Pseudonymiserede data

Direkte identifikatorer er erstattet, mens en nøgle eller anden information kan forbinde data med personen. Behandl dem fortsat som personoplysninger.

Produktionsdata

Brug kun når et dokumenteret testformål reelt kræver det. Databeskyttelsesreglerne og behovet for passende sikkerhed følger med kopien.

Datatilsynet fremhæver behandlingsgrundlag, dataminimering, sletning og passende sikkerhedsforanstaltninger, når personoplysninger bruges til test. Et testlabel gør ikke oplysningerne mindre virkelige.

Byg et lille datasæt der finder rigtige fejl

Et godt fixture-sæt er forståeligt, stabilt og let at nulstille. Gem generatoren eller seed-scriptet sammen med koden, så alle miljøer kan få samme kendte udgangspunkt uden en manuel databasekopi.

• Dæk roller og grænser: opret mindst to virksomheder, almindelige brugere, en administrator og en bruger uden adgang, så afslag kan testes.
• Bevar relationerne: lad ordrer, linjer, filer og betalingstilstande hænge sammen, og medtag bevidst poster uden valgfrie relationer.
• Medtag grænsetilfælde: tomme værdier, lange navne, danske tegn, store beløb, tidszoner, gamle datoer og de statusser, der er svære at nå gennem brugerfladen.
• Gør data tydeligt fiktive: brug navne som “Testkunde 0042” og reserverede domæner som example.com eller .test.
• Gør nulstilling sikker: seed kun det valgte ikke-produktionsmiljø, kræv en miljømarkør, og afvis kørsel mod produktionsprojekt, produktionsdatabase eller produktionskonto.

Når produktionsdata undtagelsesvis er nødvendige

En sjælden datakombination eller en migrering kan kræve mere realisme end syntetiske data giver. Gør undtagelsen tidsbegrænset og reproducerbar i stedet for at oprette en permanent, fuld produktionsklon.

1. 1. Beskriv testen og nødvendigheden: skriv hvad der skal bevises, hvorfor syntetiske eller anonymiserede data ikke er nok, og hvem der godkender brugen.
2. 2. Udvælg mindst muligt: begræns rækker, felter og tidsperiode. Udelad fritekst, filer, kontaktoplysninger og særlige kategorier, medmindre testen konkret kræver dem.
3. 3. Reducér identifikation tidligt: transformér data i eller tæt på det kontrollerede produktionsmiljø, før kopien sendes videre. Opbevar en eventuel koblingsnøgle separat og med smallere adgang.
4. 4. Beskyt miljøet efter risikoen: brug afgrænset adgang, MFA for privilegerede konti, krypteret overførsel, logning, sikkerhedsopdateringer og kontrollerede leverandører.
5. 5. Sæt automatisk udløb: giv miljø, eksport og artifacts en dato, og kontrollér bagefter at database, filer, logs, lokale kopier og backups følger den besluttede sletning.

Datatilsynet angiver, at de samme sikkerhedsforanstaltninger som udgangspunkt skal være etableret i testmiljøet, når de er passende i produktion – især for adgangsstyring, logning, sikker overførsel og patching. Den konkrete risikovurdering kan stille yderligere krav.

Stop testmiljøet fra at påvirke virkeligheden

Sikkert testindhold er ikke nok, hvis staging stadig kan sende mails til kunder, hæve penge, oprette kalenderaftaler eller skrive tilbage til et live system. Adskil både data, credentials og destinationer mellem miljøerne.

• Brug særskilte testkonti, API-klienter, buckets, databaser, nøgler og webhookendpoints; kopiér ikke produktionssecrets til staging.
• Send mail og SMS til en lokal opsamler eller en dokumenteret allowlist af testmodtagere. Gem den oprindelige modtager som testmetadata, hvis flowet skal kontrolleres.
• Brug leverandørens test- eller sandboxmiljø, når det findes, og markér tydeligt i brugerfladen at handlingen ikke er virkelig.
• Afvis udgående kald til produktionsdomæner på netværks- eller applikationsniveau, og lad testen fejle tydeligt i stedet for at falde tilbage til live credentials.
• Giv testmiljøet et synligt miljønavn og en anden visuel markering, så en medarbejder ikke forveksler det med produktion under en manuel test.

Gør en datarefresh til en kontrolleret pipeline

Hvis data skal fornyes, så lad processen være kode og kontroller frem for en fil, der sendes rundt. En enkel pipeline kan udtrække det godkendte udsnit, transformere, validere, indlæse og til sidst dokumentere sletning af mellemprodukter.

• Fastlås kilde, destinationsmiljø, valgte felter, transformationsversion og ansvarlig godkendelse.
• Stop processen, hvis miljømarkører, destinationskonto eller forventede sikkerhedsindstillinger ikke passer.
• Kontrollér forbudte mønstre og datatyper efter transformationen, men brug ikke et regex-resultat som bevis for reel anonymisering.
• Verificér antal, relationer og de testscenarier, som datasættet skulle bevare; maskering må ikke gøre testen meningsløs.
• Log proces og resultat uden at skrive de følsomme værdier ind i loggen. Gem hvem, hvornår, formål, version og slettefrist.

Typiske fejl

• “Det er kun staging”: miljøet er offentligt tilgængeligt, har svagere login og indeholder alligevel en fuld kundekopi.
• Overfladisk maskering: navn og e-mail ændres, mens adresser, fritekst, filnavne og kombinationer af dato, sted og ordre bevarer identiteten.
• Fælles credentials: test og produktion bruger samme API-nøgle, cloudprojekt eller databasebruger, så en fejl kan krydse miljøgrænsen.
• Ingen udløbsdato: en midlertidig fejlkopi bliver liggende i en bucket, på en laptop eller i et CI-artifact efter sagen er lukket.
• Kun den pæne vej testes: datasættet har én administrator og én kunde, så manglende rettigheder, tenant-adskillelse og tomme tilstande aldrig bliver prøvet.
• Testmiljø bliver produktion: fiktive konti og data bliver ikke ryddet, før miljøet åbnes for rigtige brugere.

Tjekliste til sikre og brugbare testdata

• ✓Alle databaser, filer, exports, logs og lokale kopier er kendt
• ✓Hvert miljø og datasæt har formål, ejer og slettefrist
• ✓Syntetiske data er standard og kan genskabes fra kode
• ✓Fixtures dækker roller, virksomheder, afslag og grænsetilfælde
• ✓Produktionsdata kræver dokumenteret nødvendighed og mindst muligt udsnit
• ✓Pseudonymiserede data behandles fortsat som personoplysninger
• ✓Adgang, logning, overførsel og patching følger den konkrete risiko
• ✓Test har egne credentials, konti og integrationer
• ✓Mail, SMS, betaling og webhooks kan ikke ramme virkelige modtagere
• ✓Refresh-processen validerer miljø, data og relationer
• ✓Mellemprodukter, artifacts og lokale kopier bliver slettet
• ✓En kontrol bekræfter sletningen og den færdige testtilstand

Relaterede guides

• Testmiljø og rollback – adskil miljøer og afprøv vejen tilbage.
• GDPR og persondata – kortlæg dataflow, formål og ansvar i hele appen.
• Dataretention og slettefrister – gør oprydning målbar og efterprøvbar.
• API-nøgler og secrets – adskil credentials og rotation mellem miljøer.

Officielle kilder

Guiden er teknisk og praktisk information, ikke juridisk rådgivning. Krav og sikkerhedsforanstaltninger skal vurderes ud fra jeres konkrete behandling og risiko.

• Datatilsynet: Testdata – anvendelse af personoplysninger ved udvikling og test
• Datatilsynet: Pseudonymisering og anonymisering
• Datatilsynet: Hvad er personoplysninger?
• EUR-Lex: Databeskyttelsesforordningen (GDPR)
• Microsoft Azure Well-Architected Framework: Security testing
• IETF RFC 2606: Reserverede domæner til dokumentation og test