Domæner og syntetiske testdata

Forudsætninger

Ovenstående model beskrive propulering af syntetiske testdata ind et STAR testmiljø. Baggrunden for denne model er det er den tekniske mest enkle og kosteffektive og benytter sig derfor den moderniseret arkitektur. For denne arkitektur se https://starwiki.atlassian.net/wiki/spaces/MOI/pages/3650846897 og https://starwiki.atlassian.net/wiki/spaces/KON/pages/77570682. For STAR eksisterende (gammel) systemportefølje er der alternativer, men pga. omkostningsprofilen pga.

1. Større teknisk kompleksitet

2. Behov en “dobbelt“ implementering

3. Kort levetid i gammel arkitektur

bør disse overvejes i forhold gevinsten

Beskrivelse af flow

1. Første del er en træning af logikken der danner de syntetiske testdata. Træningen basere sig på rigtige data (form, model, om det er rigtige prod data, anonymiseret data m.v. er ikke beskrevet her)

2. De syntetiske test samles i en række synk pakker

3. Fra Synk pakkerne trækker adaptorne de syntetiske data og sikre data korrekt kommer ind i testmiljøet. Adaptorne sørge kvaliteten i de syntetiske testdata ved

   1. At data ligges ind den korrekte rækkefølge
      I modellen eksemplet ved først lave borgerstamdata, dernæst nødvendige forretningsdata på borger så som kontaktgruppe, visitationskategori m.f. og til sidst selve CV data

   2. At bruge forretningslogikken til at ligge data ind i form af servicekald eller eventbroker beskeder
      I modellen eksemplet ved at benytte eventbroker besked til borger stamdata og servicekald til nødvendige forretningsdata og CV data

   3. Der er et feedpack loop, skulle de syntetiske test ikke overholde forretningsregler i servicekald eller eventbroker beskeder, da disse vil retunere en fejl hvis der er problemer. Denne feedback bruges så til at forbedre logikke der danner de syntetiske testdata.

Fordelen ved model

• Den er fremtidssikret, da den benyttes STAR moderniseret arkitektur

• Den teknisk den mest simle at etablerer

• Den sikre bedste muligt kvaliteten af de syntetiske testdata

• Den udelukker ikke at det vil være muligt at kombinerer med syntetiske test i den gamle systemportefølje

• De laveste etableringsomkostninger

• Vi undgår at forbindelse med modernisering skal der ske en væsentlig omlægning af træningsmodel og adaptorer når de skal skiftes fra gl. til ny arkitektur

Ulemper ved model

• Den er tids- og implementeringsmæssig bundet til moderniseringen

• Den kan betyde at nogle test der går på tværs af forretningsmæssigt domæner først kan gennemføres på syntetiske test når alle berørte dele er moderniseret