https://commons.wikimedia.org/wiki/File:Godin_van_de_Wind_4_Nieuwpoort.jpg

D: Data - ditt allt!

Av Charlotta Carlsson 2020-07-03

På alla testnivåer är testdata A och O.  Eller varför inte A till Ö... Det hade funnits tillräckligt att skriva om i ett helt alfabet om bara testdata. Nu får det blygsamma 1 inlägg av mina 28. Men det är kanske det allra viktigaste av dem. 

Låt mig göra följande enkla definition: Testdata är de data du stoppar IN i testmiljön antingen (1) innan du testar eller (2) när du testar. Testdata är inte att förväxla med testresultat. En rapport, ett beräknat värde eller en fil som kommer UT ur systemet när du testar är alltså inte testdata utan ett testresultat. 

Det kan vara bra att i testplaneringen identifiera olika komponenter av testdatat för att kunna förbereda de olika delarna på lämpligt sätt. Vissa komponenter förväntas någon alltså lägga in i testmiljön innan testerna (1). Andra hör till enskilda testfall (2).

Några typiska komponenter kan vara:

• Grunddataregister (exempelvis fasta prislistor, organisationsstruktur, artikelregister, kontoplan och olika slags stödtabeller)
• Konfigurationer (parameterdata som styr systemets beteende)
• Transaktionsdata (de data som skapas eller ändras i systemets dagliga användning och som representerar den dagliga verksamheten)
  
• Filer för inläsning från andra system (behövs kanske när vissa systemintegrationer ska testas, finns det att tillgå eller måste vi skapa eget testdata?)
• Transaktioner på annat format från andra system (-"-)

För alla dessa fall av testdata förväntar sig acceptanstestare att de representerar verkligheten, samt vad gäller grunddata och konfigurationer att det är exakt vad som sedan ska driftsättas. Annars kan de inte känna sig trygga med testresultatet. Det här tycker jag är en avgörande skillnad mellan systemtest och acceptanstest (det finns förstås flera): Representationen av mottagande verksamhet i form av deras verkliga och kompletta data är grundläggande i acceptanstest, medan i systemtest handlar det mer om att använda specifika smarta varianter av testdata för att hitta buggar.

Jag menar så här: I en systemtest går det utmärkt att använda Kalle Anka som normalfall för ett namnfält. Inte i acceptanstest (såvida systemet inte handlar om serietidningar...). Det spelar ingen roll om buggar hittas lika bra med hjälp av testdatat Kalle Anka. I acceptanstest handlar det nämligen inte (borde det i varje fall inte göra) om att leta buggar. Det handlar om att se hur systemet effektiviserar användarnas kommande vardag, att systemet blir trovärdigt, och när testarna förstår datat så testar de också effektivt och korrekt. Testdata i acceptanstest ska därför vara så produktionslikt som möjligt. 

Om möjligt: använd en kopia av din produktionsdatabas (som i många fall behöver avpersonifieras  - tänk "GDPR"). Det ger, förutom trovärdigheten, en automatisk testtäckning av verksamhetens/kundens olika fall som, i varje fall i nuläget, kan förkomma i verksamheten (tänk t.ex. "hur långa efternamn kan förekomma i kundregistret?"). 

Men att använda produktionsdata är för den delen inte så enkelt som det verkar vid första anblicken:

• Det gäller att veta när det är lämpligt att produktionskopian tas; i vilken status vill vi att datat ska komma till testmiljön?
• Många verksamheter och därmed dess data präglas av större körningar t.ex. vid månadsskiften eller uppdateringar i batch varje natt. I vilket läge kommer det att vara då vi produktionssätter?
• Databasen i produktion kanske laddas med data från källsystem vid vissa tidpunkter, hur får vi detta att stämma med testfallen vi vill köra?
• Behöver vi kanske synka status hos flera systems data för att kunna testa systemintegrationer?
  
• För att befintlig produktionsdata ska kunna användas som testdata vid test av en ny systemversion kan den ju även behöva kompletteras och justeras, eller kanske ska data som helhet till och med konverteras mellan systemversioner eller mellan databaser i gamla och nya system?
• Och förstås om systemet stödjer ett helt nytt behov där det inte finns tidigare produktionsdata att använda över huvud taget så måste ju all testdata skapas från grunden vilket innebär särskilda utmaningar. Men grundprincipen även då är att använda så verklighetstrogen information som möjligt.

Inte nog med det, här är några fler aspekter av testdata som jag direkt kommer på. Listan är naturligtvis inte komplett och varierar kraftigt utifrån kontext:

• Om ditt projekt byter ut ett eller flera gamla system mot ett nytt är datakonvertering troligtvis en central projektaktivitet, och den behöver förstås testas noggrannt. Det är då i princip ett måste att konverteringen testas noggrannt för sig, i god tid INNAN acceptanstest. Det behövs både tekniska och verksamhetsögon på datat i dessa förberedande konverteringstester. Om datakonverteringen i sig är väl testad så kommer konverterat data att utgöra en pålitlig komponent av testdata i acceptanstesten.
• Ingen får använda samma testdata samtidigt i samma testmiljö, då förlorar testarna kontroll över resultatet. (Se vidare under bokstaven Ä - Äg din testmiljö)
  
• Användarregister och behörigheter för olika användarkategorier är ett par specialfall av grunddata eller transaktionsdata. I vilken form ska detta finnas i testmiljön? Å ena sidan vill man testa produktionslikt, å andra sidan ska kanske inte alla ha tillgång till testmiljön och det kan även behövas manipulation av behörigheter för olika testsyften.
  
• Ansvar: Vem ansvarar för att populera testmiljön med testdata? För att skapa testdata? För att tänka ut vilka data som behövs i varje testfall?

Med irrelevanta testdata kommer testresultatet antagligen att vara missvisande. Undvik att behöva lägga tid på att tolka felaktiga testresultat och kanske att behöva göra om testerna, lägg lite möda på testdatafrågorna i testplaneringen istället.

Slutsats för bokstaven D:  I acceptanstest ska testdata representera den kompletta verkligheten.