STATUS - KLADDE UNDER UDARBEJDELSE.

Anvendes ved ændringer, der har betydning for eksterne.

Interne links (indhold i links ikke relevant for eksterne)

https://starwiki.atlassian.net/browse/TEK-260https://starwiki.atlassian.net/browse/TEK-259

Relevant baggrundsinformation om arkitektur og strategi:

Testbar arkitektur og test automatisering

STAR's strategi for test automatisering

Afgrænsning

Afgrænsning
Som STAR udvikler/tester/FA/PO har jeg brug at kunne sikre kvaliteten af STARs leverancer på effektiv og lovmedholdig vis. Hertil er der brug for følgende kapabiiteter, som skal dels udvikles, dels implementeres organisatorisk: Stabil test automatisering af forretningskritiske brugerrejser på tværs af STARs portefølje af systemer, herunder f.eks. Jobnet og multiple DFDG domæner (end-2-end tests). Nem on-demand konstruktion af GDPR lovmedholdige test data til test formål. Fleksible og effektive on-demand test miljøer, som eliminerer flaskehalse og sikrer, at forskellige full stack teams kan arbejde uafhængigt af hinanden (herunder i STAR 2.0 organiseringen) Særdeles mere effektive test værktøjer til testere i STAR (samt applikationsudviklere). Stærkt forbedret IT understøttelse af test behov for alle vidensarbejdere STAR samt udvalgte eksterne, som skal teste op i mod STAR (kommuner m.m.). Opbygning af initielle tværgående test suites i høj kvalitet, som automatisk regressionstester de vigtigste forretningsflows og hermed sikrer kvaliteten i fremtidige leverancer på kritiske områder. Arbejdet skal opdeles i faser, hvor fase 2 handler om udbredelse af systemunderstøttelse henvendt mod udviklere og fase 3 handler om udbredelse til øvrige personalegrupper, herunder udvikling i brugergrænseflader til ikke-udviklere. Arbejdet er en videreudvikling af tværgående test i DFDG (fase 1).  Open
Acceptkriterier
Nr.	Beskrivelse	Relevant for
1005.17.42b.1	Alle domæner, applikationer og interne afhænigheder er containeriseret og kan spinnes op i et Docker miljø (bortset fra DFDG Classic)	STAR
1005.17.42b.2	Automatiserede tests på tværs af applikationer/domæner kan afvikles på CI samt lokalt på udviklermaskiner	STAR
1005.17.42b.3	Kvaliteten af de automatiserede test suites skal være høj indenfor følgende parametere: høj forretningsmæssig værdi, stabil og korrekt afvikling (ingen falske positiver og ingen falske negativer), hurtig og parallel afvikling af tests samt at tests er nemme at konstruere og koden er forståelig. Den forretningsmæssige værdi opnåes ved, at test eksekveringen giver den ønskede indsigt i systemets kvalitet samt løbende sikrer at ændringer i systemet ikke resulterer i utilsigtede fejl.	STAR
1005.17.42b.4	Test data til én og samme test borger kan nemt oprettes i multiple forretningsdomæner (herunder nye Jobnet/Vitas domæner) uden, at udviklere/testere kender til domæne- og databasemodeller i de enkelte forretningsdomæner	STAR
1005.17.42b.5	Nyt software i STAR testbart (herunder automatiserbare, kontrolerbare og observerbare), så tests kan observere og manipulere systemet uden hvilket effektive tests ikke vil kunne fungere. Bl.a. skal tests sætte en bestemt initial tilstand før en test køres og testen skal kunne få events når en hændelse er færdig. For yderligere definition af testbarhed se kapitel 6 i STAR's strategi for test automatisering.	STAR
1005.17.42b.6	Der er oprette stamdata (grunddata) i de enkelte forretningsdomæner databaser, så landekoder, stillingsbetegnelser m.m. er til stede, uden at automatiserede tests skal beskæftige sig hermed	STAR
1005.17.42b.7	Der er oprettet en mindre test suite, som til dels tester de vigtigste forretningsmæssige flows, samt sikrer at testrammeværket er korrekt og komplet	STAR
1005.17.42.8	Vi skal nemt og effektivt kunne genbruge standardiserede test borgere (persona) i flere tests	STAR
1005.17.42.9	Testrammeværket er dokumenteret og der er gennemført vidensdeling på tvær af teams i Star City	STAR

Links i listen virker kun med STAR Jira konto og kan derfor ikke tilgås af eksterne. Links under Summary indeholder ikke andre oplysninger relevant for eksterne end hvad der fremgår i tabellen.

(kopiér og indsæt manuelt i tabellen)

Ikke synlig for eksterne, men indeholder ikke andre oplysninger end kopieret til den manuelle oversigt ovenfor.

Denne epic er oprettet ud fra et internt ønske om at sikre kvalitet, effektivitet (og GDPR overholdelse for test data) i hele STAR. Arbejdet er en videreudvikling af tværgående test i DFDG (fase 1), som er beskrevet i seperat epic. Nedestående figur viser sammenhængen mellem de forskellige faser, kapabiliteter, leverancer og målgrupper. Scope for denne epic er fase 2+3 !

