Konverteringstest (Migrationstest) – En guide for testmanagement

Af: Ole Chr. Hansen, Q Nation A/S

Indledning

Konverteringstest, også kendt som migrationstest, refererer til den særlige testindsats der verificerer, at data og systemer kan overføres fra et eksisterende (legacy) miljø til et nyt målmiljø på korrekt vis. ISTQB’s officielle terminologi definerer konverteringstest som “test af software, der anvendes til konvertering af data fra eksisterende systemer til brug i erstatningssystemer”. Med andre ord fokuserer konverteringstest på at validere de programmer og scripts, der omformer og migrerer data fra det gamle system over i det nye, så det nye system kan benytte dem korrekt.

I praksis omfatter migrationstest dog mere end blot datakonvertering. Det handler om at sikre en fuldstændig og fejlfri overgang til et nyt system eller miljø – uden væsentlig forstyrrelse af forretningen. En udbredt beskrivelse er, at migrationstest skal garantere minimal nedetid (driftsafbrydelse), ingen tab af data og bevaret dataintegritet, samtidig med at alle funktionelle og ikke-funktionelle krav stadig opfyldes efter migreringen. Migrationstest ses ofte som en del af vedligeholdelsestest i livscyklussen. For eksempel fremhæver ISTQB, at når et system migreres til en ny platform, bør man både teste driftsmiljøet og den migrerede software, og at migrationstest (konverteringstest) er nødvendig, hvis data flyttes fra et andet system ind i det system der vedligeholdes.

Standarder fra ISO/IEC/IEEE adresserer også migration. ISO/IEC 12207 (software-livscyklusprocesser) betragter migration som en aktivitet under vedligeholdelse, der kræver omhyggelig planlægning og verificering. Standarden foreskriver f.eks., at der udarbejdes en migrationsplan, udvikles konverteringsværktøjer, gennemføres selve konverteringen af software og data, og ikke mindst at migreringen verificeres grundigt. Dette understreger, at migrationstest skal planlægges og udføres systematisk og i overensstemmelse med etablerede procedurer.

I resten af denne artikel uddybes, hvordan konverteringstest gribes an, hvilke metoder og risici der er forbundet med migration, samt hvilke roller, ansvar, værktøjer og best practices der er relevante for en testmanager at kende. Der fokuseres her på datamigrering og test af dette.

Fremgangsmåder for migrationstest

Tilgangen til konverteringstest afhænger af typen af migration. Fælles for dem er dog behovet for både manuelle og automatiseredetestteknikker for at sikre, at overgangen forløber korrekt.

• Datamigrering: Når fokus er på at flytte data fra et kildesystem til et nyt system, er testen primært centreret om ETL-processen (Extract, Transform, Load). Testteamet skal kontrollere, at alle data udtrækkes korrekt, transformeres i henhold til de definerede regler, og indlæses i målsystemet uden tab eller forvrængning. Fremgangsmåden omfatter typisk:

  • Foranalyse af data: inden migreringen gennemføres data profiling for at forstå kilde-dataenes kvalitet og struktur. Eventuelle datarense- eller transformationsregler identificeres tidligt.

  • Test af migreringsscripts/programmmer: de scripts, der udfører konverteringen, bør enhedstestes og granskes for at sikre korrekt mapping mellem felter og format. Dette kan involvere white-box-test af transformationslogikken for at bekræfte, at kodelogikken følger kravene.

  • Datareconciliation: efter migreringen udføres en systematisk sammenligning af kilde- og måldata. Dette indebærer både kvantitative checks (f.eks. at antallet af poster i det nye system matcher det gamle, summen af værdier, kontrolsummer etc.) og kvalitative checks (f.eks. stikprøver eller 100% felt-for-felt sammenligning for kritiske dataelementer). Automatiserede værktøjer eller scripts er ofte nødvendige her, da datamængderne kan være enorme. Et princip er at sikre 100% dækning for kritiske datafelter – dvs. alle poster kontrolleres for disse felter.

  • Funktionsafprøvning med migreret data: ud over selve datavalideringen skal man teste, at målsystemets funktioner virker med de migrerede data. For eksempel, hvis man migrerer kunde- og transaktionsdata til et nyt banksystem, skal testerne verificere, at kontoberegninger, udtræk, rapporter m.m. stadig fungerer korrekt med de overførte data.

Manuelle vs. automatiserede teknikker: I alle ovennævnte migrationsformer bør man kombinere manuelle og automatiserede testmetoder for at opnå effektiv testdækning. Manuelle tests er typisk nødvendige for udforskende kontrol og brugerstøttet validering– f.eks. visuel kontrol af data i UI’et, domain-eksperters gennemgang af rapporter, eller ad hoc tests af funktionalitet hvor automatik mangler. Men manuelle tilgange alene er meget ressourcekrævende og fejlbehæftede for migrationsprojekter i større skala. Som undersøgelser viser, er manuel datavalidering ekstremt tidskrævende og kan ikke skaleres til store datamængder, hvilket fører til begrænset testdækning og risiko for at oversætte fejl. Testere kan let overse subtile datafejl, især når tusindvis af poster skal sammenlignes. Derfor bør testmanageren tilstræbe maksimal automatisering af gentagne og voluminøse checks:

• For datamigrering kan man udvikle automatiserede scripts (f.eks. i SQL, Python eller specialiserede ETL-testværktøjer) til at sammenligne hele datasæt mellem kildesystem og målsystem. Eksempelvis kan scripts generere tælletal, totaler eller hashværdier for hver tabel og rapportere afvigelser med det samme. Moderne ETL testværktøjer (såsom QuerySurge, Informatica DVO, Datagaps m.fl.) tilbyder funktionalitet til automatisk at validere datamappings og opdage uoverensstemmelser. Disse værktøjer muliggør også realtime monitorering af migreringsprocessen, så fejl fanges øjeblikkeligt.

