Beskrivelse af epic af it-understøttelse af Styrelsen for Arbejdsmarked og Rekrutterings forretning

Versionshistorik af betydning for eksterne (v0.1, v0.3, v0.5 og v1.0)

Anvendes ved ændringer, der har betydning for eksterne.

N/A Christopher Juhl (Unlicensed)

Interne links (indhold i links ikke relevant for eksterne)

JOB-5006 - Getting issue details... STATUS

Indholdsfortegnelse

Afgrænsning af epic

Ingen eksterne snitflader

Oversigt over berørte webservices 

Manuel oversigt som er synlig for eksterne

Ingen eksterne snitflader

Beskrivelse af epic

Baggrund

Her udfylder PO oplysninger om baggrund for epic'en, herunder fx om der ligger politisk aftale eller lovgivning bag. Særligt vigtigt, at dette fremgår, hvis det ikke fremgår i en overliggende ISB, hvortil der evt. kan henvises.

STAR ønsker at udbygge anvendelsen af automatiserede tests ved brug af Leapwork, med det formål at styrke kvaliteten af det samlede produkt STAR sætter i produktion.

Testopgaven for STAR's udviklingsteams består i dag af såvel mange repetitions- opgaver som mere specialiserede tests af ny-udviklede funktioner. Samtidig udvides Test-opgaven løbende, hvor det er et krav, at it-løsningerne kan fungere i mange browserversioner og bliver responsive i stigende omfang.

Ved i første omgang at overføre testen af repetitions-opgaverne til Leapworks, frisættes tid og ressourcer til at komme bedre omkring de mere specialiserede tests. Senere skal der kigges på udvidelsesmuligheder.

Under denne EPIC fastsættes også nogle organisatoriske principper for den fremtidige brug af Leapwork, så de automatiserede tests bliver en integreret del af udviklingsteamets arbejde, fremfor et appendix.

Det er tanken, at suiten af leapwork flows skal indgå som en del af definition of done for et increment. Det vil sige, at hvis ikke leapworkflowet kører uden fejl i slutningen at et sprint, så kan arbejdet i sprintet ikke regnes for Done. Dette skaber incitament til at vedligeholde tests'ne, hvilket så igen medfører at fejl findes og rettes tæt på det tidspunkt, hvor de introduceres, hvilket igen øger produktiviteten og ikke mindst kvaliteten. 

Regler

Her udfylder PO oplysninger om eksisterende eller forventede regler om registrering og indberetning.

N/A Christopher Juhl (Unlicensed)

Forventet påvirkning af jobcenter-, a-kasse- eller ydelsessystemer

Her beskriver PO overordnet, hvordan epic'en forventes at påvirke aftagerne. Særligt vigtigt, at dette fremgår, hvis det ikke fremgår i en overliggende ISB, hvortil der evt. kan henvises.

N/A Christopher Juhl (Unlicensed)

Acc.kr. 1004.2.1 Der skal findes en testsuite af leapwork-flows, som eksekveres dagligt i Teamcity. 

Opsætningen af Team city job løses i   JOB-5408 - Getting issue details... STATUS . Derudover er udgøres stories i denne epic af de leapwork flows, der tilføjes til test suiten. 

 Følgende skal være gældende:

1. Der skal eksistere en Jobnet/JobAG suite, som eksekveres hver nat/dagligt i TeamCity.

2. Det skal være Jobnet-teamet, som selv monitorerer testsuiten og udbedringen af fejl.

   1. Der skal opsættes en automatisk notifikation som orienterer teamet i tilfælde af fejlede tests.

3. testsuiten skal ikke være blokerende for deploys.

1. Opsætte test suiten i team city med minimum én test

Test suiten findes her: https://tc.startest.dk/project/Test_Leapwork_Borger?mode=builds

Acc.kr. 1004.2.2 Der skal findes en dokumentationsskabelon for dokumentation af leapwork-testflows. 

Løses i  JOB-5467 - Getting issue details... STATUS . 

Dokumentationen findes her: /wiki/spaces/CITY/pages/3437658157

Ideen med dokumentationsskabelonen er, at det skal være let for nye folk at blive onboardet, samt let for resten af et teams medlemmer at være medarbejdere på Leapwork-flows. Derudover er det for at sikre at alle nødvendige informationer bliver dokumenteret rutinemæssigt ved implementering af nye flows. 

