Effektivisera hanteringen av testdata

2008-01-09 Artikelbanken Test Läst 8174 gånger

Testdata är ett område som är förknippat med många problem. Några vanliga problem är dessa:

  • Det är svårt att skapa en lagom stor uppsättning testdata. En tänkbar lösning är att använda sig av en kopia av hela produktionsmiljön för att vara säker på att få med allt men detta är ofta väldigt tungarbetat. Batchkörningar tar onödigt lång tid att köra när det är för mycket data i testmiljön.
  • Testare behöver tillförlitligt testdata som inte är sönderhackat av andra testare.
  • Det är komplicerat att låta flera system dela på en gemensam testmiljö. De olika systemen ligger oftast inte i fas och körplanen blir väldigt komplex. Således finns ett behov av att varje system kontrollerar sina testdata.

I den här artikeln presenterar jag en process för att effektivisera hanteringen av testdata för användning i flera testmiljöer. Jag kommer att behandla för- och nackdelar med processen och vilka roller som behövs för att processen ska fungera så effektivt som möjligt.

Artikeln baseras på det arbetssätt som jag har använt i samband med tester av större administrativa system inom en organisation. Eftersom jag har arbetat länge inom försäkringsbranschen är vissa exempel hämtade från den branschen. Processen är inte generell för samtliga företag och det är inte troligt att du kan applicera hela processen rakt av, men delar av processen är generella och kan användas för vidareutveckling av en egen process. Du kan t ex behöva anpassa processen beroende på hur systemen hänger ihop och om det finns flera plattformar. Jag har använt processen för integrationstest, systemtest och acceptanstest. För komponenttest användes däremot utvecklarnas lokala miljö och testdata togs fram på annat sätt som inte beskrivs i den här artikeln. Principerna bör gå att tillämpa även för komponenttest.

Process för att ta fram testdata och testmiljöer

Processen består av följande sex steg.

  1. Ta fram ett urval från produktion
  2. Genomför sambandskontroller
  3. Avidentifiera känslig information
  4. Skapa central testmiljö och iordningställ testmiljö
  5. Läs in testdata till respektive system
  6. Uppdatera säkerhetskopian vid ändringar

Varje steg beskrivs mer utförligt nedan.

1. Ta fram ett urval från produktion

Detta steg genomförs av testledaren eller en särskilt utsedd testdataansvarig. Man kan exempelvis välja att ta var tionde eller var tjugonde person från produktionsmiljön beroende på hur stora volymer data som finns. Om det blir för mycket data, väljer man var exempelvis var tjugonde och om det blir för lite, kan man välja var tionde. Urvalet lagras i en särskild mellanlagringsmiljö för ytterligare bearbetning.

Utöver det slumpmässiga urvalet är det vanligt att data behöver kompletteras för hand. Vanligen finns önskemål på testdata hos verksamhetsspecialister, testare och IT-drift. Det är ofta ”specialare”, till exempel personer med udda försäkringsavtal, eller grupper, exempelvis samtliga personer med en speciell försäkringsform, som verksamhetsansvariga och testare vill inkludera i testerna. Det är vanligt att visst testdata alltid ska vara med. Det kan vara särskilt snåriga situationer, komplex affärslogik, systemdelar där det tidigare hittats många fel eller testdata som hör till testfall baserade på tidigare funna fel. Visst testdata kan gälla för ett specifikt system och kan tas bort nästa gång nytt testdata skapas. Testdata tas fram genom att den testdataansvarige eller en DBA (datasadministratör) kör databasfrågor mot produktionsdatabasen. Om det är möjligt bör man spara sådana databasfrågor så att de snabbt kan köras vid ett senare tillfälle. Man kan även behöva ange enstaka testdata manuellt om de inte kommit med i de databasfrågor som körts.

I ett senare steg kommer känslig information att tvättas bort, men redan här kan man behöva utesluta viss information, exempelvis data om egna anställda, löneinformation, sjukdomshistorik etc.

2. Genomför sambandskontroller

Körningar görs sedan för att kontrollera att alla samband har kommit med. Samband kan både finnas inom samma system och med omgivande system. Ett exempel på samband inom systemet är att om testerna avser en kund med familjepension så måste även den avlidnes försäkring finnas med i systemet för att informationen ska visas korrekt. Samband med andra system kan gälla utbetalning, personuppgifter med mera.

