Testdata og miljøer

As-Is beskrivelse af Det store integrerede Testmiljø, AUIT (2019(

Noter, spørgsmål og forslag til Continuous improvement til ejerne af AUITs Testindsats

Formål med Testmiljø

Der er flere formål med miljøet.

Hovedformålene er, nu hvor dette skrives i dec. 2019:

1.1 Integrations-tests for komponenter udviklet af AUITs udviklere.

1.2 System-test og system-integrations-test mellem nyudviklede og allerede eksisterende services op mod nye eller eksisterende systemer.

1.3 SKAL-opdateringer ved rettelser af produktionsfejl.
Proceduren er Først i udviklingsmiljø, så i Testmiljø og derefter i Produktion.

  
Fordi miljøet er det eneste AUIT har omkring integrerede systemer, så bruges miljøet i større eller mindre grad også til:

2.1 Deployment-test af nye systemer med nye services - inden produktions-deployment . 

2.2 Test af patchninger og funktionsrettelser af systemer i forvaltning.

2.3 Test af data-initialisering af nye data-mapninger og til nye systemer.

2.4 Performancetest.

2.5 Forretningens brugertest, usecase-tests og user-acceptancetest.

2.6 Forretningens slutbruger-test og -undervisning.

2.7 Ad hoc Testmiljø for komponenter/applikationer - når nu miljøet er til stede …

2.8 Deployment-test af versionsopgraderinger af systemer.

2.9 Udviklings-Testmiljø for AUIT-webudviklere - fordi deres værktøj pt. ikke er funktionsdygtigt i Udviklingsmiljøet. 

Testmiljøet bruges, som man kan se, til mange forskellige formål. Og antal test-aktiviteter er stigende. 

Dermed er antal af perioder med konkurrerende aktiviteter stigende. Bare i 2020 skal vi i gang med de nye Studiesystem, LMS, og DigiEksamen samt en ny Auhra.

Se nærmere om risici i afsnit neden for.
 

Under udarbejdelsen af indeværende beskrivelse udviklede vi et Diagram over det store miljø.

Der mangler måske en ansvarlig for at holde miljøet integreret.
 

Under udarbejdelsen opstod der også ideen om eventuelt at oprette yderligere testmiljøer, således at testniveauerne kunne få 'renere' miljøer at udføres i.
Hvis vi engang får opsplittet det integrerede miljø i 2 dele - et staging-miljø og et integrations-testmiljø, så er overvejelserne i note om SOA og miljøet højst relevante.

Testindsatsen har lavet en sammenstilling af udviklernes Testniveauer og niveauernes placering i Testmiljø i et særligt dokument. Her ses bl.a. de 3 hovedtyper af testaktiviteter, der nu foregår i Testmiljøet.
  

Det er i øvrigt en vurdering (se Gartners A Litmus Test for Business Applications), at behovet for et integreret testmiljø øges generelt.
Et klip om virksomheders vurderinger:

• On average, 19% of the total spend of their ERP project was, is or will be spent for integration. Ten percent of the respondents estimate that this expenditure was, is or will be greater than 35% of the total spend.
• On average, 21% of the total spend of their CRM project was, is or will be spent for integration. Sixteen percent of the respondents estimate that this expenditure was, is or will be more than 35% of the total spend and a few (3%) estimate more than 45%.

…

• Application leaders must be able to justify the money spent on integration technologies and skills in terms of business benefits, typically some combination of innovation, agility, insights and efficiency outcomes.

Aftale om miljøets levetid 

Miljøet holdes kontinuerligt kørende.

Det er nødvendigt for AUITs testaktiviteter.

Og i det samarbejde om udvikling, som AU har med eksterne leverandører i f.eks. fremmede lande, så bliver behovet for miljøet egentlig en oppetid 24-7.

Hele miljøet tages enkelte gange ned - til repopulering af miljøet med data fra produktion.
Læs mere her om processen for repopulering.

Enkelte systemer og dermed dele af miljøet tages ned ved forvaltning, patchning og deployment.

Disse aktiviteter indvirker forstyrrende på testaktiviteter.

Man kunne måske indføre Servicevinduer til den slags aktiviteter.

Governance

Noter, spørgsmål og forslag til Continuous improvement til ejerne af AUITs Testindsats

Testmiljøejer

AUIT drift eller udvikling.

Der er ikke én ejer men et samspil med ejere/ansvarlige af de testmiljøer der indgår i Det store integrerede testmiljø.

Er der behov for at udpege et egentligt ejerskab over den samlede systemopsætning, der kaldes Det Integrerede Testmiljø?

Findes der f.eks. en Integrations-ejer, der har ansvar for de samlede integrationer?

Testmiljø driftsansvarlig

Der er ingen én person udpeget.

Systemforvaltning for de enkelte miljøer er principielt ansvarlig for systemets testudgave.

De systemansvarlige er også ansvarlige for systemet i testmiljøet.
Og de integrationsansvarlige (oftest udviklere) er det også for integrationerne i test.

Martin Smith har beskrevet det som,
at Miljøet er drevet af Det Store Kollektiv

Ledelsen bør overveje, om det er en udfordring, at der ikke er nogen, der har driftsansvar for det samlede integrations miljø.

Testmiljø datasamlingsansvarlig
(tænk GDPR)

Hvem giver adgang til miljøet.
Hvem er ansvarlig for data-sikkerhed.

Samme forbehold som oven for.

Systemforvaltning for de enkelte miljøer er principielt ansvarlig også for test-adgang til data.

AUIT har i 2018 udarbejdet retningslinjer for, hvordan Sikker udvikling og sikker håndtering af testdata skal foregå.

Idet testmiljøet i høj grad indeholder kopi af produktionsdata, så medfører det, at oprettede testbrugere i de forskellige systemer kan have adgang til de aktuelle produktionsdata, som det testsystem de arbejder med giver adgang til. 

På den side ses også hvilke krav systemforvaltningen skal opfylde. Herunder står der, at testdata skal registreres og der er beskrevet en procedure til det.

Det bliver Testindsatsen og/eller AUIT-drift, der må følge op på, om disse retningslinjer bliver overholdt.

Dette bør indgå i Systemforvaltnings-dokumentation for hvert system.

Skabelonen for Systemforvaltning har længe indeholdt  forslag til et afsnit om testmiljøer og testbehov. Men der er brug for at styrke udfyldelsen af afsnittet.

Testindsatsen har programsat en besøgsrunde til systemforvaltninger med diskussion af testforvaltning.

SLA for testmiljø

de ansvarlige er interessenter til en SLA,
som sætter rammen for hvad de andre sætter i værk

Der er når dette skives ingen systemforvaltningsaftale eller SLA omkring miljøet.

Miljøet vedligeholdes
- delvist af systemforvaltningen for de involverede systemer.
- delvist af udviklere og projektansvarlige for nyudvikling.

Det forventes, at udviklere, testere, projektansvarlige og systemansvarlige indbyrdes aftaler, når der skal ske justeringer og ændringer, der involvere større dele af testmiljøet. 
Der er ingen selvstændig koordinering af dette.

Se ovenfor om systemforvaltning.

Pt er der kun en  sporadisk koordinering af brugen af (og dermed af ændringerne i) systemet.

Pt er der en vis kalenderstyring af miljøet.
I løbet af februar 2020 vil beskrivelsen af denne kalenderstyring blive moderniseret.

Forslag: Hvis en testaktivitet booker miljøet i en periode, så er den ansvarlige person samtidig et kontaktpunkt for øvrige rekvirenter med henblik på at give akut eller kortvarig adgang til miljøet alligevel. 

 RFC for Testmiljø

For både kodeændringer, dataændringer

men også for deployment:
både til produktion
men også nye test-sammenhænge

Der udarbejdes pt ikke dokumentation for effekten på miljøet af kommende ændring i kode eller data.

Interessenterne aftaler indbyrdes efter bedste evne og erfaring.

Udmelding om større changes foregår via Systemchef-Forum.
Og måske kan det nyligt dannede Forum for forvaltning også inddrages.

I løbet af 2019 er der fremkommet en række forslag til mulige initiativer angående changes:

• Indfør service-vinduer til patchning og opgraderinger af miljøets systemer.
• Sæt system i informationer til interessenter, for når der sker kode- eller dataændringer i miljøet.
• Tag relevante dele af produktions-RFC i brug også i testmiljøet.

Det er op til AUIT-ledelsen og evt. fremtidige projekter at overveje, hvordan der kan findes tid og ressourcer til sådanne tiltag.

Beskrivelse af Datasamling:
Initialisering - repopulering

Repopulering kan bestå af en blanding af

• kopi af data fra produktion
• opbygning af testdata fra andre kilde-systemer
• konstruerede data til aktuelle testformål

Data i de systemer, der indgår i det integrerede Testmiljø forsøges holdt således at:

• Data i de tættest integrerede systemer holdes så vidt muligt integrerede, således at objekter i det ene system svarer til samme objekt i det andet system.
  (se senere definition af tættest integrerede)
• Ethvert testforløb har ret til at oprette egne testdata - også når integrationen mellem disse data ikke holdes opdateret hele vejen rundt.
  Dermed vil der over tid opstå dataobjekter eller attribut-indhold, der ikke svarer til indholdet i alle de tilstødende systemer.
• Der findes pt ingen hurtige metoder til at 'rulle tilbage' og dermed genoprette objekt-integrationen.

Testdata repopuleres i ny og næ med data, der svarer til data i produktion.
Det sker især, når store nye integrationsprojekter har brug for en sikkerhed for, at dataobjekterne svarer til hinanden mellem systemer og/eller når der til testformål er brug for aktuelle udgaver af data.
Repopulering sker efter systematiske aftaler med interessenterne/systemforvaltningerne.

Seneste repopuleringer blev foretaget:
- nov. 2018 (i anledning af projekt Tjek and Go)
- feb. 2019 (i anledning af projekt Uddannelses og eksamensplanlægning)  

I løbet af 2019 er der fremkommet en række forslag til mulige initiativer angående changes:

• Indfør at enhver testaktivitet skal kunne tilbageføre datasamlinger til oprindelig status.
• Indfør at ethvert system udarbejder rutiner til at gen-initialisere testsystemet med relevante testdata - under hensynstagen til disses integration med de øvrige systemer i miljøet.
• Ovenstående er nok for meget at forlange af alle systemer, men måske de afhængige systemer kunne indføre en procedure for: repopulering af mit system med de aktuelle data fra de tættest integrerede systemer.

Det er op til AUIT-ledelsen og evt. fremtidige projekter at overveje, hvordan der kan findes tid og ressourcer til sådanne tiltag.

Produktets system(er) og AUIT-leverancer i dette Testmiljø, som dette system er ejer af

Det integrerede Testmiljø er en samling af
- integrationssystemer (hjertet i eller mekanikken bag integrationerne)
- tæt integrerede systemer (indgår som primære datakilder til integrationerne)
- løsere integrerede systemer (aftagersystemer)

Se beskrivelse i de næste linjer for hver samling.
Heidbra tager udgangspunkt i tankerne bag hendes diagram over integrerede systemer fra dec.2019.

Under udarbejdelsen af indeværende beskrivelse udviklede vi et Diagram over det store miljø.

Mange samtaler med mange involverede personer tog udgangspunkt i dette diagram - og dets opdeling af testmiljøet i 'Hjertet af intetgrationerne', 'De tættest tilknyttede systemer' og 'de afhængige systemer'. (se mere i de kommende afsnit).

I de fleste af samtalerne skulle folk lige tænke sig om, inden de accepterede Heidbras tanker om ÉT samlet miljø. De enkelte udviklere og testansvarlige arbejder typisk i en mindre del af miljøet.

Man véd godt, at de andre systemer også er der, men man tænker måske ikke altid over, hvor tæt integreret vi har behov for, at miljøet faktisk er.

SOA-systemet, med konfigurationer og egne data samt service-'kontrakter' mellem systemer.

IDM-systemet, med drivere, Userapps og workflows op mod diverse systemer samt data om personer, roller og organisation.

Dele af Aros datasamlingen (hjælpetabeller, mellemtabeller ol).

Datasamlinger og hjælpetabeller i Auhra og Stads.

Auhra (med egne frontends)
Stads (med Stadsapplikationer og frontends)
UniAD
Aros applikationsdata (Enhedsregister, Funktionsvaretagelse, IDM-common ol)
Medarbejderstamkort (som frontend til Auhra og IDM)
Mit.au.dk (til adgangsstyring af brugergrupper og som frontend)
MitStudie.au.dk bliver nok også en del af de tættest integrerede 

Listen er lang - og der kommer hele tiden nye til. Her kan som eksempel nævnes:
PhD Planner, WorkZone, BlackBoard, Digital eksamen, Ldaps, UniExchange (og der er flere).
Og som nye fra 2019: Undervisning og eksamensplanlægning, Dalux, Emply, MoveOn.

I Heidbras diagram over tilknyttede systemer, så indgår der ca. 15 aftagersystemer. Det er de systemer, som blev involveret i repopuleringen i feb. 2019.

På  AUs Reolen, i listen over integrerede systemer, indgår der cirka 50 systemer. 
Så der er 30 systemer, der er endnu løsere knyttet til det Store Integrations Testmiljø end de her nævnte aftagersystemer.

Evt. eksterne leverandører og samspil med deres installation eller data.

Der er eksterne leverandører til stort set alle systemer i testmiljøet.

Herunder driftes nogle af systemerne (og deres testmiljøer) af den eksterne leverandør.

I alle disse tilfælde er det vigtigt, at samspil og ansvarsdeling er beskrevet i:

• udviklingsaftaler mellem leverandør og AUIT.
• de enkelte systemers Systemforvaltnings-aftale.

AUIT er leverandør af rigtig mange af de services, drivere, scripts og koder i øvrigt, der binder systemerne sammen i den ønskede integration.

Men der er også eksterne leverandører, der har services kørende 'i deres ende af systemet', som er afhængige af at kunne kalde eller aktivere services i vores ende af miljøet.

I hvor høj grad skal disse situationer beskrives i indeværende dokument?

Testmiljøets relation til tilsvarende installation i produktion

versionering
konfigurationer
data
ny kode og gammel kode

Systemerne i testmiljøet er ofte men ikke altid af samme version som i produktion.

Nogle gange har systemansvarlig ikke fået opdateret testudgaven til nyeste version.
Nogle gange er der nyinstalleret en nyere version, der er i test og er på vej ind (det sker).
Enkelte gange findes systemet ikke i produktion, fordi det er nyt og på vej ind for første gang.

Nogle gange er de services og andre integrationskoder, som AUIT leverer, af en nyere version end i produktionsmiljøet - og disse er nogle gange fejlbehæftede, netop fordi de er under aftestning.

Systemer i testmiljøet holdes så vidt muligt konfigureret på samme måde som i produktion.

Data i systemer i testmiljøet afspejler til en vis grad data i produktion.
Se afsnit oven for.

Applikation(er)
Frontends o.l.

Mange af systemerne kommer med egne frontends og applikationer.

Udviklere har gennem deres udviklingsværktøjer adgang til metoder for at initiere og følge databevægelser. Se retningslinjer i førnævnte Sikker udvikling og sikker håndtering af testdata.

Egne datasamlinger(r)

Prod-kopi af data og/eller nye testdata til testcases

Systemforvaltning for de enkelte miljøer er principielt ansvarlige også for test-adgang til data.

I testmiljøet er der særligt behov for adgangsstyring af testere - fra udvikling, drift og forretningsbrugere.

Der bruges flere metoder til at vedligeholde disse lister.
Noget sker gennem systemernes database-adgangsstyring.
Noget sker gennem integrationernes konfigurationer og kalde-mekanikker.
Noget sker gennem brugerhåndteringen i test-UniAD.
Noget sker gennem særlige adgangstabeller i Aros (f.eks. til Medarbejderstamkortet)

Det er i høj grad udviklere og projektansvarlige, der vedligeholder disse grupperinger af testfolk.

AUIT har i 2018 udarbejdet retningslinjer for, hvordan Sikker udvikling og sikker håndtering af testdata skal foregå.

Det er en kendt udfordring, at testadgange sjældent slettes. 

Adgangsstyring er derfor et særligt issue i forhold til 'forvaltning af det samlede testmiljø'.

Måske skulle vi indføre en form for logning af, at der kan sikres sporbarhed af adgangen til de systemer, der indgår i miljøet.

Mulige tiltag

Forstyrrelse i og mellem systemer ved brug af det aktuelle miljø

Skab større kendskab til sammenhængen i det samlede miljø.

Skab større viden i det hele taget om, hvilke testforløb skal eller skal ikke udføres i det integrerede miljø.

Genopbyg udviklings-testmiljøet for webudviklerne. 

Skab kommunikationsforum for meddelelser om ændringer mellem de testansvarlige.
Udvid evt. brugen af
 #AU IT Test og Udvikling driftsmeddelelser <TestDriftsMedd.IT@list.au.dk> 

Vejled vores systemansvarlige i, hvordan de skal håndtere 'brugerhenvendelser' om fejl i testmiljøet.

Data-sammenhæng mellem integrerede systemer kan brydes hvis:

Et udviklingsforløb aftester nye datastrukturer og -mapninger, der indvirker på omliggende systemer. 

Som ovenfor.

Data-sammenhæng mellem integrerede systemer kan brydes hvis:

Det ene testforløb indsætter egne testdata, der ikke integreres som håbet til omliggende systemer. 

Som ovenfor. Desuden:

Integrations-brud af data kan ikke undgås, så længe miljøet bruges til så tidlig kode-test som nævnt i formålsbeskrivelsen (pkt 1.1, 1.2, 2.2, 2.3, 2.7, 2.9).

Så længe vi ikke har metoder til at 'rulle test-inddateringer' tilage, så må vi nok leve med det.

Men på sigt ville det være godt med en 'repopulering af de ønskede testdata'.

Data-sammenhæng mellem integrerede systemer kan brydes hvis:

Det ene testforløb ændrer i testdata således, at testdata i andre systemer forstyrres.

Gør ejer af aktuel kalenderreservation ansvarlig for at forhandle med øvrige rekvirenter om at give plads i kalenderen.

Vejled alle interesserede i, hvordan kalender-reservationerne skal håndteres.
Der bør laves vejledning til de ansvarlige ejere af reservationen.
Og der bør laves vejledning til dem, der ønsker adgang til et reserveret miljø.

En første udgave af disse vejledninger udformes i feb. 2020 og skal derefter udbredes til de rette parter.

Under udviklingsforløb skal testmanager/testere lave klare aftaler om, hvilke typer af tests og fejlrettelser, der kan ske samtidig.

Selv når det drejer sig om skal-opdateringer eller små-rettelser fra andre systemer, så skal disse orientere sig om, hvorvidt der er reservationer af afhængige systemer i kalenderen. I givet fald skal der forhandles med den kalenderansvarlige, hvornår der kan gives kalenderplads til rettelserne. 

Som ovenfor.

Man kunne måske indføre Servicevinduer til den slags aktiviteter.

Og som tidligere nævnt:

Gør ejer af aktuel kalenderreservation ansvarlig for at forhandle med øvrige rekvirenter om at give plads i kalenderen.

Vejled alle interesserede i, hvordan kalender-reservationerne skal håndteres. Både når man 'ejer' miljøet i kalenderen og når man ønsker adgang til miljøet.

Den bedste løsning ville være at indføre et staging-miljø. Se skitsen til forslag i dette dokument for 'de 4 niveauer af testmiljøer'.

Det næstbedste er at performance-tests koordineres i god tid med den aktuelle kalenderejer af miljøet.

Persondata & GDPR

Begrænsning af dataudvalg

Fordi dette er Det Integrerede TestMiljø, så er det vigtigt, at data-objekterne hænger sammen på tværs af systemer. Derfor bør alderen/versionen af testdata i det ene system svare til alderen/versionen i det andet system.

Anonymisering

Fordi det er så vigtigt, at data-objekterne hænger sammen på tværs af systemer, så skal identiteter og andre nøgle-referencer mellem systemerne svare til og kunne knytte sig til hinanden.

AUIT og systemforvaltningen har ikke en metodik til at sikre dette på anden vis, end ved at kopiere disse identiteter og nøgle-referencer fra produktion over i alle systemerne i testmiljøet.

AUIT-Sikkerhed har tidligere godkendt denne procedure. Men man ER klar over, at den fulde produktions-kopi ER problematisk. 

Og med nye sikkerhedsforordninger som f.eks. GDPR stilles der større krav til sporbarhed, retten til at blive glemt ol.

Og i det hele taget er det et problem, at oprettelsen og manglen af nedlæggelse af testbrugere er så ukontrolleret. Oprettede testbrugere har adgang til de aktuelle produktionsdata, som det testsystem de arbejder med giver adgang til. 

Databehandleraftaler

Systemforvaltningen bag hvert system og/eller projektledelsen for et nyt system har ansvaret for at udarbejde databehandleraftaler inden for dét system.

Forvaltere af de tættest integrerede systemer skal være særlig opmærksomme på, at der kan opstå indirekte integrations-effekter ved indførsel af nye systemer. Alle data-interessenter skal inddrages hver gang.

Et muligt spørgsmål til DPO kunne være:
Hvad skal der til, for at Testmiljøet overholder og følger GDPR?

AUIT-sikkerhed har det generelle ansvar for at påpege IT/System-ricisi.

AU's DPO (Data Protection Officer) har friheden og pligten til at påtale omstændigheder omkring perondata.

Loven siger:
En påtale fra DPO betyder, at AUITs ledelse skal forholde sig til påtalen.