1. Dokumentationen skal forklare LeapWorks flows i dybden

2. Dokumentationen skal give et overblik over, hvilke flows hvori de forskellige subflows bliver brugt

3. Dokumentationen skal give et overblik over hvilket data, der er behov for i de forskellige flows

4. Dokumentationen skal give en skabelon for fremtidig dokumentation, således at dokumentationen bliver standardiseret

5. Der skal findes en how-to, der beskriver hvordan man udfører standard-opgaver, eksempelvis at udskifte typisk anvendte parametre.

(Her indsættes link til dokumentationen, når EPIC er done)

Acc.kr. 1004.2.3 Testene skal være robuste overfor login og skal generere sin egen testdata og rydde testdata op efter sig efter kørsel. 

Løses i  JOB-5400 - Getting issue details... STATUS , for så vidt angår login. Derudover er dette acceptkriterium et, der gennemsyrer alle tests i testsuiten, og dermed alle stories i epicen. 

Det er helt centralt for at få værdi ud af flows'ne, at de ikke kræver for meget vedligehold. 

1. Sub-flowet skal kunne bruges i alle eksisterende og fremtidige flows.

2. Sub-flowet skal dokumenteres så fremtidig vedlighold bliver gjort lettere.

3. Sub-flowet skal selv generere det data det skal bruge til at gennemføre login.

Særlige krav til test

Ingen særlige krav til test. Christopher Juhl (Unlicensed)

Konsekvenser for drift/idriftsættelse

ingen konsekvenser Christopher Juhl (Unlicensed)

Arkitektur- og implementeringsnoter 

Christopher Juhl (Unlicensed)

Husk GDPR stillingtagen

Ingen personfølsomme data i epics

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.

•  Ja, det er tjekket, at epic ikke indeholder dette.

• Angiv hvem der har foretaget dette tjek: Christopher Juhl (Unlicensed) og Josephine Risager Pedersen (Unlicensed)

• Angiv dato for tjek: 15 Dec 2021 

Opbevaring af oplysninger i STARs it-systemer

Ved oprettelse af nye dataområder skal der tages stilling til, hvornår formålet med data ophører og dermed fastlægges en slettepolitik.

Ved indførelse af nye data på eksisterende dataområder skal GDPR slettejobs opdateres.

Ingen nye data Christopher Juhl (Unlicensed)

Hvem må tilgå oplysningerne?

Afsnittet må ikke blot slettes, hvis det vurderes ikke relevant. Det skal dokumenteres at man har forhold sig til nedenstående.

Husk det er hensynet til borgeren der tæller højst. Der skal være hjemmel til at sagsbehandler må tilgå oplysninger. Formålet skal være som led i administrationen af beskæftigelsesreglerne eller ydelsesadministration.

  Ingen nye data Christopher Juhl (Unlicensed)

Korrekte sikkerhedsattributter på services

PO skal for hver enkelt servicemetode angive hvilke myndighedstyper, der må kalde de forskellige servicemetoder.

Tilladte organisationer (eksempel - se den fulde liste over myndighedstyper på siden DFDGs sikkerhedsmodel )

ej relevant, Christopher Juhl (Unlicensed)

A-kasse filtrering

Hvis a-kassen må anvende metoden, må a-kassen så se / hente alle data? Eller skal der foretages filtrering ift. at a-kassen fx kun må se nogle udfaldsrum / kodelisteværdier? Husk at filtreringen skal ramme eventuel visning på Jobnet aht. sagsbehandlerlogin

ej relevant, Christopher Juhl (Unlicensed)

Sagsbehandlerlogin på Jobnet - tag stilling til adgang!

En sagsbehandler i et jobcenter kan tilgå en borger tilknyttet det konkrete jobcenter.

En sagsbehandler i en a-kasse kan tilgå en borger, som er medlem af a-kassen og KG 1 (tilmeldt og ikke-tilmeldt) eller KG 8 og tilmeldekategori 5 - dimittend.

Begrænsninger kan foretages via (a-kasse-) filtrering, eller ved at afgrænse på action niveau på konkrete sider på Jobnet.

Stillingtagen: Beskriv kort, at der er taget stilling til sagsbehandlerlogin

ej relevant, Christopher Juhl (Unlicensed)