Første gang jeg fikk spørsmål om å snakke for det vi litt upresist kan kalle testmiljøet, måtte jeg tenke meg grundig om. Jeg takket selvsagt ja, men jeg grunnet på hva i all verden jeg skulle si. Min første refleksjon var at testing var mindre utfordrende enn vanlig databehandling, fordi det foregikk i mindre skala og i en begrenset periode. Det skal sies at dette var i min spede barndom i Datatilsynet, og den gangen var det veldig lite snakk om testing hos oss. Vi hadde få saker og fikk få spørsmål om testing.
Noe kan gå galt…
Jeg har selvsagt lært. Det har også mange virksomheter. Og testmiljøet i Norge har blitt mer modent, i den forstand at flere har fått opp øynene for hvor viktig, og ikke minst hvor utfordrende testing er. Det er dessuten ikke lenger bare funksjonelle krav i løsningen som skal testes.
La oss begynne med å smake på selve ordet. TEST. Det betyr å prøve ut noe, sannsynligvis noe selskapet har jobbet med lenge, og som de snart skal sette i produksjon. Det ligger nærmest i sakens natur at noe kan gå galt. Ja, vi kan si det så sterkt at det egentlig er ganske fint om noe går galt, for det er jo bedre at det går galt under testing, enn etter produksjonssetting. Men tenker vi tanken helt ut, er det å teste på ekte personopplysninger faktisk å ta en sjanse med disse menneskenes data.
Noe kan gå galt, og de som utfører testingen, skal nødvendigvis heller ikke ha autorisert tilgang til ekte data, for eksempel dersom det er innleide konsulenter. Nå kan ikke dette helt unngås, men det skal foreligge et behandlingsgrunnlag. De som skal teste skal være autoriserte, og vår klare anbefaling er å bruke syntetiske data ved testing. For dummies kalles dette gjerne Donald Duck-data, fordi det ikke er snakk om ekte personer eller opplysninger som kan ledes tilbake til reelle personer.
…og det gjør det dessverre litt for ofte
Det er veldig viktig å teste, derfor er også regelmessig testing eksplisitt nevnt som et aktuelt tiltak for å sørge for tilstrekkelig sikkerhet for personopplysninger. De siste årene har vi sett flere eksempler på alvorlige hendelser fordi virksomhetene ikke har testet på forhånd:
- I en sak mot Oslo kommune, knyttet til appen Skolemelding, ga vi et overtredelsesgebyr på 1,2 millioner kroner. Vi la bl.a. vekt på at «mangelfull testing før lansering av appen førte til at den ble lansert med sårbarheter som er godt kjent i sikkerhetsmiljøer verden over».
- Rælingen kommune ble ilagt et overtredelsesgebyr på 500 000 kroner. Det ble blant annet gitt fordi det ikke var gjort nødvendig testing før applikasjonen Showbie ble tatt i bruk.
- Vi har også nylig gitt et overtredelsesgebyr på kr 1 250 000 til Norges Idrettsforbund. De testet på reelle personer i betydelig omfang da de skulle flytte data fra fysisk miljø til en skytjeneste. Resultatet var at personopplysninger var eksponert i 87 dager. (De har tre uker på å klage på vedtaket.)
Gjør test til en fest!
Hvordan teste riktig? Et godt sted å begynne er å lese Datatilsynets veileder om programvareutvikling med innebygd personvern.Der er et eget kapittel om nettopp testing. Det er også en god ide å la seg inspirere av NAV. Hvert år deler vi ut en pris til beste løsning med innebygd personvern. Vinneren i 2019 var nettopp NAV med bidraget «Gjør test til en fest! Løsning for syntetiske testdata«.
Min testlærekurve har vært bratt, men veldig nyttig, og det var veldig stas å delta på prisutdelingen til NAV. Jeg hadde helt sikkert holdt et mye bedre foredrag om testing nå enn da denne reisen startet. Og jeg fikk min straff. Foredraget den gangen ble holdt på Thon Hotell Nydalen, og da jeg kom ut etter foredraget, var sykkelen min stjålet. Men den avklippede låsen lå igjen. Den hadde altså ikke bestått testen.