Anonymiserat produktionsdata - Myt eller ren fiktion: del 5

Som konsult möter jag i princip dagligen kunder som har problem med testdata och kunder som vill få i gång testautomatisering, men som inte lyckas. I de flesta fallen handlar det om att kunden vill använda produktionsdata som testdata, ibland med anonymisering för att säkerställa att man följer GDPR.

Med den här artikeln vill jag slå hål på myter kring att produktionsdata är lämpligt testdata och att personuppgifter blir lagligt testdata om man bara anonymiserar. Artikeln är indelad i 5 avsnitt enligt bilden och det här är den sista delen, som handlar om testautomatisering.

För att effektivt kunna automatisera testning behövs en strategi, och helst en bolagsöverskridande strategi som synkroniserar exekveringen så att alla vet när detta sker och därför inte stör ut varandra. En strategi som ligger nära till hands är att alltid exekvera direkt efter uppdatering för att verifiera att legacy-funktionalitet fortfarande är intakt. Använder man sig av CI/CD kan man med fördel deploya i en mellanmiljö där exempelvis automatiska regressionstester, säkerhetstester och användbarhetstester körs, om testerna går igenom deployas mjukvaran vidare till en gemensam testmiljö. Man kan också exekvera precis innan en uppdatering för att säkerställa att systemet är i gott skick, många har felsökt problem som man trott varit relaterade till en uppgradering, men som visar sig varit aktiva redan innan uppgraderingen.

Testautomatisering är bara effektivt om man ska exekvera testerna många gånger, men det betyder också att vi måste underhålla testerna över tid. Regressionstester är ett bra exempel som ofta exekveras efter varje uppgradering. Att skapa automatiska tester är i sig utveckling och bör behandlas som utveckling med versionshantering, planerat underhåll och överenskommen praxis för designval. Exempelvis kan man vid testning av webapplikationer använda Page Object Pattern (POP) som separerar variabel- och konfigurationsvärden per websida. Resultatet är att om något ändras på en sida kan du justera värden in en fil och det slår igenom på samtliga testfall relaterat till den websidan.

Testfall kan med fördel utvecklas parallellt med ny funktionalitet och allra bäst fungerar det tillsammans med testdriven utveckling. Om en utvecklare först kodar funktionalitet och sedan skapar testfall, går dom lätt in i testningen med för mycket kunskap om funktionaliteten för att opartiskt kunna testa. Testningen blir då lätt en slags självuppfyllande profetia. Om utvecklare i ställer först skapar testfall baserat på hur man ska verifiera att kraven uppfyllts och därefter utvecklar funktionaliteten kommer man runt detta problem och ofta blir kodningen också effektivare. När funktionaliteten är kodad och klar kan testfallen exekveras och vid leverans av nya funktionaliteten flyttas testfallen över till regressionstestsviten, se bilden bredvid.

Eftersom testningen i sig ofta påverkar testdatat kan det vara en bra idé att låta testfallen återställa datat. Om vi exempelvis testar access för en användare kan vi vi verifiera att användaren inte har access, öka accessen och verifiera att användaren har access och till sist återställa accessen. Därmed är testdatat redo för nästa exekvering.

Förutsägbart data

Förutsägbarhet är en nyckelförutsättning. I varje situation och vid varje tillfälle måste vi veta vilket data som finns, vilka värden som är satta och vilket status det har. För att skapa förutsägbarhet har vi definierat ett antal grundförutsättningar.

• I de flesta fall är produktionsdata tidsberoende, det ändras över tiden, därmed behöver göra en omladdning med jämna mellanrum och då tappar vi både kontroll och förutsägbarhet. Genom att använda syntetiskt data skapar vi ägandeskap och genom ägandeskap skapar vi kontroll. Undantag kan exempelvis vara konfigurationsfiler för switchar, routrar, DNS eller lastbalanserare som inte dynamiskt ändras över tid i produktion, därmed är det statiskt till nästa uppdatering och produktionsdatat kan då vara mycket lämpligt att använda för testautomatisering. Men i de flesta fall är produktionsdata raka motsatsen till lämpligt testdata.
• För att skapa förutsägbarhet måste vi ha kontroll över testdata i sig, vi inte kan ligga i händerna på externa parter. Om vi inte har kontroll över externa system, och aktuellt testdata i dessa, måste vi simulera systemen.
• Vi behöver även skapa kontroll över händelser. Användarbaserade händelser kan hanteras genom testverktyg, antingen som förberedelse eller i form av kontinuerlig lastgenerering.
• Bakgrundsarbeten som synkning med andra system, filöverföringar, periodiska arbeten sker i produktion vid specifika tillfällen för skäl som ofta inte är valida i testmiljöer. Ett importarbete kan exempelvis behöva köras på natten i produktion för att lasten är lägre då, men i testmiljön kan vi bestämma att jobbet körs vid den eller de tidpunkter som passar oss. Likaså det data som importeras måste vi ta kontroll över, inte bara tidsmässigt utan även innehållsmässigt. Om vi inte vet varför vårt data ser ut som det gör, så har vi inte kontroll.
• Om alla använder samma testdata kommer vi att störa varandra och det enda förutsägbara i det fallet är att inget är förutsägbart. Det är alltså av största vikt att vi kan allokera delar av testdatat för specifika syften.