• Automatisering skal dog suppleres med manuel spot-checks og domæneekspertise. I kritiske situationer kan nogle specialiserede eller komplekse scenarier kræve menneskelig vurdering – f.eks. brugeraccepttest hvor forretningsbrugere verificerer, at data “giver mening” i den nye kontekst, eller design-inspektion af migreringslogikken for at fange fejl som et værktøj ikke forstår. Således bør teststrategien balancere automatiseringens effektivitet med manuel oversigt på udvalgte områder, hvor menneskelig dømmekraft er nødvendig.

Sammenfattende bør fremgangsmåden til migrationstest være systematisk og faseopdelt. Ofte planlægges tests i tre faser: før migrering (pre-migration tests, hvor man tester migreringsværktøjer på et testdatasæt, verificerer mappingregler og forbereder miljøet), under selve migreringen (løbende monitorering og validering af processen) og efter migrering (post-migration tests, hvor der valideres mod forretningskrav og evt. opdateres med finjusteringer). Dette faseopdelte approach sikrer, at man fanger fejl tidligt og kan korrigere kursen inden idriftsættelse.

Risici og faldgruber ved migration

Migreringsprojekter er berygtede for at indebære høj risiko. Uden grundig test kan konsekvenserne være katastrofale – fra tab af uerstattelige data til store driftsforstyrrelser for forretningen. Nedenfor gennemgås nogle af de mest almindelige risici og typiske faldgruber ved konverteringsprojekter, som testmanageren bør være opmærksom på:

• Datatab og datakorruption: En af de største farer ved datamigrering er, at data forsvinder eller ændres utilsigtet. Dette kan ske pga. fejl i migreringslogikken (f.eks. en dårlig join eller filter der gør, at nogle poster udelades), ukorrekt mapping (data placeres forkert), eller begrænsninger i målsystemet (feltlængder, tegnsæt osv.). Selv subtile fejl kan snige sig ind – decimaler kan gå tabt, tekstfelter kan få uønskede trimninger eller mærkelige tegn, enkelte datafelter kan lande i forkerte kolonner, osv. Resultatet kan være, at datasættet umiddelbart “ligner” det rigtige, men indeholder skjulte unøjagtigheder. For at mitigere denne risiko skal testteamet udføre omfattende datareconciliation som beskrevet tidligere. Ethvert afvigelse i antal poster eller kontrolsummer mellem kildedata og migreret data er et rødt flag. Der bør også designes tests, der specifikt fanger typiske datakorruptionsscenarier – f.eks. at NULL-værdier håndteres korrekt, at specialtegn (æøå, emoji, etc.) overlever migreringen intakte, og at numeriske værdier beholder præcisionen (ingen afrundingsfejl). Ofte etableres der en “parallel run” eller udtræk af rapporter fra begge systemer til sammenligning. Endvidere er backup/rollback-planer afgørende: Test at man kan gendanne data, hvis migreringen må rulles tilbage, således at man aldrig risikerer permanent datatab.

• Inkompatibilitet og afvigelser mellem gammelt og nyt system: Inkompatibilitet kan vise sig i mange former. Det nye system kan have en anden datamodel (f.eks. ændret schema, nye obligatoriske felter som det gamle system ikke havde). Hvis disse forskelle ikke afdækkes, risikerer man at migreringen fejler eller at de migrerede data ikke giver mening i det nye system. For eksempel, hvis det nye system kræver at hver kunde har en unik e-mailadresse, og legacy-data indeholder dubletter eller tomme værdier, vil disse poster fejle indlæsningen. Forretningsregler kan også afvige: Det nye system kan validere data strengere (f.eks. kun tillade gyldige datoer, hvor det gamle tillod 00-00-0000). Inkompatibilitet kan desuden opstå på teknisk niveau – f.eks. filformater, tegnkodning (ANSI vs UTF-8), eller systemintegrationer (et afsender-system bruger et format modtageren ikke længere understøtter). Et specifikt aspekt er tværoperabilitet/compatibility: ISO 25010 definerer kompatibilitet som evnen til at udveksle information mellem komponenter og fungere sammen i et delt miljø. Under migrering til nye platforme skal man sikre, at alle tidligere integrationer og grænseflader stadig er kompatible. Testmæssigt bør man adressere disse risici ved grundig præ-migreringsanalyse: gennemgå schema-differencer, kør dataprofilering for at finde værdier der vil bryde regler i det nye system, og afvikl evt. prøvemigreringer for at opdage inkompatible data tidligt.

• Performance-regressioner: Et ofte overset aspekt er systemets ydeevne efter migrering. Selvom funktionaliteten virker, kan responstider og kapacitet være dårligere i det nye miljø, hvilket påvirker brugerne negativt. Årsager kan være, at den underliggende database nu håndterer data anderledes (f.eks. manglende indeks på den migrerede database), at ny arkitektur introducerer latency (f.eks. ved cloud-migrering), eller at større datavolumen end forventet belaster systemet. Volumen af data er i sig selv en risiko: at migrere “big data” mængder kan medføre lange batch-vinduer eller overskride backup-vinduer. Typiske faldgruber inkluderer også, at batch-job eller rapporter, der kørte acceptabelt hurtigt før, nu timeouter eller kører for langsomt. For at imødegå dette skal testteamet udføre performance tests på det migrerede system – både load testing(simulere mange brugere/transactions for at måle svartid) og stress testing (presse systemet til det yderste for at se hvor det bryder). Det anbefales at sammenligne performance-målinger før og efter migrering: Ifølge anbefalingerne bør det nye/opgraderede system have samme eller bedre responstid end legacy-systemet. Hvis tests viser regression, skal tuning eller arkitekturjusteringer iværksættes før go-live. Desuden kan kapacitetstest (capacity testing) forudsige om det nye miljø kan håndtere fremtidig vækst i datamængde eller brugertal.