3. Avidentifiera känslig information

I nästa steg görs avidentifiering. Det finns det olika synsätt om vad som är avidentifiering beroende på hur känsliga uppgifterna är. Det kan vara företagets jurister som styr hur avidentifieringen ska göras.

Det viktigaste första steget är att avidentifiera namn och adress. Tips! Ändra adress på samtliga testpersoner så att de går till ditt företag. Om ett misstag sker så att ett brev går iväg till någon av testpersonerna, så har man därmed försäkrat sig om att brevet kommer tillbaka till företaget. Testpersonerna kan döpas till företagets namn följt av ”testfall”.

För att ytterligare göra avidentifiering kan personnummer, kundnummer med mera avidentifieras. Det är vanligt att systemet gör en kontroll av om uppgifterna är korrekta, exempelvis att ett personnummer innehåller en korrekt kontrollsiffra. Därför kan man inte bara byta ut informationen rakt av mot nonsensdata, man måste använda en räkneformel för att åstadkomma uppgifter som accepteras av systemet.

Ett problem som kan uppstå är att testarna inte hittar sina utvalda testdata. Om en testare exempelvis har valt att inkludera ett specifikt personnummer för att kunna testa en specialsituation i systemet och detta personnummer byts ut mot ett påhittat, blir det omöjligt att hitta informationen i testmiljön. En översättningstabell behövs i detta fall. En sådan tabell innehåller två kolumner med det korrekta personnumret och det fejkade personnumret.

Ett annat problem som man kan behöva ta hänsyn till är om externa samarbetspartners, exempelvis Skatteverket, deltar i testarbetet. Det är kanske inte möjligt att kräva att en samarbetspartner ska införa samma avidentifiering. Om de skickar en fil med riktiga personnumret, måste en översättning till det avidentifierade personnumret göras när filen kommer.

4. Skapa central säkerhetskopiera och iordningställ testmiljö

Nu när testdatat är färdigt, läggs det in i en testmiljö. I vårt fall läste vi in datat till den miljö som användes för tester med andra samverkande system (den miljö som ibland kallas systemtestmiljö, systemintegrationstestmiljö, samverkanstestmiljö eller sambandstestmiljö). För att iordningställa testmiljön, flyttas program, filer etc till miljön, antingen av utvecklarna var och en för sig eller av en testmiljöansvarig.

Testledaren bör i samband med testplaneringen ha bestämt vilket fiktivt datum som ska gälla för testerna. Det fiktiva datumet är det datum som systemklockan är inställd på när testerna inleds. Det är vanligt att man vill att testerna löper över ett årsskifte eftersom det ofta sker en hel del extra aktiviteter i ett system då. Det är praktiskt att skapa ett testschema där det framgår vilka körningar som ska köras och vilka testfall som ska genomföras.

För att systemet ska komma till detta fiktiva datum kan man behöva ”rulla fram” testmiljön så att man står precis i startläget för testerna. Detta görs bland annat genom att köra de batchar som behövs för att komma fram till rätt datum och flytta fram klockan i systemet. När detta är klart tas en säkerhetskopia av hela miljön med dess testdata. Denna säkerhetskopia är utgångsläget för alla testmiljöer oavsett system och testnivå.

5. Läs in testdata till respektive system

Säkerhetskopian kan nu läsas in i vilken testmiljö som helst för att användas av de olika systemen. Resultatet blir att alla system utgår från samma testdata och från samma versioner av det testade systemet. Kopplingen till alla andra system finns även om du exempelvis är på en testnivå där man normalt bara testar inom systemet och därmed upptäcks integrationsproblem tidigt. Eftersom varje system läser en kopia av den centrala säkerhetskopian blir störningar på andra tester minimala. Den gemensamma miljön uppdateras med nya program efter godkända integrationstest vilket gör att alla system har tillgång till den aktuella programversionen.

6. Uppdatera säkerhetskopian vid ändringar

Om förändringar av filer görs måste ny säkerhetskopia tas och om det finns behov kan respektive system läsa ner denna i sin egen testmiljö. När exempelvis filer ändras måste en ny säkerhetskopia tas. Utvecklarna måste få information om att det finns en ny kopia och en utpekad person behöver ha ansvar för att läsa in kopian i respektive miljö.