Open

Tværgående test er en implementering af strategi for test automatisering udarbejdet af moderniseringsprojektet, dels af udviklingsdelen, dels af den organisatoriske implementering (forandringsledelse). Scope er dynamiske, funktionelle og tværgående tests. Resterende test aktiviteter håndteres af andre projekter. Se nedenstående figur for detaljer. 

Open

Ingen

Ingen ændringer i snitflader mellem DFDG domæner og eksterne aftagere.

På sigt vil denne epic give eksterne aftagere bedre muligheder for test op imod STAR's systemer. 

• Containerisering af Jobnet.

• Containerisering af Vitas.

• Containerisering af Taxonomy

• Containerisering af LSS

• Containerisering af øvrige applikationer 

• Azure Devops afvikling af tests i CI

• Konfigurationstyring så vi kan styre connectionstrings m.m

• Vi skal kunne køre på det seneste i master på CI

• Skal kunne nemt styre hvilke applikationer/domæner/containere som er oppe og nede.

• Paralleliseret testafvikling (plus check at det virker)

• Vi skal kunne køre lokalt mod specifik branch der ikke er i master

• Vi skal kunne angive specifikke versioner af alle domæner når vi kører

• Styr på hvordan vi venter hvor det ikke skal give problemer med test suiten hvis event mangler (testen skal blot fejle).

• Styr på timeouts (overskrivbar default).

• Simulering af events via eventbroker

• Vente på at systemet er fuldt ud startet op inkl. opdatering af heldbredscheck

• Styr på applikationer/domæner som ikke svarer

• Styr på exception beskeder og log filer (evt. log filer som arifaktor i PR)

• Foreløbig løsning på notifikation når async processen er færdig i et eller flere konkrete domæner/applikationer (endelig løsning afventer at vi får mere erfaring)

• Vi skal nemt kunne udlæse samlet ”streng” med alle versioner af et kørende system – det kan evt. senere kræve ændringer i frontends el. lign

• Wiremocks (subbe eksterne afhængigheder, såsom LetAsyl m.fl.)

• Endelig løsning for notifikation når async processen er færdig i et eller flere konkrete domæner uden at testen ved noget om hvilke events som er involveret internt

• Webhooks

• Standard test data fixtures (migrations)

• Udarbejdelse af ca 25 vigtige tværgående service test cases som involvere applikationer og domæner, herunder identifikation + prioritering af disse

• Udarbejdelse af ca 25 vigtige tværgående GUI test cases som involvere applikationer og domæner, herunder identifikation + prioritering af disse

• Programmering af ovennævnte test suites.

• Test data katalog klasse med persona o.s.v.

• Dokumentation i STARWiki og oplæring

• DFDG

  • Services

  • WSRMer

  • Kodelister

  • PersonStatusService (PSS) / domænespecifikke statusservices

  • PersonHistoryService (PHS) / domænespecifikke historik services

  • LSS (Landssupportsystem) og herunder Registerudtræk (hvis STAR har dataejerskab og der er lavet PHS på domænet)

• Jobnet

• VITAS

• JobKon

• JobAG

• JobSearch

• Ydelsesudstilling

• Taxonomy

• BI integrationsplatform

• Alle områder

  • Nye batchjobs

    • Dokumentation af jobbet til SF (jf. skabelon: xxx link til skabelon) 

  • Dataløft

    • Hvis der i Databaser tilføjes eller fjernes kolonner med personfølsomme data (f.eks. person navne, adresser, email, telefonumre etc.), så skal SF informeres så disse data fremadrettet tilføjes eller fjernes fra scrambling.

• Kommunalt sagsbehandlingssystem

• A-kasse sagsbehandlingssystem

• Kommunalt bookingsystem

  • WorkForcePlanner (WFP)

  • M4 Booking

  • Schultz Booking

• Kommunalt ydelsessystem (KY)

• Kommunalt sygedagpengesystem (KSD)

Test suites skal være i høj kvalitet, herunder nemme at vedligeholde og robuste (uden falske positiver).

Kun containeriseringen har konsekvenser for drift og dette håndteres af moderniseringsprojektet.

Der henvises til strategi for testautomatisering som beskriver arkitekturændringer.

Illustrationer, skærmdumps m.v. må ikke indeholde cpr.nr., CV. nr., rigtige personnavne på borgere eller deres kontaktoplysninger i form af e-mail, telefonnr., adresse m.v.

• Angiv hvem der har foretaget dette tjek: MMC

• Angiv dato for tjek: 05-06-2023

Denne epic tilføjer ingen nye nye dataområder eller nye data i eksisterende områder.

Denne epic tilføjer ingen nye oplysninger og ændre ikke på adgang til eksisterende oplysninger.

Denne epic tilføjer ingen webservices, som kan kaldes af andre organisationer.