• Fejl i mapping og transformation: En klassisk fejlkilde i konverteringsprojekter er forkerte mapping-regler mellem kilde- og målsystem. Dette kan føre til data der havner forkert (f.eks. værdier byttet om mellem felter), eller forkert konverterede værdier (f.eks. valutafelt der ikke bliver omregnet, datoformat der forveksles, eller enhedskonverteringer som ikke er korrekt – tænkt på NASA’s berømte enheder-fejl). Flere kilder påpeger, at i migreringstests optræder andre typer fejl end i nyudvikling: Ofte er fejlene mere subtile – f.eks. at betingelser er inverteret, så en logik giver modsat resultat, eller at data er “flyttet til en anden placering” i strukturen. Sådanne logiske mappingsfejl kan være svære at få øje på uden en systematisk tilgang. For at afdække dem skal testanalytikeren udforme specifikke verifikationscases for alle mapping-regler: Hver kombination af input-output skal testes mindst én gang. Dette inkluderer grænseværdier som minimum- og maksimumværdier, tomme værdier, specielle koder osv. Parvist test og andre testteknikker kan hjælpe med at dække kombinationer af felter, der transformeres. Endvidere anvendes dual-run sammenligning: kør en kendt transaktion eller udregning i både det gamle og det nye system med samme input og sammenlign resultaterne – en uoverensstemmelse afslører, at en forretningsregel eller transformation opfører sig anderledes end før. Sådanne differencer skal undersøges; de kan indikere mapping-fejl eller bevidste ændringer, som så skal accepteres af forretningen.

• Driftsforstyrrelser og nedetid: Under selve migreringsovergangen er der risiko for betydelig nedetid eller forretningsforstyrrelse, hvis man ikke planlægger korrekt. “Cut-over” tidspunktet (hvor man skifter fra gammel til ny) er kritisk – eventuelle fejl her kan forårsage, at systemet er utilgængeligt længere end planlagt. Hvis migreringen f.eks. trækker ud over weekenden på grund af uforudsete problemer, kan det ramme næste arbejdsdag. Der er også risiko for inkonsistente data, hvis systemer køres parallelt: Hvis man migrerer data, men brugere stadig opdaterer det gamle system undervejs uden at disse ændringer kommer med over, kan der ske tab af de seneste transaktioner. For at reducere denne risiko bør testmanageren sørge for at teste migreringsprocedurerne i et testmiljø (generelprøve). Dette involverer at gennemløbe hele migreringsprocessen op til flere gange før den faktiske migrering – for at måle hvor lang tid det tager, hvilke fejl der opstår, og om rollback mekanismerne fungerer. Skal systemet sættes i read-only mode? Alle sådanne scenarier bør være en del af testplanen. Målet er at sikre, at eventuel nedetid minimeres og at der findes contingency plans (beredskabsplaner) hvis noget går galt (f.eks. evne til at falde tilbage til det gamle system, hvis det nye fejler kritisk). Testteamet skal verificere disse fallback-procedurer – f.eks. ved at simulere en afbrudt migrering og øve at rulle tilbage.

• Utilstrækkelig testdækning: En risiko er, at testteamet simpelthen ikke når at teste alle relevante områder af migreringen. Presset tidsplan eller undervurdering af kompleksiteten kan medføre, at man ikke får valideret visse datakategorier eller forretningscases. Konsekvensen er, at fejl dukker op i produktion. Dette er en faldgrube i mange migrationsprojekter, fordi fokus ofte er på selve dataflytningen og mindre på forretningsprocesserne omkring dataene. Testmanageren bør derfor gennemføre en risikobaseret testanalyse tidligt: identificér de mest kritiske datatyper og funktioner (baseret på forretningsrisiko) og prioriter testindsatsen på dem. En formel risikoanalyse med stakeholders kan kortlægge hvor fejl vil have størst impact, så testfokus afspejler dette. Ydermere bør testdækningen omfatte både funktionelle og ikke-funktionelle krav – det er en faldgrube kun at teste “om data kom over”, uden at teste eksempelvis rapporternes rigtighed, brugeroplevelsen eller sikkerhedsregler i det nye system. En sporbarhedsmatrix fra krav (inklusive migrerings-specifikke krav) til testcases kan hjælpe med at sikre, at intet overses.

• Andre faldgruber: Herunder hører bl.a. dårlig datakvalitet i kildesystemet – hvis legacy-data er mangelfulde eller fejlbehæftede, kan migreringen arve disse problemer eller endda forværre dem. Testteamet skal derfor inkludere data quality checks før migrering (f.eks. identificere dubletter, ugyldige værdier, referentiel integritet) og arbejde med forretningen om at rense data hvis nødvendigt. Sikkerheds- og compliance-risici er også centrale: Ved persondata skal man sikre, at GDPR overholdes i migreringsprocessen (ingen uautoriseret adgang til data under overførslen, logning af dataudtræk etc.), og at dataarkivering sker korrekt ved system-pensionering. Hvis data flyttes på tværs af landegrænser eller til cloud, skal compliance-afdelingen involveres. Endelig er mangelfuld brugerinddragelse en faldgrube – hvis de faktiske brugere først ser det migrerede system ved go-live, kan der opstå overraskelser. Brugeraccepttest (UAT) på det migrerede system er en vigtig aktivitet for at fange eventuelle forretningsmæssige mislyde inden systemet tages i brug.

Denne liste er ikke-udtømmende, men den illustrerer de typiske problemområder. En erfaren testmanager vil tidligt i projektet identificere disse risici og sikre, at de bliver adresseret i teststrategien og planlægningen.

Opgaver og ansvar i migrationstest

Migreringsprojekter kræver et tæt samarbejde mellem flere roller. Især testmanageren og testanalytikeren har centrale, men forskellige ansvarsområder under konverteringstest. Nedenfor beskrives deres respektive opgaver, både teknisk og organisatorisk, i forbindelse med migrationstest:

