Vikten av anpassat testdata
Oavsett om du skall utveckla ett nytt system eller uppgradera och förvalta ett äldre så behöver du testdata som är anpassat för det du skall testa.
För många år sedan började jag ett uppdrag på ett multinationellt bolag för att hjälpa dem starta upp en intern QA avdelning. Jag kunde inte undgå att se att det runt omkring mig jobbades hårt för att förbereda sig för GDPR som skulle införas i maj 2018.
Det visade sig att de hade scoopat ut test och utveckling ur GDPR-anpassningen vilket var vad jag arbetade med. Jag föreslog då att vi skulle hantera frågan om GDPR även inom mitt uppdrag, vilket de var tacksamma över att jag gjorde.
Jag hade redan då jobbat länge med test men jag måste erkänna att jag var tämligen okunnig när det gällde testdata. Jag började därför höra mig för i mitt nätverk efter personer som kunde hjälpa mig igång. Trots mitt stora nätverk inom testområdet så blev det tydligt att det var svårt att hitta folk som verkligen kunde såväl den kommande GDPR-lagstiftningen och vad som behövdes för att testa på ett optimalt sätt.
Det första jag insåg var att det är mer komplext att hantera lagstiftningen i test och utvecklingsmiljöer än i produktionsmiljö så jag förstod snabbt varför de scoopat ut dessa delar.
Nu har det gått över 6 år sedan jag började jobba med att ta fram och implementera anpassat och lagligt testdata och den här bloggposten är en sammanfattning av de erfarenheter jag fått.
Då det är ovanligt att man inte utgår från ett tidigare system och dess data när man bygger nya, så man har nästan alltid utgått ifrån produktionsdata när man börjat utveckla. Det är ingen bra idé men det var GDPR:s hot om höga sanktionsavgifter som främst gjorde att företag fick upp ögonen för hanteringen av personuppgifter i testdata. Trots detta är det fortfarande mycket vanligt att stora företag och myndigheter fortfarande använder riktiga personuppgifter i sina test och utvecklingssystem.
När man läser denna text kan man få intrycket att det är oerhört komplicerat. Men är det en sak jag lärt mig så är det att inte göra testarbetet mer komplext än vad det faktiskt är. Vi behöver däremot goda kunskaper om vad som behöver testas, och hur det skall göras. Man behöver även förmågan att kunna diskutera såväl utvecklingsmiljöer, som test och juridik för att kunna skapa relevant och hanterbart testdata.
Varför behöver vi anpassat testdata?
Det finns i huvudsak tre anledningar till att man inte skall använda produktionsdata i test och utvecklingsmiljöer:
- Att behandla personuppgifter i utvecklingsmiljöer kräver en laglig grund, tex ett specifikt medgivande för test/utveckling samt ha exakt samma säkerhet och kontroll som i produktionssystem vilket i praktiken är omöjligt.
- Konfidentiellt data såsom prislistor, marknadsplaner med mera vill man kanske inte att konsulter eller ens anställda från ”fel” avdelning får tillgång till. Det kan även i vissa fall vara olagligt tex om denna information kan vara kursdrivande om den kommer på drift.
- Produktionsdata är i regel inte bra ur testbarhetssynpunkt då det mesta är ganska lika.
Vad händer om vi utgår från produktionsdata?
Innan vi går in på detaljer i ovanstående så tänkte jag sammanfatta de problem de skapar.
-
Det finns en stor osäkerhet om man lyckas när man försöker anonymisera/pseudonymisera personuppgifter. Kanske går det att spåra vems uppgifter vi anonymiserat? Denna fråga blir allvarligare ju känsligare data man hanterar. För att komplicera det i ytterligare en dimension så kan det hända att man använder konsulter/personal som inte är svensk, eller till och med sitter utanför EU vilket kan göra det otillåtet för utvecklarna att hantera personuppgifter vare sig man har medgivande eller ej. Vi pratar ju främst om personuppgifter här och att bryta mot GDPR kan som alla vet bli väldigt dyrt. Men även andra lagar såsom finansiella, kommunallagen och flera andra behöver man ta hänsyn till.
-
När man testar end to end så använder man oftast data från flera källsystem. Det kan vara svårt att anonymisera dem så att data fortfarande fungerar. Man bör också tänka på att ju mer data vi anonymiserar, desto svårare blir det att garantera att anonymiseringen fungerat.
-
För att vi skall kunna säkerställa att fel inte skall uppstå i produktion så måste vi testa dessa i utvecklings- och testmiljöer.
-
När man testar så behöver man data som stödjer de tester man skall testa och det kan vara många parametrar som skall uppfyllas. Om det av olika anledningar inte finns data som stödjer det man vill testa, tex så kan det vara en funktion man håller på att utveckla.
-
Relevant testdata kan ”ta slut”. När man hanterat en uppgift så kan man inte alltid göra om samma sak med samma grunddata då det har fått nya egenskaper. Detta kan lösas genom att man återställer hela databasen till hur den såg ut vid ett givet tillfälle, men detta kan orsaka andra problem.
-
För att testa feltolerans så behöver vi även data som är felaktigt, saknar vissa fält, använder otillåtna tecken och mycket annat. Dessa finns förhoppningsvis inte i produktion men vi behöver försäkra oss om att det inte får några allvarliga effekter om det trotts allt hamnar där.
De främsta fallgroparna när man skapar testdata
Det främsta misstaget är att man försöker anonymisera all produktionsdata i ett svep och tror att detta skall räcka. Det kan bli väldigt komplicerat när man har många olika källsystem. För det första skall du kunna garantera att data verkligen är anonymiserat vilket är i det närmaste omöjligt pga att det oftast finns så stora mängder extremfall. En del säger att man skall ta bort dessa men det är helt fel väg att hantera frågan ur testbarhetssynpunkt. Vad är då ett extremfall, eller som de oftast kallas när man hanterar data, outliers? Det kan tex vara data som anger en ensamstående förälder med 11 barn med rätt till färdtjänst som bor i Sveg. Det lär knappast finnas mer än en person med de egenskaperna och det lär finnas mycket mer information om denna person när man tittar närmare. Kan man på detta vis spåra vem uppgifterna tillhört så kan man inte hävda att data är anonymiserat. Varför kan vi då inte bara ta bort dessa extremfall? Det är ju dessa extremfall som är intressanta ur ett testperspektiv. Om antalet barn är det intressanta här så måste vi veta att systemet inte gör något oväntat/otillåtet när ett högt värde uppstår i detta fält. Vad är då rimligt att systemet klarar? Det kan jag inte säga men inget får lämnas åt slumpen. Om vi skall sätta en övre gräns här så måste ett läsbart felmeddelande eller en process skapas för om en person lyckas få ett barn mer en vad systemet klarar av.
Om vi använder anonymiserat produktionsdata så behöver vi hantera väldigt stora volymer vilket kan ta åtskilliga timmar, alternativt dygn, för att ladda in vilket försvårar testarbetet.
När vi sedan tittar på hur produktionsdata ser ut så är det mesta väldigt lika varför vi inte behöver så mycket av det för att testa. Vad vi däremot behöver, som jag beskrivit ovan, är extremfall, vilket vi oftast har för lite av. Vi behöver även skapa felaktigt data för att kunna testa feltolerans i systemet, vilket sammantaget visar på varför produktionsdata inte är bra testdata ens om det är lagligt att använda.
Hur gör man då?
Så i stället för att försöka anonymisera stora mängder data så behöver vi skapa syntetiskt data från grunden och fokusera på vad vi verkligen behöver. Det innebär att vi fokuserar på kvalitet i stället för kvantitet. Att skapa alla dessa testdata i förväg är i princip omöjligt då det är oerhört svårt att komma på alla varianter som vi behöver innan vi skall testa. Skulle vi ha missat något så behöver vi kunna skapa detta utan långa handläggningstider för att någon annan skall göra det.
Det finns många tillfällen då behovet förändras under systemets utvecklings- och livscykel, tex beroende på tid. Skall något tillåtas beroende på ålder så vill vi alltid ha någon/något som precis har uppnått tex ålder, och en som fortfarande inte gjort det men ligger precis utanför intervallet. (Så kallad gränsvärdestest)
Sedan får vi inte glömma att data kan förbrukas. Har tex en person fått körkort, så kan vi inte ge den personen ett till för att studera hur processen går till. Detta är bara några få exempel och oftast är det mycket fler saker man behöver. Det är därför i princip omöjligt att i ett svep skapa allt det data vi behöver.
Det finns tillfällen då vi även behöver kvantitet, tex för prestandatester. Men testdata bör inte vara statiskt och när vi testar prestanda så behöver vi inte precision på samma vis som när vi testar funktionalitet och beräkningar. De processer/lösningar som man sedan sätter upp kan oftast återanvändas för andra delar av systemet, eller för nya projekt.
Vi på Sopra Steria har hjälpt många bolag med såväl kravställning, utveckling av miljöer och framställandet av dynamiska testdata. Hör av dig till mig om du är nyfiken på att få veta mer eller få tips kring hur man kan komma i gång.
Vill du veta mer om testdata?
Den 26:e april kommer Anders tillsammans med Mikael Carlander att hålla ett webinarie på det här temat.
Läs mer och anmäl dig här:
Inläggsförfattare