Översikt till processen

I mitt fall användes samma centrala databas för samtliga system. Det innebär exempelvis att kundinformationen från den centrala miljön användes av både försäkringssystemet, utbetalningssystemet och skadesystemet. En grafisk illustration av sambandet ser ut så här:

Bild 1 – Sambandet mellan miljöerna i översikt

Olika situationer då processen kan användas

Processen är förstås användbar för alla vanligt förekommande tester i både projekt och förvaltning. Utöver det kan den även användas till andra lite mer speciella situationer.

Ibland är det nödvändigt att ha testdata som avspeglar den kompletta produktionsmiljön. Så är fallet vid så kallade parallelltester som innebär att man jämför gamla versioner av program med nya versioner för att se att slutresultatet blir lika. Detta arbetssätt kan vara praktiskt i samband med större förändringar av systemet. Testerna kan med fördel genomföras i en separat miljö som enbart är till för parallelltest. Man tar ner hela produktionsdatat till testmiljön, avidentifierar datat och kör sedan med de gamla programmen. Därefter kör man samma tester men med de nya programmen och jämför sedan om resultatet blev lika.

Även då behovet av testdata är mycket litet kan processen användas. Man kan i vissa situationer vilja minska uppsättningen testdata till kanske bara 10-15 personer. Då plockar man ner enstaka testpersoner till en särskild miljö. I detta fall används den mellanlagrings¬miljö som beskrivits ovan. Detta kan vara relevant när man vill följa ett fåtal testpersoner och ha bättre uppföljning på resultatet. Ett exempel är att följa en försäkrings flöde genom systemet ända ner till ekonomi och huvudbok.

Fördelar med detta sätt att arbeta

Tack vare att man skapar en säkerhetskopia som kan användas av alla system i alla testmiljöer på alla testnivåer, behöver inte respektive system skapa eget testdata. Detta sparar en hel del tid och medför fördelen att samtliga system har samma testdata.

Detta arbetssätt är effektivt om man kör testerna i testomgångar. Testomgångar innebär att man kör en testcykel exempelvis på fyra månader, från och med november till och med februari med ett fiktivt testdatum. När man kört testfallen för denna testcykel och fel rättats börjar man om från början igen med de rättade programfelen. Man tar en ny säkerhetskopia och laddar ned den i testmiljön. Sedan kan man starta en ny testomgång med samma testcykel, fiktiva datum, testdata och testfall. Testarna kan använda samma testdata som tidigare och slipper leta fram nytt testdata.

Eftersom det är bättre kvalitet på testdatat minskar antalet fel som utvecklarna inte kan återupprepa på grund av bristfälligt testdata. Omtesterna blir också mer effektiva.

Nackdelar med detta sätt att arbeta

Processen sparar mycket tid när den väl är på plats, men det tar tid att arbeta fram en fungerande process. Varje gång man ska skapa nytt testdata tar det en viss mängd tid som måste inkluderas i tidplanen. Sammantaget kan man säga att fördelarna uppväger nackdelarna.

Roller som behövs

Arbetet underlättas mycket om det finns en särskilt utpekad person som ansvarar för testdata, en så kallad testdataansvarig. Rollen söker ut och skapar testdata och kan vara en DBA (databasadministratör), utvecklare eller en testansvarig.

Det underlättar även om det finns en utpekad testmiljöansvarig som dokumenterar behovet av testmiljöer, iordningställer testmiljön, testar att testmiljön fungerar och eventuellt hjälper till med testverktyg.

Eventuellt kan dessa två roller innehas av en och samma person, men om arbetet är omfattande bör rollerna innehas av specifika personer.

Sammanfattning

Att ha en effektiv process för hantering av testdata medför många fördelar. Körningar tar kortare tid, data blir mindre sönderhackat och data för specialsituationer medföljer automatiskt. Att bygga upp processen för att skapa testdata tar tid men när den finns där kan man använda samma process om och om igen. Det behövs en testdataansvarig och en testmiljöansvarig för att hålla allt ajour och informera respektive ansvarig om eventuella förändringar.

 

KONTAKTA OSS

Har du frågor? Vill du ha hjälp med områden inom kravhantering och test?
Hör av dig till oss! Vi hjälper dig gärna. 

Kontakt 

Dela artikeln