• Testmanagerens ansvar:
  Som overordnet ansvarlig for testindsatsen i migreringsprojektet skal testmanageren først og fremmest planlægge og styretestforløbet. Dette inkluderer udarbejdelse af en teststrategi/testplan specifikt for migreringen. Planen skal definere scope(hvad der skal testes – f.eks. data-konverteringsprocessen, funktionelle regressionstests, performance osv.), tilgangen (manuel vs. automatiseret, testteknikker), ressourcer og tidsplan. Ifølge standarder som ISO 29119 bør testplanen og testspecifikationer dokumenteres grundigt og gennemgås med interessenter. Testmanageren allokerer det rette team – ofte kræves specialiserede kompetencer til migrationstest, f.eks. databaseeksperter, testere med domænekendskab og måske værktøjsspecialister. Det kan være nødvendigt at afholde træning for testholdet i det nye systems teknologi eller forretningsområde, for at sikre at alle har viden om, hvad der migreres.

Et andet kerneansvar er risikostyring. Testmanageren skal tidligt facilitere risikoworkshops med de relevante interessenter (forretningsfolk, arkitekter, udviklere, drift etc.) for at identificere migrationsrisici og beslutte, hvordan de skal testes eller mitigere. For eksempel kan det komme frem, at det største risikoscenario er tab af transaktioner i en overgangsperiode – dette skal så adresseres med specifikke tests og måske procesændringer. Testmanageren prioriterer testindsatsen baseret på denne risikoanalyse, så de mest kritiske områder testes først og mest.

Koordinering er ligeledes en væsentlig del af testmanagerens rolle. Migrationstest involverer ofte flere parter – f.eks. udviklingsteamet der leverer migreringsscripts, infrastrukturteamet der håndterer miljøerne, forretningseksperter til accepttest, og evt. tredjepartsleverandører. Testmanageren fungerer som bindeled og kommunikationsknudepunkt: sørger for at alle ved hvornår tests finder sted (f.eks. planlægge et vindue til prøvemigrering i testmiljøet), at nødvendige dataudtræk fra produktion bliver stillet til rådighed (under hensyntagen til datasikkerhed), og at fejlmeldinger fra test hurtigt når frem til dem der kan rette dem. Under selve migreringsweekenden (hvis der er en sådan) vil testmanageren typisk etablere en war room eller kommandocentral for at overvåge progress og håndtere eventuelle issues i real-time.

Compliance og kvalitetssikring er også testmanagerens ansvar. Dette indebærer at sikre, at testprocessen følger relevante standarder og virksomhedspolitikker. Hvis organisationen har bestemte testframeworks (ISTQB-aligned processer eller ISO 29119 testprocesser), skal testmanageren sikre, at disse overholdes – f.eks. at der udføres formelle testgennemgange, at exit/entry kriterier defineres, og at testdokumentation er opdateret. I et migreringsprojekt kan compliance også betyde at sikre, at test af migreringen overholder lovkrav (f.eks. at der ikke testes med personfølsomme data i ukontrollerede miljøer – data masking kan være nødvendig). Testmanageren skal desuden sørge for, at der foreligger godkendelser og sign-offs fra de relevante parter før go-live. Eksempelvis skal forretningschefen muligvis formelt godkende, at data er korrekt migreret baseret på UAT-resultater, og drift skal godkende performance-testresultater. Testmanageren tilrettelægger denne acceptproces og indsamler dokumentation for testresultaterne, som kan fremvises ved evt. revision eller post-mortem evaluering.

Sammenfattende kan testmanagerens nøgleopgaver skitseres således:

• • Testplanlægning: Udarbejde migrations-teststrategi, estimere testindsats, planlægge testaktiviteter i forhold til projektplan.

  • Ressourceallokering: Sætte det rette hold, sikre nødvendige kompetencer og evt. træning.

  • Risikostyring: Identificere risici, prioritere test baseret på risiko, beslutte afbødende tiltag.

  • Koordinering og kommunikation: Orkestrere samarbejde mellem udvikling, drift, forretning; statusrapportering til projektleder og interessenter.

  • Miljø- og datahåndtering: Sikre at testmiljøer og testdata (evt. produktionsudtræk) er tilgængelige og opsat korrekt til migreringstest.

  • Overvågning af testudførelse: Følge op på testfremskridt, håndtere blokeringer, tage beslutning om go/no-go ift. test exit-kriterier.

  • Rapportering og kvalitetssikring: Dokumentere testresultater, fejlstatistikker, afvigelser; udarbejde testrapporter og få nødvendige sign-offs.

  • Overholdelse af standarder: Anvende relevante standarder og best practices (ISTQB, ISO 29119 etc.) i testdokumentation og processer.

• Testanalytikerens ansvar:
  Testanalytikeren (eller testspecialister under testmanageren) har det primære ansvar for detaljeret testanalyse, design og eksekvering inden for migrationsprojektet. Hvor testmanageren fokuserer på det overordnede “hvad og hvornår”, fokuserer testanalytikeren på “hvordan” de konkrete tests skal udføres.

En af de første opgaver er analyse af krav og konverteringsspecifikationer. Testanalytikeren sætter sig grundigt ind i migreringsomfanget: Hvad er forskellene mellem de to systemer? Hvilke datatyper skal konverteres, og hvilke transformationsregler er beskrevet? Ofte vil der foreligge en mapping-dokumentation mellem gammelt og nyt system – testanalytikeren gennemgår denne for at identificere potentielle svage punkter eller tvetydigheder, der skal testes. Forretningsregler der ændres under migreringen noteres også. Hvis sådan dokumentation mangler eller er ufuldstændig, må testanalytikeren arbejde sammen med udviklere og forretning for at udlede testbetingelser. For eksempel: “I det nye system er felt X obligatorisk; i det gamle var det tomt for 20% af posterne – hvad er forventet udfald? Skal de droppes, eller udfyldes med default? Dette skal testes.”

