Jeg ser at det er en interessant debatt som nå foregår rundt bruk av person-identifiserbar informasjon (PII) i forbindelse med test og utvikling, og da spesielt rundt test, sett i lys av EUs GDPR.
Bakgrunn: Tre overraskelser og potensielle gevinster som utviklere vil få gjennom GDPR og GDPR: – Test på produksjonsdata kan være lovlig
La meg legge til at PII er mye mer omfattende enn det begrepet vi benytter i Norge som er personopplysninger. PII kan omfatte sted, IP og alt som gjør at man kan identifisere et individ. Jeg har selv hatt gleden av å holde tre foredrag så langt rundt temaet for Dataforeningens testnettverk og skal holde flere i tiden som kommer. La meg også legge til at jeg representerer et selskap som selger løsninger innenfor området.
For mange kan nok dette med bruk av PII i test virke forvirrende og jeg skal derfor forsøke å bidra til en liten oppklaring på hva og hvorfor.
Vi er nødt til å starte med hva som faktisk er formålet med GDPR. For det første er dette ment som en harmonisering av regelverket på tvers av hele EU/EØS. Dernest ønsker man at borgerne skal få en bedre forståelse av hvordan deres data/informasjon blir brukt, herunder også anledning til å klage på bruken. I tillegg ønsker man at bruken av PII blir mer sikker og at bruken også blir redusert dersom det er mulig. Så langt tror jeg at alle er enige.
Premissene er gale
Utfordringen rundt test dreier seg om at en del av premissene for en del av argumentasjonen er gal. La oss derfor ta utgangspunkt i hvordan test foregår de aller fleste steder i dag og da med spesielt fokus på test data.
For at en eller flere tester skal kunne utføres er det i hovedsak to ting som trengs; en testcase (beskrivelse av hva som skal testes) og testdata (de dataene som ligger til grunn for at en testcase skal kunne utføres). For å få tilgang til et testdata-grunnlag bruker de aller fleste norske organisasjoner i dag kopi av produksjonsdata. Det vil si at man kopiere/kloner produksjonsbasen og tilgjengeliggjør den for test. Og her begynner problemene.
Det er en myte at produksjonsdata er det eneste saliggjørende for å kunne drive god testing
La oss slå fast en gang for alle. Det er en myte at produksjonsdata er det eneste saliggjørende for å kunne drive god testing. Snarere er det tvert imot, produksjonsdata er en begrensende faktor i seg selv når man skal drive god testing. Når vi er ute og snakker med organisasjoner som driver med test er tilbakemeldingen at ca. 30 % av alle tester feiler fordi man ikke har et godt nok testdata-grunnlag. Men hvordan er dette mulig når man baserer seg på kopi av produksjon? Jo fordi kopi av produksjon faktisk ikke gjenspeiler det man ønsker å teste på. Når man driver test så ønsker man å teste alle mulige scenarier, også de man ikke finner i produksjon. La meg eksemplifisere: Hva med negativ testing, den vil du så godt som aldri finne i produksjon. Ei heller ekstremcasene, som du i beste fall finner et veldig lite antall av. Slike scenarioer vil man kunne generere opp ved hjelp av syntetiske data, i tillegg til andre vanlige scenarioer, men på en slik måte at reelle PII ikke blir brukt.
Myte nr 2: Det tar lang tid å generere syntetiske test data. Det er snarere tvert om. I de fleste tilfeller vil det være raskere å generere opp syntetiske testdata enn det er å vente på produksjonsdata. Vi ser at Software Delivery Life Cycle – SDLC ofte blir forsinket fordi man må vente på testdata og da på kopi av produksjon. Hvorfor? Jo fordi veldig ofte er ikke de riktige produksjonsdataene tilgjengelig, det er feil versjon, etc.
Med andre ord vil syntetiske testdata gi bedre kvalitet og hurtigere tilgang, og således være med på å gjøre test mer effektivt. Sagt på en annen måte, en del av argumentene for å bruke produksjonsdata i test er ikke reelle. Sett opp mot EU GDPR er dette interessant fordi man ser for seg å benytte grunnlaget «berettiget interesse» og en kompatibilitetsvurdering som argumentasjon for bruk av produksjonsdata og dermed reelle PII i test. Man kan ikke uten videre benytte en slik argumentasjon når man fra et test-ståsted vet at produksjonsdata ikke er gode nok. Da gjør man det kun fordi man ikke har noe ønske om å forandre dagens praksis snarere enn sett ut i fra et personvernståsted.
Du kan ikke kopiere hele baser, bare fordi det er det enkleste
Videre er det svært sjelden at man faktisk benytter hele produksjonsbasen til test. Hvis en database i produksjon er på 3 TB så bruker man ikke hele denne til test, man bruker kun et utvalg. Så hvorfor skal du ta kopiere hele basen? Jo fordi det er det enkleste. Men det strider mot artikkel 23 i EU GDPR, som sier noe om minimering av bruken av PII. Du kan ikke fortsette å kopiere hele baser bare fordi det er det enkleste.
Finnes det metoder som gjør at du kan drive feilretting uten bruk av produksjonsdata, ja så skal du det
Alle er også enige om at dersom man skal utvikle noe nytt eller ny funksjonalitet så kan man ikke benytte en eksisterende kundebase til noe slikt. Det går på artikkel 5 i EU GDPR som handler om hvilket formål man har innsamlet PII i. Med andre ord: Dersom du driver en nettbutikk og selger forbrukerelektronikk, så kan du ikke bruke innsamlede PII til å utvikle en mobiltelefontjeneste. Men hvor går så grensen for hva som er nytt? Her kommer man over på området forvaltning. Forvaltning er jo bare videreføring av det eksisterende og ikke noe nytt. Dermed må man kunne benytte produksjonsdata i test, eller? Tja, det er ikke like sikkert. Dersom det finnes metoder som gjør at du ikke trenger å benytte reelle PII i test, så skal du heller ikke gjøre det – og vi har tidligere i kronikken slått fast at det finnes slike metoder. Så da kan du ikke fortsette med det bare fordi det er den enkleste metoden.
Dette gjelder også for test i forbindelse med feilretting. Finnes det metoder som gjør at du kan drive feilretting uten bruk av produksjonsdata, ja så skal du det. Jeg ser riktignok at i en del tilfeller så må man benytte reelle produksjonsdata i feilrettingsøyemed, men du skal ikke gjøre det bare fordi det er det enkleste.
Poenget er at de aller fleste, om ikke alle, må forandre sin testpraksis på grunn av EU GDPR. Man kan ikke uten videre benytte produksjonsdata og dermed reelle PII i test. I de tilfeller man kan gjøre det, så er det mer unntaket enn regelen. De aller fleste benytter produksjonsdata fordi man tror dette er det enkleste og beste, og ikke ønsker å forandre dagens praksis. Personvern handler ikke om hva som er enklest og mest behagelig, det handler om hvordan vi best mulig kan sikre PII. Og betyr det at vi må ta noen grep innenfor test for å imøtekomme dette, ja da er du faktisk forpliktet til å ta disse grepene.
Man skal ikke forsøke å finne frem til argumenter for å slippe unna bare fordi det medfører endring, det er ikke godt personvern. Sånn er det bare.