Dernæst udfører testanalytikeren testdesign – udarbejder konkrete testcases, testscenarier og valideringsteknikker. For datadelen vil det ofte betyde at definere SQL-udtryk eller scripts til validering. Testanalytikeren kan f.eks. designe en test for “Kontroller at summen af alle overførte kontosaldi er identisk i gammelt og nyt system” eller “Kontroller at antallet af kunder per land er det samme før og efter migrering”. For komplekse transformationer kan der designes reference-tests: giv kendte input til migreringsprogrammet og verificer at output matcher manuelt beregnede forventninger. På applikationsdelen vil testanalytikeren designe regressionstestcases med fokus på at sammenligne adfærd før/efter. Dette kan involvere udnyttelse af brugsscenarier fra det gamle system – ISTQB anbefaler at testerne samarbejder med systemets brugere for at forstå alle varianter af transaktioner, da legacy-dokumentation tit er mangelfuld. Testanalytikeren sikrer, at disse varianter bliver repræsenteret i testtilfældene.

Testdatahåndtering er et andet vigtigt element i testanalytikerens arbejde. For at teste migreringen realistisk skal man bruge relevante datasæt. Ideelt hentes produktionsekstrakter (anonymiseret hvis nødvendigt) for at teste med virkelige datafordelinger. Testanalytikeren skal specificere hvilke dataudtræk der behøves – f.eks. “vi skal bruge et dump af kunde- og kontotabellerne pr. sidste månedsskifte” – og sikre at data enten anonymiseres eller at der søges særlig tilladelse, hvis det indeholder personhenførbare oplysninger. Hvis produktiondata ikke kan bruges, må testanalytikeren generere syntetisk testdata der simulerer nøglescenarier (inklusive grænse cases). Dette kan kræve brug af datagenereringsværktøjer eller SQL-scripts til at skabe testdatabaser med de ønskede karakteristika. I en migrationstest skal testdata som minimum inkludere: 1) Typiske repræsentative data, 2) Ekstreme værdier og grænsetilfælde (for at teste robusthed af konverteringen), og 3) Dirty data hvis legacy-data er kendt for at indeholde fejl – for at se hvordan migreringsprocessen håndterer disse (blokeres de, logges de som fejl, rettes de automatisk?). Testanalytikeren planlægger også gendannelse af testdata mellem testkørsler – f.eks. at testmiljøets database rulles tilbage til et rent udgangspunkt inden næste testcyklus.

Under testudførelsen er testanalytikeren ansvarlig for at gennemføre testcases, dokumentere resultater og identificere defekter. I en datamigreringstest kan dette betyde at køre et script der sammenligner tusindvis af poster og så analysere differencerapporten for at forstå, hvilke forskelle der er reelle fejl. Testanalytikeren skal være i stand til at diagnosticere fejlene: er en mismatch pga. en fejl i migreringslogikken, eller skyldes det forventede ændringer (f.eks. at systemet nu automatisk udfylder et felt med en ny standardværdi)? Denne analyse kræver både teknisk forståelse og domænekendskab. Fundne defekter rapporteres i testværktøjet og følges op – testanalytikeren vil ofte arbejde tæt med udviklere (eller data engineers) for at forklare problemerne og få dem løst. For eksempel, hvis test afslører at alle postnumre over 9999 blev trunkeret, skal det rapporteres præcist, så udviklerne kan justere feltstørrelsen eller logikken.

En anden opgave er at specificere valideringsteknikker for forskellige slags tests. Testanalytikeren vælger hensigtsmæssige metoder: For store datamængder kan sampling være relevant nogle steder – men der skal fastlægges klare kriterier for udvælgelse af prøver (f.eks. 10% tilfældig sampling plus alle kritiske kunder). Alternativt besluttes at køre fuld sammenligning for visse kritiske tabeller vha. automatiske diff-værktøjer. Hvis der bruges automatiserede værktøjer (som f.eks. et ETL testværktøj), konfigurerer testanalytikeren disse – definerer reglerne i værktøjet for sammenligning (tillad måske at et timestamp-felt ignoreres, hvis det naturligt ændres). Testanalytikeren skal også tage stilling til ikke-funktionelle valideringer: f.eks. designe performance-scripts (hvilke transaktioner skal simuleres, hvor mange users, hvor længe) samt sikre at testmiljøet er passende (er det identisk med produktion mhp. performance? hvis ikke, hvordan skal resultaterne så tolkes?).

Endelig spiller testanalytikeren en stor rolle i dokumentation af testbasis og resultater. Alle testcases og deres forventede resultater skal dokumenteres tydeligt – især ved migreringstest, hvor revisionskrav kan være høje (man vil kunne bevise senere, at data blev korrekt overført). Testanalytikeren bidrager til testafslutningsrapporten ved at sammenfatte hvilke områder der er testet, hvor mange data der er valideret, og de fejl der blev fundet og rettet. Denne dokumentation er typisk en del af testkonceptet eller migrationsrapporten som testmanageren afleverer til projektledelsen for endelig accept.

I mindre organisationer kan samme person varetage begge roller, men i større migrationsprojekter vil der ofte være et testteam, hvor testmanageren og testanalytikere arbejder tæt sammen. Nøglen er klart rollefordeling, så alle opgaver – fra strategi til hands-on validering – bliver udført grundigt. Som Richard Seidl pointerer, kræver migrationsprojekter erfarne testledere og specialiserede testere, da testen skal planlægges omhyggeligt ned til mindste detalje, og der skal anvendes avancerede testværktøjer for at håndtere det store omfang af kode og data.

Best practices og værktøjer til konverteringstest

Erfaringer fra utallige migrationsprojekter har udmøntet sig i en række best practices – velafprøvede fremgangsmåder og teknikker – som kan guide testmanageren i planlægning og udførsel af konverteringstest. Her præsenteres nogle af de vigtigste best practices samt eksempler på værktøjer, der understøtter dem:

• Grundig foranalyse og planlægning: Start migrationstest-aktiviteterne tidligt i projektet. Så snart omfanget af migreringen kendes, bør testledelsen begynde at planlægge. En Migration Test Specification eller teststrategi-dokument bør udarbejdes, der klart beskriver testtilgangen, testområder, metoder (f.eks. om der bruges manuelle eller automatiserede tests), testtyper (funktionel, teknisk, performance, osv.), antal testrunder, tidsplan, brug af live data vs. syntetisk data, krav til testmiljø, kompetencebehov i teamet, osv.. Dette dokument gennemgås og godkendes af relevante interessenter, så alle er enige om, hvordan testen gribes an. Planen skal også inkludere entry- og exit-kriterier for hver testfase: f.eks. at et vist antal datafelter er verificeret uden fejl før man går videre. Ved at planlægge detaljeret kan mange faldgruber forebygges – f.eks. at have separate pre-migration og post-migration miljøer klar, at have et klart aftalt freeze-tidspunkt for dataændringer inden migrering, osv.

• Specialiseret testteam og domain knowledge: Sørg for, at testteamet har den nødvendige viden. Hvis migreringen vedrører et komplekst domæne (f.eks. en bank eller et hospitalsystem), er det værdifuldt at inkludere personer med domæneerfaring i testarbejdet – de ved, hvilke data der er kritiske, og kan lettere spotte “mærkelige” outputs. Overvej også at involvere dataejere eller forretningsbrugere i udvalgte tests. Best practice er at køre brugerdrevet accepttest på det migrerede system, hvor nøglebrugere verificerer at deres kerneopgaver fungerer som før. Dette øger tilliden til systemet markant ved go-live. Omvendt bør testerne også forstå teknikken bag migreringen: workshops med udviklerne af migrationsscriptsene kan være gavnlige, så testteamet ved hvordan data transformeres og dermed hvilke kontrolpunkter der er vigtige.

• Tidlige test af migreringsværktøjer (dry-runs): Inden den store migrering køres, bør man lave en eller flere testmigreringer(dry-run) i et testmiljø. Her kører man hele migrationsprocessen igennem end-to-end på et repræsentativt datasæt (helst en kopi af produktionsdata, hvis muligt). Formålet er at gennemøve procedurerne, tidsmåle processen og opdage fejl uden konsekvenser. Alle trin fra ekstraktion, transformation til load og efterfølgende verifikation køres som generalprøve. Testteamet skal definere succes-kriterier for dry-run (f.eks. “max 0,1% af poster fejler indlæsning, og disse kan begrundes individuelt”). Hvis kriterierne ikke mødes, justeres plan eller scripts, og en ny dry-run udføres. Dry-runs giver også mulighed for at tune ydeevnen – måske skal man f.eks. justere batch-størrelser eller paralleliseringsgrad for at få processen hurtigere.

• Automatiseret datareconciliation og brug af ETL-testværktøjer: Som tidligere nævnt er automatisering nøglen til at sikre fuld testdækning ved datamigreringer. Et centralt best practice er at anvende dedikerede ETL testværktøjer eller skripter til datareconciliation. Eksempelvis kan man bruge SQL-scripts til at sammenligne antal rækker i hver tabel, summen af vigtige numeriske felter, og tilfældige samples for hver tabel mellem kilde og mål. For mere avanceret sammenligning tilbyder værktøjer som QuerySurge, Datagaps ETL Validator, iCEDQ m.fl. mulighed for at definere forretningsregler for data og køre automatiske sammenligninger. De kan generere rapporter over afvigelser, som testerne så kan gennemgå. Fordelen ved disse værktøjer er indbygget support for store datamængder og kompleks logik (f.eks. sammenligne to datasæt med forskellige nøglestrukturer). Værktøjerne kan også integreres i kontinuerlige processer – f.eks. køre efter hver migreringsbatch. Data reconciliation bør ikke kun laves som en endelig aktivitet; det kan med fordel integreres løbende i etaper (f.eks. verificere tabel for tabel undervejs). Et godt tip er at begynde med små afgrænsede datamængder for at validere at scripts og værktøjer virker, inden de køres på fuld skala. Dette sparer tid når man når til de store volumener.

• Testautomatisering af forretningsfunktioner: Udover datareconciliation bør man automatisere funktionelle regressionstestsså meget som muligt. Hvis der findes et automation-framework (f.eks. UI-test med Selenium eller API-tests), bør det udvides eller genanvendes til at teste det migrerede system. Dette muliggør hurtig gentest af store dele af funktionaliteten. Det er især værdifuldt hvis man planlægger flere migrerings-cyklusser eller pilot-udrulninger – så kan samme testsuite køres hver gang og sammenlignes. Ved applikationsmigration kan man også overveje skærmbillede-baseret sammenligning: dvs. tage output fra legacy-systemet (rapporter, skærmudtræk) og fra det nye system for samme input og automatisk sammenligne dem for forskelle. Nogle testautomatiseringsværktøjer eller RPA-bots kan hjælpe med dette. Obs: Automation kræver investering – testmanageren skal afveje initial indsats mod gevinst. Men i migrationsprojekter, hvor næsten alt skal kontrolleres, er gevinsten ved automation som regel høj, fordi manuel kontrol af f.eks. millioner af datafelter er praktisk umuligt.

• Inkorporering af non-funktionelle tests: Best practice er at inkludere test af ikke-funktionelle krav som en integreret del af migrations-testplanen, ikke som en eftertanke. Udover performance-tests (belastning, stress) og sikkerhedstests, bør man teste pålidelighed og recoverability – f.eks. simuler strømafbrydelse eller netværksudfald under migreringen for at se om processen kan genoptages uden datakorruption. Også volumentest (volume testing) er relevant: migrér en ekstra stor mængde data for at se om systemet eller scriptsene kan håndtere det (dette kan afsløre memory-leaks eller grænser i værktøjer). Hvis det nye system skal sameksistere med gamle systemer i en periode, udfør kompatibilitetstest og co-existence test – f.eks. at ny og gammel applikation kan køre parallelt mod samme database i overgangsperioden uden konflikt. ISO 25010’s kvalitetsattribut portabilitet – udskiftelighed (replaceability) kommer i spil: det nye system skal kunne erstatte det gamle i driftsmiljøet nemt. Dette verificeres bl.a. ved at teste installationsprocedurer (installér den nye software i produktionslignende miljø og se om alt konfigureres korrekt) og eventuelle un-installation eller fallback procedurer.

• Kontrol af proces og dokumentation: En vigtig best practice er at behandle migrations-testaktiviteter med samme disciplin som andre testfaser, med fuld dokumentation og sporbarhed. Det vil sige, alle resultater af data-valideringer skal dokumenteres, f.eks. gem diff-rapporter, logfiler fra migreringskørsler (som viser evt. fejl eller advarsler undervejs), screenshots fra før/efter af nøgledata osv. Disse artefakter kan blive uvurderlige, hvis der senere stilles spørgsmål ved migreringens korrekthed (audit trail). Desuden bør man føre et migreringsdefekt-log separat: holde styr på alle problemer der opstod under test, hvad årsagen var (scriptfejl, datamangel, konfigurationsfejl, etc.), og hvordan det blev løst. Dette bliver en vidensbase, der kan bruges under den endelige live migrering – testteamet ved præcis hvilke faldgruber de skal være opmærksomme på, fordi de har set dem før. En testrapport skrives til sidst, som sammenfatter testforløbet – denne vil typisk indgå i den endelige go-live godkendelse.

• Involvering af interessenter og løbende feedback: En sidste best practice at fremhæve er at sikre løbende dialog med alle berørte parter under testforløbet. Migration berører typisk mange – fra forretningsbrugere, IT-drift, support, til ledelsen. Testmanageren bør udgive hyppige statusrapporter undervejs i test (f.eks. daglige under en intensiv migrations-testcyklus) for at formidle, hvad der virker, og hvad der er fundet af problemer. På den måde undgår man overraskelser. Desuden bør forretningen (eller kunde ifm. leveranceprojekt) få mulighed for at reviewe testresultaterne. For eksempel kan man præsentere en sammenligning af nøgletal før/efter migrering: “Totalt antal kunder: før 1.000.000, efter 999.950 – differencen på 50 er verificeret som lukkede duplikater, accepteret af forretningen.” Sådan gennemsigtighed opbygger tillid. Endelig: hav en klar sign-off ceremoni, hvor alle parter formelt godkender, at systemet er klar baseret på test. Det sikrer at ingen væsentlige bekymringer overses.

Standarder og rammeværk

Flere standarder og rammeværk kan hjælpe med at strukturere og kvalitetssikre arbejdet med konverteringstest. Testmanageren bør kende til disse og anvende dem hvor relevant, da de giver et fælles sprog og referencepunkter for testarbejdet:

• ISTQB-terminologi og koncepter: ISTQB (International Software Testing Qualifications Board) har i deres glossary og syllabus defineret mange af de begreber, der er centrale for migrationstest. Vi har allerede set definitionen på konverteringstest/migrationstest fra ISTQB’s ordliste. ISTQB Foundation syllabus beskriver også vedligeholdelsestest som inkluderer test ved migration og overgang, f.eks. at både ændret software og nyt miljø skal testes, samt at data-konvertering skal verificeres ved system-retirement. Ved at bruge ISTQB’s terminologi (som f.eks. “gentest og regressionstest”, “ikke-funktionelle kvalitetsattributter”, “testbetingelser” osv.) sikrer testmanageren en fælles forståelse i testteamet og overfor stakeholders. Desuden kan ISTQB’s generelle principper for test anvendes: f.eks. “risikobaseret testtilgang” hvilket vi allerede har adresseret, og vigtigheden af uafhængig test (herunder at få forretningen til at validere vigtige dele af migreringen uafhængigt). For testanalytikere og testmanagers findes ISTQB Advanced syllabi, som yderligere guider rollerne – f.eks. omkring testmanagerens opgaver ift. testplanlægning, estimering, risikostyring, og testanalytikerens opgaver ift. testteknikker og testdatahåndtering – alle disse generiske retningslinjer gælder også i migrationssammenhæng og kan med fordel følges.

• ISO/IEC/IEEE 29119 (Software Testing standardserien): ISO 29119 er en international standard for softwaretest, der indeholder flere dele: testprocesser, testdokumentation, testteknikker, m.v. Selvom den ikke specifikt nævner “migrationstest” i detalje, opstiller den rammeværket for, hvordan man driver et struktureret testforløb. Del 2 (Test Processes) beskriver en generisk testprocesmodel, som kan skræddersys til migrationsprojekter – dvs. man gennemløber de kendte faser: testplanlægning, testanalyse, testdesign, implementering, eksekvering, evaluering og afslutning, med de aktiviteter vi tidligere har gennemgået under hver fase. Del 3 (Test Documentation) er meget relevant: den indeholder skabeloner og indholdsanbefalinger for testplaner, testdesignspecifikationer, testrapporter mm. En testmanager kan bruge disse skabeloner til at sikre, at alle nødvendige emner bliver beskrevet. For eksempel vil en testplan ifølge ISO 29119-3 inkludere elementer som test scope, risici, strategi, ressourcer, milestones, og exit criteria – hvilket er lige hvad man behøver at dække for migrationstest. Hvis organisationen er ISO 29119-compliant, vil testmanageren udarbejde migrations-testdokumenterne i overensstemmelse med denne struktur. Del 4 (Test Techniques) beskriver forskellige testteknikker (ækvivalensklasser, grænseværdier, beslutningstabeller osv.) – testanalytikeren kan anvende disse til at sikre systematisk dækningsgrad i migrationstests (f.eks. identificere ækvivalensklasser af datatransformationer, grænseværdier for numeriske felter ved konvertering osv.). Kort sagt fungerer ISO 29119 som et overordnet kvalitetssystem for test, der også gavner migrationsprojekter ved at bringe orden og dokumentation i processen.

• ISO/IEC/IEEE 12207 (Software life cycle processes): Som tidligere nævnt adresserer denne standard migration som del af vedligeholdelsesprocessen. Den foreskriver bl.a., at der skal laves en migrationsplan med involvering af brugerne, og at aktiviteter som kravanalyse for migration, udvikling af migrationsværktøjer, selve konverteringen, migreringsverifikation og support af det gamle miljø skal planlægges. For testmanageren betyder det, at migrationstest ikke bør ses isoleret, men som integreret i den samlede livscyklus. Der bør være alignment mellem projektets livscyklus og testaktiviteterne. F.eks. når 12207 kræver en migrationsplan, bør testmanageren sikre at testafsnittet er en del af denne plan (eller en separat testplan der refererer til den). Standarden understreger også at der skal tages hånd om brugernes overgang og paralleldrift hvis nødvendigt – testmanageren kan herudfra argumentere for pilot-test og involvering af slutbrugere i accepttesten.

• ISO/IEC 25010 (Software product quality model): Denne standard definerer kvalitetskarakteristika for softwareprodukter, og den er nyttig som tjekliste for, hvilke kvalitetsaspekter migrationstesten skal dække. Nogle relevante kvalitetsattributter i migrationssammenhæng:

  • Funktionel egnethed – især funktionel korrekthed: Migreringen må ikke introducere funktionsfejl; systemet skal fortsat levere korrekte resultater med nødvendig præcision. Test af funktionel korrekthed vil f.eks. sige at alle beregninger med de migrerede data giver samme resultater som før, med samme nøjagtighed (jf. eksemplet om decimaler der ikke må mistes).

  • Pålidelighed – herunder modenhed (stabilitet), fejltolerance og gendannelighed. Efter migrering skal systemet være stabilt (ingen nye nedbrud pga. migrerede data), det skal kunne håndtere fejl graciøst (hvis visse data ikke migreres, crasher systemet så, eller håndteres det?), og man skal have mekanismer til gendannelse (f.eks. kunne køre migreringen om, hvis det fejler, uden datatab – test af rollback er i tråd med gendannelighed).

  • Ydelseseffektivitet – som inkluderer tidsadfærd og kapacitet. Vi har belyst performance-test som sikrer dette krav: ISO 25010 minder os om at det er en selvstændig kvalitet, der ikke må overses.

  • Kompatibilitet – inkl. sammenarbejdsevne (interoperability) og sameksistens. Dette er relevant hvis dele af det gamle og nye system skal køre sammen, eller hvis data fra det nye skal kunne bruges af andre systemer. Migrationstesten skal således også tænke på integrationer med eksterne systemer – f.eks. hvis data eksporteres i et bestemt format, gør de det stadig korrekt?

  • Sikkerhed – især integritet og fortrolighed af data. Under migrering er data ofte i bevægelse, måske midlertidigt ubeskyttet; test skal bekræfte at sikkerhedsforanstaltninger er effektive (kryptering, adgangskontrol). Efter migrering skal adgangsrettigheder i det nye system kontrolleres (ingen utilsigtet eskalation eller tab af rettigheder).

  • Portabilitet – herunder installérbarhed og udskiftelighed (replaceability). Som tidligere nævnt betyder udskiftelighed graden af nemhed hvormed et system kan erstatte et andet i samme miljø. Migrationstest skal demonstrere netop dette: at det nye system problemfrit kan tage over. En del af dette er at teste installations- eller deploymentsprocessen (kan systemet let deployeres i produktion?), samt at teste eventuelle co-existence scenarier (midlertidig sameksistens med det gamle).

Ved at bruge ISO 25010 som rettesnor kan testmanageren verificere, at testen ikke kun fokuserer på funktionelle aspekter, men også på disse kvalitetsegenskaber. Det sikrer en mere helhedsorienteret evaluering af det migrerede system. I praksis kan man lave en matrix over de relevante kvalitetskarakteristika vs. testaktiviteter for at sikre dækning – f.eks. at der er planlagt eksplicitte performancetests (ydelse), sikkerhedsscanning (sikkerhed), osv., som en del af migrations-testplanen.

Slutteligt skal det nævnes, at standarder er værktøjer og ikke et mål i sig selv. De skal anvendes pragmatisk. I et migrationsprojekt kan situationen ofte ændre sig undervejs, og så må testmanageren tilpasse processer fleksibelt. Men at kende og bruge de relevante standarder giver et solidt fundament – det hjælper med at argumentere for bedste praksis, sikre fuldstændighed i testdækning og dokumentation, og giver forankring i anerkendte principper som alle involverede kan forstå værdien af. En migrationstest, der udføres i tråd med etablerede standarder og rammeværk, vil alt andet lige have højere sandsynlighed for at lykkes første gang, fordi intet væsentligt bliver overset, og fordi kvaliteten er indbygget i processen fra start til slut.

Med ovenstående gennemgang står det klart, at konverteringstest er en kompleks disciplin, der kræver både teknisk dybde og organisatorisk overblik. For en testmanager handler det om at navigere denne kompleksitet ved hjælp af gennemprøvede metoder, aktiv risikostyring og et solidt kendskab til standarder – alt sammen for at sikre, at migreringen resulterer i et system der fungerer lige så godt (helst bedre) i morgen, som det gjorde i går, med alle data intakte og al funktionalitet på plads.