master test plan - star · arbejdsmarkedsstyrelsen · a-kassekommunikation via webservices ·...

Knowledge Cube A/S · Bernstorffsgade 50, 7. sal · DK 1577 København V · T +45 33 98 46 00 F +45 33 14 46 00

CVR 28 51 04 89 · www.knowledgecube.net · [email protected]

ARBEJDSMARKEDSSTYRELSEN - A-KASSEKOMMUNIKATION VIA WEBSERVICES

MASTER TEST PLAN

VERSION 1.43

DATO 30. maj 2012

REFERENCE Anders Ellegaard Dahl

FORFATTER Nicolai L. Nielsen

KONTRAKTNUMMER SF099

Slettet: ARBEJDSMAR-KEDSSTYRELSEN

Slettet: A-KASSEKOMMUNIKATION VIA WEBSERVICES

Slettet: MASTER TEST PLAN

Slettet: 1.

Slettet: 22. maj 2012

Slettet: Nicolai L. Nielsen

Arbejdsmarkedsstyrelsen · A-kassekommunikation via webservices · Master Test Plan ·

Version 1.3 · 30. maj 2012

Side 2 af 29

DOKUMENTVERSIONER

Version Dato Initialer Afsnit Ændringer

1.0 25. april 2012 NLN Alle MTP for test i forbindelse med A-Kasse kommunikation via webservices.

1.1 26. april 2012 NLN Alle Opdateret med GetAbsenceVersion6 samt workflows afledt af sygeraskprojektet. Samt opdateret på baggrund af kommentarer fra AMS

1.2 7. maj 2012 NLN 10 Ændringer til personskema. Organisator ret-tet til KMD

1.3 22. maj 2012 TN 2.1, 7.1.1, 7.2.1, C, D

Konsekvensrettelse i forhold til versionering af GetAbsence samt tilføjelse af GetLatestIn-terviewDate. Tilføjet JC for testdata for KMD (tidl. Organisator).

1.4 30. maj 2012 TN Fjernet workflows afledt af syge/rask-projektet, herunder er GetAbsence rettet til version5. Der henvises nu til LB 3.3 ASE er flyttet til testslot 13.


Version 1.3 · 30. maj 2012

Side 3 af 29

INDHOLDSFORTEGNELSE

1 INTRODUKTION 5

2 TEST ITEMS 5

2.1 Fase 1 webservices 5 2.2 Event flows 6 2.3 Funktionscertifikater 7

3 PLAN FOR TESTAKTIVITETER 8

4 TEST TILGANG 9

4.1 Gentest og regressionstest 11 4.2 Rapportering af fejl 11 4.3 Test faser for AMS leverandører 12 4.3.1 Fabriksprøven 12 4.3.2 Accept kriterier 12 4.3.3 Afvikling af den interne integrationstest 12 4.4 Test faser for eksterne aftagere 13 4.4.1 Afvikling af komponenttest hos A-kasser 13 4.4.2 Afvikling af den eksterne integrationstest med A-kasser 13

5 PERFORMANCETEST 14

6 RELEASE HÅNDTERING 14

6.1 Releaseplan 14 6.2 Release notes 14 6.3 Release Leveranceprocedure 14 6.4 Release miljøsikring 15

7 TESTMILJØER 15

7.1 Testmiljø - T2 URL (intern integration/kundetest) 15 7.1.1 Fordeling af kommuner og jobcentre 15 7.2 Testmiljø - T3 URL (ekstern integration) 16 7.2.1 Fordeling af kommuner og jobcentre 16 7.3 Testmiljø – T8 URL (SF/AMP Build Verification/Deployment) 17

8 LEVERING AF TESTDATA 17

8.1 Konfiguration af testmiljøer (WSRM) 18

9 TEST STATUS 18

9.1 Statuskategorier 18 9.2 Test metrikker 18 9.3 Testrapportering 18 9.4 Mødeoversigt 19 9.5 Generelle accept- og stopkriterier 19


Version 1.3 · 30. maj 2012

Side 4 af 29

10 ORGANISERING 21

10.1 Personskema 21 10.2 Ansvarsskema 21 10.3 Procesgodkendelse 22

A GLOSSARY 23

10.4 Aktører 23 10.5 Begreber 24

B DOKUMENTSTRUKTUR 25

C DET OVERORDNEDE SCOPE FOR TESTEN I FASE 1. 26

D WORKFLOWS DER BØR EFTERPRØVES AF A-KASSERNE I INTEGRATIONSTESTEN. 27


Version 1.3 · 30. maj 2012

Side 5 af 29

1 Introduktion Dette dokument beskriver rammerne for testen af AMS projekt A-kassekommunikation via webservices og be-skriver dermed hvad der skal testes, samt hvis ansvar det er at udføre de respektive tests. Det primære formål med denne testplan er at klargøre hvilke testmæssige tiltag der er nødvendige for at sikre at de af kunden og leverandøren definerede krav til A-kassekommunikation via webservices overholdes. Master Test Planen er et vigtigt holdepunkt for alle involverede aktører. Det er derfor nødvendigt, at alle aktører læser testplanen igennem og forholder sig til indholdet. Afsnit 2: indeholder alle test items, altså de elementer, der skal testes i forbindelse med A-kassekommunikation via webservices, samt hvordan hvert enkelt element skal testes. Afsnit 3: beskriver testtilgangen; hvordan den strukturerede test skal afvikles, hvordan fejl skal rapporteres og gentestes, samt hvordan der skal regressionstestes. Afsnit 4: beskriver de forskellige testfaser, hvem der er ansvarlige for hvad, samt hvornår er der planlagt mile-pæle og leverancer. Afsnit 5: Omhandler performance test og tilgangen til dette. Afsnit 6, 7 og 8: omhandler releases, testmiljøer og håndtering af testdata. Afsnit 9: beskriver teststatus, kontrol og rapportering på testfremdriften i form af metrikker, skriftlige statusrap-porter, møder osv. Afsnit 10: beskriver hvordan testprojektet er organiseret og hvem der er involveret.

2 Test Items

2.1 Fase 1 webservices

ID Testområde Metode Ansvarlig Miljø

F1WS01 Systemtest (funktionel) af webservices – Intern Integra-tionstest

Automatiseret test KC KT2

F1WS02 Systemtest (funktionel) af A-kasse funktioner der aftager webservice – Komponenttest.

Manuel test A-Kasse leveran-dør

KT2

F1WS03 Integration mod udstillede webservices – Ekstern Inte-gratrionstest

Manuel test A-Kasse leveran-dør / KC

KT3

Procedurekrav

Alle test cases udformes med udgangspunkt i IEEE 829 standarden og leveres i Microsoft Word format in-den testens begyndelse.

Test cases skal være reviewet inden testafviklingen begynder. Alle afvigelser fundet under testen skal registreres i FogBugz. Testen dokumenteres i test summary rapport.


Version 1.3 · 30. maj 2012

Side 6 af 29

Afhængigheder

Testen af dette test-item forudsætter at følgende er klar til test: Det fælles datagrundlag Webservices A-Kasse integration mod webservices Funktionscertifikater WSRM opsætning jf. afsnit 8.1 Konfiguration af testmiljøer (WSRM)

Funktionalitetsoversigt

Yderligere informationer omkring beskrevne funktionalitet kan ses i dokumentet LB99_AMS_A-kassekommunikation via webservices_løsningsbeskrivelse_fase1_v33

DFDG- hændelse Beskrivelse af hændelse

Webservice-understøttelse:

T, A T: Tilmelding af person i jobcenter A: Afmelding af person i jobcenter eller ophør af medlemskab i a-kassen

(WSRM) GetUnemploymentEnrollmentVersion4 GetLatestInterviewDate (WSRM) GetCancelUnemploymentEnrollmentVersion4

C CV kundenummer eller CV status æn-dres.

(WSRM) GetCVStatusVersion4

F30 Servicebesked om oprettelse eller æn-dring af Jobplan

(WSRM) GetJobplanStatusVersion1

F31 F32 F33 F34

Servicebesked om sygdom, raskmel-ding, ferie eller mindre intensiv indsats. Der kan også være registreret en opdate-ring eller sletning af hændelsen.

(WSRM) GetAbsenceVersion5 og GetDeleteAbsenceVersion5

A-kasseskift og udmelding (MA og MT)

Skift af a-kasse Udmelding af a-kasse Fremsendelse af uafsluttede fraværsfor-hold(servicebeskeder) ved a-kasseskift

Bl.a. (WSRM) GetMembershipCancellation

CodeListService A-kasse kan oprette adgang til Code-ListServer og hente relevante Codelister.

CodeListService

WSRM-kø A-kasse kan åbne, tømme og afslutte WSRM-køen korrekt

2.2 Event flows


EvtFl01 Funktionel test af understøttelsen af event flows – Intern integrationstest

Kombination af ma-nuel og automatiseret webservice test

KC KT2

EvtFl02 Funktionel test af event flows – Ekstern Inte-grationstest

Manuel test A-Kasse leverandør / KC

KT3

Procedurekrav

Alle test cases udformes med udgangspunkt i IEEE 829 standarden og leveres i Microsoft Word format inden

Slettet: 6

Slettet: 6

Slettet: 41


Version 1.3 · 30. maj 2012

Side 7 af 29

testens begyndelse. Test cases skal være reviewet inden testafviklingen begynder. Alle afvigelser fundet under end-to-end test registreres i FogBugz. Testen dokumenteres i test summary rapport.

Afhængigheder

Testen af dette test-item forudsætter at følgende er klar til test: Det fælles datagrundlag Webservices A-Kasse integration mod webservices Funktionscertifikater WSRM opsætning jf. afsnit 8.1 Konfiguration af testmiljøer (WSRM)


T: Tilmelding af person i jobcenter A: Afmelding af person i jobcenter eller ophør af medlemskab i a-kassen C: CV kundenummer eller CV status ændres. F30: Servicebesked om oprettelse eller ændring af Jobplan F31/F32: Medlemmet er meldt syg/rask F33: Servicebesked om feriemelding F34: Mindre intensiv indsats Sletning af F31/F32/ F33/F34 A-kasseskift

Yderligere informationer om de enkelte flows kan ses i appendix D - Workflows der bør efterprøves af a-kasserne i integrationstesten.

2.3 Funktionscertifikater


FCert01 Funktionel test af brugen af Funktionscertifi-kater

Manuel test A-Kasse leverandør

KT2/3

Procedurekrav

Alle test cases udformes med udgangspunkt i IEEE 829 standarden og leveres i Microsoft Word format in-den testens begyndelse.

Test cases skal være reviewet inden testafviklingen begynder. Alle afvigelser fundet under end-to-end test registreres i FogBugz. Testen dokumenteres i test summary rapport.

Afhængigheder

Testen af dette test-item forudsætter at følgende: Afvikling af test mod test items 2.1 & 2.2 Forudsætninger for brug at funktionscertifikater er opfyldt jf. LB99_AMS_A-kassekommunikation via web-services_løsningsbeskrivelse_generelt_v30


Funktionscertifikater: Der skal anvendes et funktionscertifikat pr. a-kasse, der skal have adgang; dvs. en a-kasse skal bruge netop et funktionscertifikat. A-kasse-leverandører med flere a-kasser på samme a-kasse system skal således også bruge et


Version 1.3 · 30. maj 2012

Side 8 af 29

funktionscertifikat pr. a-kasse. Testafviklingen gennemføres som en del af den beskrevne test mod items 2.1 & 2.2, således at funktionscertifi-katerne anvendes i denne test og derved indirekte testes.

3 Plan for testaktiviteter Følgende afsnit indeholder en oversigt over testafvikligen med de enkelte A-kassser.

Aktivitet Startdato Slutdato

Intern Integrationstest (KC) 15-06-2012

A-kasse test fase 1 slot 1 18-06-2012 20-07-2012



Test Slot A-kasse A-kasse System Kommentar


Version 1.3 · 30. maj 2012

Side 9 af 29

nummer

A-kasse test fase 1 slot 1

1.1 17 FOA Eget system

1.1 15 3FA Facilia

1.1 76 Danske Sundhedsorg. A-kasse Facilia

1.1 95 Dana Facilia


1.2 14 Socialpædagoger Winnie/KMD

1.2 24 Metalarbejdere Winnie/KMD

1.2 34 Næring mv. Winnie/KMD

1.2 53 HK Winnie/KMD

1.2 62 Dansk funktionærforbund Winnie/KMD

1.2 72 Teknikernes A-kasse Winnie/KMD

1.2 81 BUPL Winnie/KMD

1.2 82 Business Danmarks A-kasse Winnie/KMD

1.2 91 Akademikernes A-kasse Winnie/KMD

1.2 92 Funkt. Og Tjenestemænd Winnie/KMD

1.2 83 Frie funktionær Eget system


1.3 94 ASE Eget system

1.3 10 Journalistik mv. Tieto/Modulus

1.3 18 Danmarks Lærere Tieto/Modulus

1.3 37 El-faget Tieto/Modulus

1.3 40 Byggefagene Tieto/Modulus

1.3 57 Arbejdsløshedskassen STA Tieto/Modulus

1.3 86 Ingeniørernes A-kasse Tieto/Modulus

1.3 88 Magisternes A-kasse Tieto/Modulus

1.3 98 CA Tieto/Modulus

1.3 22 Danske Lønmodtagere Tieto/EMO

1.3 67 Ledernes A-kasse Tieto/EMO

1.3 73 Kristlig A-kasse Tieto/EMO

4 Test tilgang Som en del af udviklingsarbejdet vil der med sikkerhed blive introduceret fejl i løsningen eller integrationen til nogle af de øvrige systemer. Efter der er blevet testet, fundet fejl og rettet fejl, vil der være behov for yderligere

Slettet: 1.1

Slettet: 94

Slettet: ASE

Slettet: Eget system

Slettet: 1


Version 1.3 · 30. maj 2012

Side 10 af 29

tests. For at tage højde for denne ekstra testindsats, tager den strukturerede test udgangspunkt i en "three pass" strategi for testafviklingen, der er baseret på, at planlagte test cases afvikles over tre iterationer som en del af den formaliserede test. ”Three pass” strategien gælder for struktureret test på alle testniveauer, og gennemføres efter følgende princip.

Figur 2: Integrationstest over 3 iterationer.

Det overordnede formål med hvert enkelt af de tre testgennemløb er kort beskrevet herunder.

Test Pass 1 (P1)

Formål

Alle planlagte test cases udføres mindst en gang med henblik på at finde så mange af de fejl, der er i den udviklede løsning. Alle fejl oprettes i FogBugz og sendes til den, der har ansvaret for at rette de identificerede fejl. Der udfø-res løbende gentest og regressionstest efter behov, eksempelvis i forbindelse med miljøsikringer.

Entry kriterier Exit kriterier

Testmiljø klar Udviklet funktionalitet klar Testprocedurerudarbejdet og reviewet

Alle planlagte test cases er gennemløbet Alle fejl er dokumenteret i FogBugz Test log leveret med oversigt over testens forløb

Test Pass 2 (P2)

Formål

Alle test cases der er fejlet udføres mindst en gang med henblik på at verificere rettelser i løsningen, og derved sik-re at disse gentestes. Alle fejl oprettes i FogBugz og sendes til den, der har ansvaret for at rette de identificerede fejl. Der udføres løbende gentest og regressionstest efter behov, eksempelvis i forbindelse med miljøsikringer.


Teststatusrapport for P1 udført og afleveret Alle åbne Fogbugz-sager efter afslutning af P1

Alle planlagte test cases er gennemløbet Alle fejl er dokumenteret i FogBugz


Version 1.3 · 30. maj 2012

Side 11 af 29

skal være analyseret Test log leveret med oversigt over testens forløb

Test Pass 3 (P3)

Formål

Alle planlagte test cases udføres en gang med henblik på at verificere, at rettelser ikke har introduceret nye fejl i løsningen. Alle fejl oprettes i FogBugz og sendes til den, der har ansvaret for at rette de identificerede fejl. Der ud-føres løbende gentest og regressionstest efter behov, eksempelvis i forbindelse med miljøsikringer.


Teststatusrapport for P2 udført og afleveret Alle åbne Fogbugz-sager efter afslutning af P2

skal være analyseret

Alle planlagte test cases er gennemløbet Alle fejl er dokumenteret i FogBugz Test log leveret med oversigt over testens forløb

Hvis der til stadighed findes fejl i det 3. test pass bør man overveje gennemførelsen af endnu et test pass.

4.1 Gentest og regressionstest Gennem alle testfaser har leverandøreren ansvar for at genteste rettelser til fundne fejl. Regressionstest benyttes løbende igennem hele testforløbet, hver gang fejl fundet under test bliver rettet. Det er de enkelte leverandørers ansvar at udføre regressionstest, samt at vurdere hvornår dette er nødvendigt. Derudover udfører Systemforvalter begrænset regressionstest (miljøsikring) af AMS systemkompleks, når der lægges ny kode i testmiljøer. Regressionstest gennemføres som et absolut minimum som afslutningen af en test fase. Dette gøres for at sikre at man ikke ødelægger eksisterende funktionalitet (eller genintroducerer gamle fejl) i forbindelse med implemente-ringen af nye features eller fejlrettelser.

4.2 Rapportering af fejl Den grundlæggende proces ved rapportering af en fejl (bug) i FogBugz er vist i Figur 4. For yderligere informa-tion henvises til forvaltningshåndbogens afsnit 3. https://dokumentationsarkiv.knowledgecube.net/Forvaltning/Forvaltningshaandbog.pdf

Figur 4: Grundlæggende rapportering, rettelse og gentest af fejl i FogBugz.

https://dokumentationsarkiv.knowledgecube.net/Forvaltning/Forvaltningshaandbog.pdf�


Version 1.3 · 30. maj 2012

Side 12 af 29

4.3 Test faser for AMS leverandører I de følgende afsnit beskrives de test faser, som er relevante for AMS leverandører.

4.3.1 Fabriksprøven I forbindelse med udvikling hos AMS leverandører, er den enkelte leverandør ansvarlig for at kvalitetssikre alle leverancer inden levering til AMS testmiljøer. Testfasen skal sikre, at alle leverancer har en kvalitet så de kan te-stes i det samlede systemkompleks.

4.3.2 Accept kriterier

Accept kriterier


FogBugz projekt oprettet Kravspecifikation/løsningsbeskrivelse dæk-

kende alle features er klar

Alle leverancer er kvalitetssikret inden leverance til AMS testmiljøer (KT2/KT3)

Der foreligger en reviewet Master Test Plan (dette dokument)

4.3.3 Afvikling af den interne integrationstest Integrationstesten afvikles, som beskrevet i afsnit 3, over 3 iterationer. Alle iterationer skal være gennemført og der skal være taget stilling til alle fundne fejl for at integrationstesten kan godkendes. Integrationstesten skal afvikles fra den grænseflade, som slutbrugeren skal benytte og testen skal afvikles i AMS KT2 testmiljø. Accept kriterier

Accept kriterier


AMS Testmiljøer klar Udviklet funktionalitet klar Testprocedurer er udarbejdet og reviewet

af Systemforvalter Dokumentation klar - Kravspecifikation

opdateret

Alle test cases, der direkte (og udelukkende) afprøver integrationen i interne systemer er udført mindst 3 gange (jf. 3-pass strategi).

Alle test cases, der direkte afprøver integrationen i in-terne systemer, og som også skal udføres under inte-grationstest for eksterne systemer, er udført mindst en gang.

Aktører

Aktør Inddragelse

AMS • Deltager på teststatusmøder

SF • Deployments til testmiljøer

KC • Udførelse af test cases • Fejlretning • Dannelse af testdata • Verificering af korrekt testudførelse gennem udarbejdelse og verificering af testdata og –

cases. • Deltage i teststatusmøder


Version 1.3 · 30. maj 2012

Side 13 af 29

4.4 Test faser for eksterne aftagere I de følgende afsnit beskrives de test faser, som er relevante for eksterne aftagere.

4.4.1 Afvikling af komponenttest hos A-kasser A-Kasser er selv ansvarlige for at udføre en komponenttest af deres applikationer inden starten på integrationste-sten mod AMS KT2/3 testmiljø. For at den eksterne integrationstest kan startes er det en forudsætning at komponenttesten er afsluttet på tilfreds-stillende vis. Dvs.: Alle planlagte komponent test cases er gennemført. Blokerende fejl i A-kasse systemerne er rettet og gentestet.

4.4.2 Afvikling af den eksterne integrationstest med A-kasser Integrationstesten afvikles, som beskrevet i afsnit 3, over 3 iterationer. Alle iterationer skal være gennemført og der skal være taget stilling til alle fundne fejl for at integrationstesten kan godkendes. Derudover skal der ugent-ligt være afleveret test statusrapporter og en opdateret testlog. Integrationstesten skal afvikles i leverandørens system – fra business laget eller fra den grænseflade, som slut-brugeren skal benytte. Testes der på business laget skal leverandøren sikre at der fra grænsefladen, som slutbru-gerne skal benytte, kan udføres de test cases, som er planlagt i end-to-end testen. Leverandørens system skal væ-re integreret mod AMS KT3 testmiljø. Der må ikke benyttes stubbe/mocks objekter/detours. Hvis der benyttes testautomatisering, skal test cases være implementeret så de testes på det øverste lag – det lag som slutbrugeren skal benytte applikationen fra (dvs. der må under ingen omstændigheder testes direkte på OLTP/Service/Webservice lag). Accept kriterier

Accept kriterier


Systemforvalter: Testmiljøer klar Testprocedurer er udarbejdet og reviewet

af Systemforvalter WSRM opsætning er gennemført

Eksterne:

Testlog som beskriver status på afviklede komponent test cases er afleveret til AMS/Systemforvalter

Funktionscertifikater er klar WSRM bestilling er gennemført

Alle test cases, der vedrør integrationen med eksterne systemer, er udført mindst 3 gange.

Der forligger en testlog for hver ekstern aktør, der dokumenterer resultatet af den eksterne integrations-test.

Der er leveret en testrapport til AMS, der dokumente-rer og vurderer resultatet af den samlede, eksterne in-tegrationstest.

Aktører

Aktør Inddragelse

AMS Deltager på teststatusmøder

SF Deployments til testmiljøer

KC KC vil deltage aktivt i dette testforløb og være inddraget i følgende testaktiveteter: • Dannelse af testdata


Version 1.3 · 30. maj 2012

Side 14 af 29

• Afvikling af kørsler - f.eks. af batchjobs • Verificering af korrekt testudførelse gennem udarbejdelse og verificering af testdata og –


A-Kasser • Udførelse af test cases • Fejlretning • Verificering af korrekt testudførelse gennem udarbejdelse og verificering af testdata og –


5 Performancetest Der vil ikke blive gennemført performance test som en dal af testen der ledsager A-kasse test

6 Release håndtering Herunder synliggøres omfang og håndtering af releases til testmiljøer under testforløbet.

6.1 Releaseplan Starten på testforløbet vil naturligt involvere rettelser af fejl, og det vil derfor være nødvendigt at foretage relea-ses oftere. Jo tættere man kommer på release-dato, jo færre releases vil der forekomme. NB! A-kasse kommunikation via webservises er ikke en selvstændig release, og er derfor ikke beskrevet i en se-parat release plan. Features i forbindelse med A-kasserne er indeholdt i AMS releases 2012-1 & 2012-2 De planlagte releases kan findes på Systemforvalters Sharepoint, under ”Release dokumentation > Testmiljø-plan

6.2 Release notes Når en Bug ’resolves’ i FogBugz, skal den tildeles en specifik release (milestone) således at den person, der er ansvarlig for at lukke sagen, kan se, hvornår en given rettelse kan gentestes i et testmiljø. Det er ligeledes vigtigt, at leverandørerne opretter en release note til sagen i Fogbugz, når sagen løses, der i klart sprog beskriver hvordan fejlen er løst. Systemforvalter sørger for at danne en samlet release note til hver release i testperioderne. Denne release note di-stribueres til alle aktører, således at alle har et samlet overblik over hvilke fejlrettelser, der er med til en given re-lease. Den samlede release note dannes på baggrund af et releasenoteudtræk fra FogBugz. Dette udtræk foretages på releasedagen kl. 10.00, hvorfor alle release notes skal være påført løste sager senest kl. 09.30.

6.3 Release Leveranceprocedure Leveranceprocedurerne som følger:

Leverance til SF for AMP og Jobnet Levering af installationspakker (vejledninger, kode, DB scripts) skal ske senest 18:30 dagen inden release (man/ons). Se skema for procedure:

Miljø Senest levering fra UL (man/ons)

Installation (tirs/tors)

Miljøsikring (ons/fre)

Klarmelding (ons/fre)

KT2 KL. 18:30 Kl. 22:00 Kl. 03:00 KL. 09:00


Version 1.3 · 30. maj 2012

Side 15 af 29

KT3 KL. 18:30 Kl. 21:00 Kl. 04:00 KL. 09:00

KT4 KL. 18:30 Kl. 22:00 Kl. 05:00 KL. 09:00

KT9 KL. 18:30 Kl. 21:15 Kl. 07:00 KL. 09:00 Løbende vil der tirsdag/torsdag tentativt blive installeret og miljøsikret automatisk i AMS testmiljøer fra klokken 22:00 – dvs. uden for normal arbejdstid. Der vil på installationsdagen blive udsendt en announcement senest klokken 15:00 og status for installation udsendes klokken ca. 09:00 den efterfølgende dag.

6.4 Release miljøsikring Ved hver release skal der foretages en miljøsikring af alle systemer for at sikre, at der ikke er blokerende fejl i det installerede. Der laves automatisk en miljøsikringsrapport, som vil udgøre beslutningsgrundlaget for godken-delse eller en eventuel ny release. Hvis der findes blokerende fejl, beslutter Systemforvalterens Release Manager om der skal foretages en ny installation. Når en release til et testmiljø er godkendt, udsendes der en announcement på Systemforvalters Sharepoint (do-kumentationsarkivet) – det samme gør sig gældende, hvis en planlagt release forsinkes.

7 Testmiljøer Hvert af testmiljøerne består af en fuld kopi af arbejdsmarkedsportalen, Jobnet og SAS/BI platformen. Der benyttes følgende testmiljøer til test af A-kassekommunikation via webservices:

• KT2 - benyttes til Integrationstest til de interne systemer. • KT3 - benyttes til Integrationstest til eksterne systemer. • KT8 – benyttes til Build Verification Deployment hos Systemforvalter

7.1 Testmiljø - T2 URL (intern integration/kundetest) Herunder er URL’erne til testmiljø T2 angivet for henholdsvis Arbejdsmarkedsportalen og Jobnet: Dette testmiljø benyttes til integrationstest af de interne systemer, samt til Kundetesten.

Testområde Testmiljø

Arbejdsmarkedsportalen

• amportalT2.knowledgecube.net • serviceT2.knowledgecube.net • printT2.knowledgecube.net • okoT2.knowledgecube.net • viT2.knowledgecube.net

Jobnet

• CVBank: https://job-kt2.jobnet.dk/cv • Jobbanken: https://job-kt2.jobnet.dk/jobbanken • CVAdmin: https://cvadmin-kt2.jobnet.dk/CV_admin/

Resurseplanlægger • amportalT2.knowledgecube.net (link på AMP forsiden)

7.1.1 Fordeling af kommuner og jobcentre Konkret vil testdata bestå af adgang til et antal medlemmer fra en given a-kasse, hvor det vil være muligt at ud-føre de til fase 1 understøttede forretningsmæssige operationer via (test-udgaverne af) Arbejdsmarkedsportalen eller Jobnet, som så vil afspejle sig som hændelser på WSRM-køen. For at sikre at flere organisationer ikke – utilsigtet – benytter overlappende testdata i KT2, er en række jobcentre fordelt som vist i nedenstående skema.

https://job-kt2.jobnet.dk/cv�


Version 1.3 · 30. maj 2012

Side 16 af 29

Det er muligt at ønske testdata på specifikke jobcentre. Dette gøres ved at benytte blanketten til bestilling af test-data i dokumentationsarkivet og fremsende denne senest 14 dage før start af test. Ønskerne vil i videst muligt omfang søges tilgodeset. Såfremt der ikke fremsendes ønsker vil testdata blive tildelt administrativt.

Organisation Kommune/Jobcenter

AMS København, Frederiksberg

Knowledge Cube Vejle, Vordingborg, Langeland, Jammerbugten, Brøndby

Systemforvalter Esbjerg, Skanderborg

Business DK Nordfyn, Køge

Miracle/ASE Ringkjøbing-Skjern/Ringsted

Facilia

FOA Hvidovre og Herning

Tieto Brøndby, Faaborg-Midtfyn, Glo-strup, Vesthimmerland

KMD Assens, Ballerup, Billund, Born-holm

Frie Funktionærer

7.2 Testmiljø - T3 URL (ekstern integration) Herunder er URL’erne til testmiljø T3 angivet for henholdsvis Arbejdsmarkedsportalen og Jobnet: Dette testmiljø benyttes til Integrationstest til eksterne systemer.




Jobnet

• CVBank: https://job-kt3.jobnet.dk/cv • Jobbanken: https://job-kt3.jobnet.dk/jobbanken • CVAdmin: https://cvadmin-kt3.jobnet.dk/CV_admin/

Jobcenter-planner • amportalT3.knowledgecube.net (link på AMP forsiden)

7.2.1 Fordeling af kommuner og jobcentre Konkret vil testdata bestå af adgang til et antal medlemmer fra en given a-kasse, hvor det vil være muligt at ud-føre de til fase 1 understøttede forretningsmæssige operationer via (test-udgaverne af) Arbejdsmarkedsportalen eller Jobnet, som så vil afspejle sig som hændelser på WSRM-køen. For at sikre at flere organisationer ikke – utilsigtet – benytter overlappende testdata i KT2, er en række jobcentre fordelt som vist i nedenstående skema.


Version 1.3 · 30. maj 2012

Side 17 af 29

Det er muligt at ønske testdata på specifikke jobcentre. Dette gøres ved at benytte blanketten til bestilling af test-data i dokumentationsarkivet og fremsende denne senest 14 dage før start af test. Ønskerne vil i videst muligt omfang søges tilgodeset. Såfremt der ikke fremsendes ønsker vil testdata blive tildelt administrativt.

Organisation Kommune/Jobcenter

AMS København, Frederiksberg

Knowledge Cube Vejle, Vordingborg, Langeland, Jammerbugten, Brøndby

Systemforvalter Esbjerg, Skanderborg

Business DK Nordfyn, Køge

Miracle/ASE Ringkjøbing-Skjern/Ringsted

Facilia

FOA Hvidovre og Herning

Tieto Brøndby, Faaborg-Midtfyn, Glo-strup, Vesthimmerland

KMD Assens, Ballerup, Billund, Born-holm

Frie Funktionærer

7.3 Testmiljø – T8 URL (SF/AMP Build Verification/Deployment) Herunder er URL’erne til testmiljø T8 angivet for henholdsvis Arbejdsmarkedsportalen og Jobnet.




Jobnet

• CVBank: https://job-kt8.jobnet.dk/cv • Jobbanken:

https://job-kt8.jobnet.dk/jobbanken • CVAdmin: https://cvadmin-kt8.jobnet.dk/CV_admin/

Jobcenter-planner • amportalT8.knowledgecube.net (link på AMP forsiden)

8 Levering af testdata Testdata vil være baseret på en kopi af produktionsdata, dog vil data være anonymiseret. Population består af fik-tive (anonymiserede) CPR nr. frem for reelle CPR nr. De fiktive CPR nr. dækker over personer, som også er gjort anonyme i forhold til navn, adresse samt kontaktoplysninger. Personen flytter dog ikke kommune eller job-center og får heller ikke ændret fødselsdato samt køn. Bemærk at backend data ikke vil være anonymiserede.


Version 1.3 · 30. maj 2012

Side 18 af 29

Test data udstilles i de beskrevne miljøer, hvorfra de kan manipuleres vha. Arbejdsmarkedsportalen. Det er her A-kasserne har mulighed for at tilmelde, afmelde, fraværsmelde borgere, således at de i testen efterspurgte web service beskeder genereres. A-kasserne er selv ansvarlige for at generere den data der er behov for til at gennem-føre den beskrevne test.

8.1 Konfiguration af testmiljøer (WSRM) KC/Systemforvalter udsender et WSRM konfigurationsskema. De eksterne aftagere har ansvaret for at udfylde WSRM konfigurationsskemaet med den ønskede WSRM opsætning, så testmiljøerne kan konfigureres inden te-stens begyndelse.

9 Test status Der afholdes faste teststatusmøder hver uge i testforløbet, hvor en række test metrikker fremlægges og afrappor-teres. Formålet med statusmøderne er:

• Diskussion af testforløbets fremdrift • Imødekomme skred i testforløbets tidsplan • Fremlæggelse af fremdriftsrapport

Der er defineret følgende agenda for testmøderne:

1. Siden sidst 2. Fremdriftsrapportering (fejltrends og prosa) 3. Risikolisten 4. Indtil næste møde

9.1 Statuskategorier Der gøres brug af følgende statuskategorier til udført testarbejde (til opdatering af testlog):

Status Beskrivelse

Pass Item ”består” såfremt de i test casen beskrevne forventninger er mødt.

Fail Item består ikke eller der skal laves omfattende ændringer i testprocedurer.

Not tested Man vælger ikke at teste dette item.

Could not test Man er forhindret i at teste dette item (testen er blokeret).

9.2 Test metrikker For at følge de testaktiviteter, der afvikles som en del af testforløbet vil følgende metrikker blive benyttet:

• Testfremdriftsrapport • “Bugtrend”: Opsamling af aktive fejl sorteret ud fra prioritet • Open/Closed/Resolved metric • Total åbne vs. lukkede fejl

Disse testmetrikker vil blive afrapporteret til kunden stillet til rådighed for medlemmerne af testgruppen hver dag i integrationstest-, end-to-end- test og kundetestperioden.

9.3 Testrapportering Hver enkelt A-kasse har ansvaret for at udarbejde en teststatusrapport under de planlagte testfaser. Test rappor-ten skal indeholde en summering af den foregående uges test, samt en vurdering af status for de funktionelle om-råder – Listet i appendix C - Det overordnede scope for testen i fase 1.


Version 1.3 · 30. maj 2012

Side 19 af 29

Testrapporten skal sendes til Tøger Nørgaard, Nicolai L. Nielsen og Anders Ellegaard Dahl hver mandag inden kl. 12:00.

9.4 Mødeoversigt Mødeoversigten er en overordnet plan over opstarts-, status- og godkendelsesmøder i testforløbet for både de in-terne AMS integrationstest samt de eksterne testforløb med KMD og ML.

Mødetype og formål Testfase Deltagere Dato

Test readiness review – Test Slot 1 - Integrationstest (slot 1)

KC A-Kasser

Mandag 11/6


KC A-Kasser

Mandag 30/7


KC A-Kasser

Mandag 6/8

Test statusmøde

- Integrationstest

KC AMS

På foranledning as AMS

9.5 Generelle accept- og stopkriterier Dette afsnit beskriver de generelle accept- og stopkriterier for en testfase. En test er accepteret/bestået, hvis det fejlniveau, som er afdækket ved prøven, ligger under det aftalte fejlniveau. Fejlniveauet opgøres ved optælling af fejl i fire fejlkategorier, der defineres ud fra nedenstående skema. Stopkriterier indebærer en vurdering af det acceptable niveau af (antal) fejl, der kan danne grundlag for at en test (eller en serie af tests) skal suspenderes/indstilles. En test kan med fordel suspenderes, hvis der findes for mange fejl, da det ikke giver værdi at gennemføre eller fortsætte prøven – det er blot spild af ressourcer. Ved fejlrapportering og godkendelse anvendes følgende skema over fejlkategorier og acceptkriterier

Fejlkategori Beskrivelse Acceptkriterie

Kategori 1 Kritisk fejl

Programmel/udstyr/enhed har fejl, der medfører, at programmel/udstyr/enhed er utilgængelig. Andre mangler i forhold til opstillede krav, der er til hinder for Løsningens anvendelse, sidestilles hermed.

Brugervenligheden for en af de mest anvendte dele al Leverancen medfører produktionstab hos de brugende enheder.

Omgåelse er ikke mulig og det tjener ikke noget for-nuftigt formål at gennemføre prøven.

Opstår sådanne fejl, indstilles prøven.

Ingen fejl

Kategori 2 Alvorlig fejl


Version 1.3 · 30. maj 2012

Side 20 af 29

Programmel/udstyr/enhed har fejl der medfører, at Programmel/udstyr/enhed er utilgængelig. Andre mangler i forhold til opstillede krav, der er til hinder for Løsningens anvendelse, sidestilles hermed.

Brugervenligheden af Leverancen er ikke optimal på grund af generende og overflødige trin i ar-bejdsgangen

Omgåelse er mulig. Opstår sådanne fejl, kan Kunden vælge at indstille

prøven.

Ingen fejl

Kategori 3 Ikke-kritisk fejl

Programmel/udstyr/enhed har fejl, der medfører gene for Brugere.

Andre mangler i forhold til opstillede krav, der er til gene for Brugere, sidestilles hermed.

Alternativer er tilgængelige. Fejlen kan afhjælpes i prøveperioden. Ved flere end 5 af disse fejl kan Kunden vælge at ind-

stille prøven.

Max 5 fejl

Kategori 4 Kosmetisk fejl

Programmel/udstyr/enhed har fejl, der medfører min-dre gene for Brugerne og fejlen er ikke blokerende. Andre mangler i forhold til opstillede krav, der medfø-rer mindre eller ingen gene for Brugere, sidestilles hermed.

Fejlen kan umiddelbart rettes. Ved flere end 30 mindre generende fejl kan Kunden

vælge at indstille prøven med mindre andet aftales.

Max 30 fejl

De fire fejlkategorier bruges ved kategorisering af fejl uanset hvornår og ved hvilken prøve, den pågældende fejl er afdækket. Det er som udgangspunkt i kundetestfasen Kunden, der afgør, om der er tale om en kategori 1-, 2-, 3-, eller 4-fejl, samt om der ved kategori 3-fejl er anvist en anvendelig omgåelse. Kunden kan i Leverancekontrakten/bestillingen tilpasse antallet af maksimale fejl i kategori 3-4 i afprøvnings-planen for den enkelte Leverance i både op- og nedadgående retning. Fejlkategoriseringen vedrører fejl ved selve Leverancen. En fejl i f.eks. kategori 4 kan imidlertid af den ene eller anden grund have en udsættende virkning på udførelse af afvikling af prøven på andre områder. Alle fejl skal derfor prioriteres i forhold til afvikling af prøvearbejdet, således at alle fejl med opsættende virkning henføres til den højst prioriterede kategori af de konstaterede fejl. Leverandøren er forpligtet til at rette sådanne fejl på linje med kategori 1- og 2-fejl. Fejlniveau (Master) Beståelseskriterier på Master-testplan niveau indebærer følgende:

• Alle underliggende testplaner er færdigtestet inden for rammerne af accept kriterierne • Der skal være gennemført alle testpasses for de i master testplanen definerede testområder

Fejlniveau (funktioner) Beståelseskriterier for funktionsniveauer indebærer:


Version 1.3 · 30. maj 2012

Side 21 af 29

Alle test cases indenfor den enkelte funktion er gennemført det maksimale antal fejl i enkelte fejlkategorier, som anført i skemaet ovenfor.

10 Organisering Herunder beskrives testforløbets organisering i form af et personskema samt et ansvarsskema. Såfremt der er ændringer til nedenstående skema bedes følgende personer notificeret: Tøger Nørgaard & Nicolai L. Nielsen

10.1 Personskema

Person Rolle Virksomhed E-mail

Tøger Nørgaard Projektleder KC [email protected]

Nicolai L. Nielsen Test Manager KC [email protected]

Michael Lund Software tester KC [email protected]

Laust Christensen Software tester KC [email protected]

Hanne Skou Poulsen Test ansvarlig 3F: Facilia

Facilia [email protected]

Mark Svensson Test ansvarlig FOA FOA [email protected]

Steffen Dyrberg Test ansvarlig Tieto: EMO & Modulus

Tieto [email protected]

Karsten Madsen Test Ansvarlig ASE ASE [email protected]

Tue Mark Jensen Test Ansvarlig KMD KMD [email protected]

Peter Gøtze Test Ansvarlig KMD: Winnie

KMD [email protected]

Helle Elnegaard Test Ansvarlig Frie Funktionærer

Frie Funkti-onærer

[email protected]

Anders Ellegaard Dahl Projektleder AMS [email protected]

Alex Larsen Projektleder AMS [email protected]

Fleming Jensen Test Manager AMS [email protected]

10.2 Ansvarsskema

Ansvarsområde Personer Virksomhed

Master Testplan Nicolai L. Nielsen KC

Nicolai L. Nielsen/ Tøger Nørgaard KC Teststrategi

Flemming Jensen AMS

Anders Ellegaard Dahl (projektleder) AMS

Alex Larsen (projektleder) AMS

Flemming Jensen AMS

Beslutningstagere

Tøger Nørgaard (Projektleder) KC

Ansvarlig for at udviklet funktionalitet er Tøger Nørgaard KC

mailto:[email protected]�















Version 1.3 · 30. maj 2012

Side 22 af 29

Anders Ellegaard Dahl AMS

Hanne Skou Poulsen Facilia

Mark Svensson FOA

Steffen Dyrberg Tieto

Karsten Madsen ASE

Peter Gøtze KMD

klar til test

Helle Elnegaard Frie Funktio-nærer

Flemming Jensen AMS Godkendelse af den interne integrations-test Nicolai L. Nielsen KC

Nicolai L. Nielsen KC

Flemming Jensen AMS

Tøger Nørgaard KC

Hanne Skou Poulsen Facila

Mark Svensson FOA

Steffen Dyrberg Tieto

Karsten Madsen ASE

Peter Gøtze KMD

Godkendelse af intgrationstesten med A-kasserne

Helle Elnegaard Frie Funktio-nærer

Release management Torben Espersen SF

10.3 Procesgodkendelse Procesgodkendelse indebærer identificering af testpersoner, som kan godkende at en test er gennemført.

Person Rolle Testproces Virksomhed

Nicolai L. Nielsen Test manager Funktionstest Integrationstest (Intern/ekstern) Idriftsættelsestest Datakonverteringstest

KC

Flemming Jensen Test manager Funktionstest Kundetest Integrationstest Driftstest

AMS

Tøger Nørgaard Projektleder Review på testplaner Accepttest Integrationstest Driftstest Datakonverteringstest

KC

Anders Ellegaard Projektleder Review på testplaner AMS


Version 1.3 · 30. maj 2012

Side 23 af 29

Dahl Accepttest Integrationstest Driftstest Datakonverteringstest

Alex Larsen Projektleder Review på testplaner Accepttest Integrationstest Driftstest Datakonverteringstest

AMS

Hanne Skou Poulsen Test ansvarlig Komponenttest - Facilia Integrationstest - Facilia

Facilia

Mark Svensson Test ansvarlig Komponenttest - FOA eget system Integrationstest - FOA eget system

FOA

Steffen Dyrberg Test ansvarlig Komponenttest - EMO & Modulus Integrationstest - EMO & Modulus

Tieto

Karsten Madsen Test ansvarlig Komponenttest - ASE eget system Integrationstest - ASE eget system

ASE

Peter Gøtze Test ansvarlig Komponenttest - Winnie Integrationstest - Winnie

KMD

Helle Elnegaard Test ansvarlig Komponenttest - FF eget system Integrationstest - FF eget system

Frie Funktio-nærer

A Glossary Herunder beskrives termer benyttet i dette dokument (og tests) generelt:

10.4 Aktører

Aktør Beskrivelse

AMS Arbejdsmarkedsstyrelsen

AMS10 AMS 10. Kontor

CC CyberCom Group AB

KC Knowledge Cube A/S

SF Systemforvalteren

CM Change Manager


Version 1.3 · 30. maj 2012

Side 24 af 29

RM Release Manager

10.5 Begreber

Begreb Beskrivelse

AMP Arbejdsmarkedsportalen (AMP) understøtter sagsbehandling og styring af be-skæftigelsesindsatsen. Portalen er et fælles redskab for de professionelle aktører - på tværs af stat, kommuner, a-kasser og andre aktører.

Eksterne aftagere Leverandører af systemer til kommuner/jobcentre.

TASS Match En samlet funktionalitet, der understøtter jobcenterets og anden aktørs registre-ring af oplysninger om kontaktforløb herunder samtaler og resultatet af match-vurderinger og jobplanlægningen – for borgere i Match-målgrupperne.

LOR Lead of the Reporter. Den ansvarlige leder (for en person som finder en afvigel-se). Dette vil typisk være testlederen.

Master Test Plan Dette dokument. Indeholder Test Planen, alle Test Items og Test Specifikationer for alle Test Items.

TDS TransferDataService. Flytte- og opstartsdata servicen som benyttes til at flytte borgere mellem jobcentre og til at flytte data i forbindelse med opstart af syste-mer fra kommunale leverandører.

Test specifikation Beskrivelse af, hvordan Test Items testes, hvem der skal teste dem, samt hvor og hvornår de skal testes. I IEEE 829 kaldes dette ”Test design specification”. Dog indeholder Master Test Planens specifikationer ikke ”identifikation af tilknyttede højniveau test cases”. Dette vil i stedet fremgå i separate dokumenter og af test-loggen.

Test Item Det enkelte element (genstand), der er under test.

Test procedure specifi-kation

Et dokument, der specificerer en rækkefølge af handlinger for afviklingen af en test (en samling af test cases). I IEEE 829 kaldes dette også “Test procedure specification”.

Test case Et sæt inputværdier, startbetingelser for afvikling, forventede resultater, postbe-tingelser for afvikling designet med henblik på et bestemt mål eller testbetingelse, så som at aktivere en bestemt programsti eller at verificere overensstemmelse med et specifikt krav.

Test log En kronologisk registrering (log) af relevante detaljer om afviklingen af test.

Test status rapport Samlet statusrapport for gennemførte testarbejde.

FogBugz Bug-tracker. Benyttes til registrering og håndtering af afvigelser funder under test.


Version 1.3 · 30. maj 2012

Side 25 af 29

B Dokumentstruktur Figur 5: Dokumentstruktur angiver dokumentstrukturen i forhold til master-testplanen samt de enkelte testpro-cedurer og test cases, der er omfattet af denne master-testplan.

Figur 5: Dokumentstruktur


Version 1.3 · 30. maj 2012

Side 26 af 29

C Det overordnede scope for testen i fase 1. DFDG hændelse Beskrivelse

af hændelse Webserviceunderstøttelse:

T, A T: Tilmelding af person i jobcenter A: Afmelding af person i jobcenter eller ophør af medlemskab i a-kassen

(WSRM) GetUnemploymentEnrollmentVersion4 GetLatestInterviewdate (WSRM) GetCancelUnemploymentEnrollmentVersion4

C CV kundenummer eller CV status ændres.

(WSRM) GetCVStatusVersion4

F30 Servicebesked om oprettelse eller ændring af Jobplan

(WSRM) GetJobplanStatusVersion1

F31 F32 F33 F34

Servicebesked om sygdom, rask-melding, ferie eller mindre intensiv indsats. Der kan også være registre-ret en opdatering eller sletning af hændelsen.

(WSRM) GetAbsenceVersion5 og GetDeleteAbsenceVersion5

Akasseskift og udmelding (MA og MT)

‐ Skift af a-kasse ‐ Udmelding af a-kasse ‐ Fremsendelse af uafslutte-

de fraværsfor-hold(servicebeskeder) ved a-kasseskift

Bl.a. (WSRM) GetMembershipCancellation

Funktionscertifikater – brug af disse til opkobling

CodeListService A‐kasse kan oprette adgang til Co‐deListServer og hente relevante Codelister.

CodeListService

WSRMkø A‐kasse kan åbne, tømme og afslut‐te WSRM‐køen korrekt

Formateret: Skrifttype:Times New Roman, Ingenunderstregning

Formateret: Skrifttype:Times New Roman


Formateret: Skrifttype:Times New Roman






Slettet: 6

Slettet: 6


Version 1.3 · 30. maj 2012

Side 27 af 29

D Workflows der bør efterprøves af a-kasserne i integrationstesten. DFDG hændelse Hvorledes Resultat T: Tilmelding af person i jobcenter

A-kassetester tilmelder person som dagpengemodtager

GetUnemploymentEnrollmentVersion4 Skubbes på WSRM-kø. A-kasse registrerer tilmelding i eget system

A-kassetester tilmelder person som dimittend og vedkommen-de har registreret en a-kasse


A-kassetester tilmelder person som dimittend og vedkommen-de har ej registreret en a-kasse

Ingenting

A-kassetester opdaterer a-kassetilhørsforhold i akassere-gistret (MT-afsendes) for en dimittend og dato for dagepen-geret er d.d.


A-kassetester tilmelder person til jobcentret (gamle T09)

GetUnemploymentEnrollmentVersion4 Skubbes på WSRM-kø. GetLatestInterviewdate skubbes på WSRM-kø A-kasse registrerer tilmelding i eget system og kan udlæse datoen for seneste cv eller jobsamtale.

DFDG hændelse Hvorledes Resultat A: Afmelding af person i jobcenter eller ophør af medlemskab i akassen

A-kassetester framelder person

GetUnemploymentEnrollmentVersion4 Skubbes på WSRM-kø. A-kasse registrerer afmelding i eget system

A-kassetester udmelder person af a-kasse

GetUnemploymentEnrollmentVersion4 Skubbes på WSRM-kø. A-kasse registrerer afmelding i eget system

DFDG hændelse Hvorledes Resultat C: CV kundenummer eller CV status ændres.

A‐kassetester opretter CV GetCVStatusVersion5 skubbes på WSRM-kø. A-kasse registrerer ændring i eget system

A‐kassetester sætter CV util‐gængeligt for søgning

A‐kassetester sætter CV til‐gængeligt for søgning

A‐kassetester ændrer status på CV

Formateret: Skrifttype:Times New Roman, 10 pkt,Ingen understregning,Skriftfarve: Sort

Formateret: Indrykning:Venstre: 0 pkt.

Formateret: Skrifttype:Times New Roman, 10 pkt

Formateret: Skrifttype:Times New Roman, 10 pkt,Ingen understregning,Skriftfarve: Sort

Formateret: Skrifttype: 10pkt


Version 1.3 · 30. maj 2012

Side 28 af 29

DFDG hændelse Hvorledes Resultat F30: Servicebesked om oprettelse eller ændring af Jobplan

A-kassetester opretter jobplan

GetJobplanStatusVersion1 skubbes på WSRM-kø. A-kasse registrerer hændelse i eget system

A-kassetester ændrer eksiste-rende jobplan

GetJobplanStatusVersion1 skubbes på WSRM-kø. A-kasse registrerer ændring i eget system og skal binde denne til eksisterende jobplan.

DFDG hændelse Hvorledes Resultat F31/F32: Medlemmet er meldt syg/rask

A‐kassetester sygemelder en dagpengemodtager

GetAbsenceVersion5 skubbes på WSRM-kø på datoen for sygdommens start eller hvis datoen overskrides. A-kasse registrerer ændring i eget system

A-kassetester raskmelder en dagpengemodtager

GetAbsenceVersion5 skubbes på WSRM-kø for datoen for raskmeldingen eller hvis datoen over-skrides. A-kasse registrerer ændring i eget system og skal koble raskmeldingen til en sygemelding.

A-kassetester sygemelder en dimittend

GetAbsenceVersion5 skubbes på WSRM-kø på datoen for dagpengeret.

DFDG hændelse Hvorledes Resultat F33: Servicebesked om ferimelding

A-kassetester opretter feriefor-hold

GetAbsenceVersion5 skubbes på WSRM-kø på datoen for registreringen. A-kasse registrerer ændring i eget system

A-kassetester ændrer et eksiste-rende ferieforhold

GetAbsenceVersion5 skubbes på WSRM-kø på datoen for registreringen. A-kasse registrerer ændring i eget system

DFDG hændelse Hvorledes Resultat F34: Mindre intensiv ind‐sats

A‐kassetester angiver at dag‐pengemodtager er omfattet af mindre intensiv indsats (angi‐

GetAbsenceVersion5 skubbes på WSRM-kø A-kasse registrerer ændring i eget system

Formateret tabel

Slettet: 6

Slettet: GetCancelUnemploy-mentEnrollmentVersion4 skubbes på WSRM-køen efterfølgende F32 (automatisk afmelding A som følge af sygemelding)¶

Slettet: 6

Slettet: GetUnemploymentEn-rollmentVersion4 skubbes på WSRM-køen efterfølgende F31 (automatisk Tilmelding T som følge af raskmelding)¶

Slettet: 6

Slettet: 6

Slettet: 6

... [1]


Version 1.3 · 30. maj 2012

Side 29 af 29

ver barsel inden for 6 uger, på vej på pension inden for 6 uger)

DFDG hændelse Hvorledes Resultat Sletning af F31/F32/ F33/F34

A‐kassetester sletter et fra‐værsforhold

GetDeleteAbsenceVersion5 skubbes på WSRM-kø A-kasse registrerer ændring i eget system

DFDG hændelse Hvorledes Resultat A‐kasseskift A-kassetester skifter a-

kassemedlemskab på en til-meldt dagpengemodtager (MT-hændelse)

GetUnemploymentEnrollmentVersion4 Skubbes på WSRM-kø (eksisterende hændelse i DFDG) A-kasse registrerer tilmelding i eget system GetAbsenceVersion5 for alle uafsluttede fra‐værsforhold skubbes på WSRM-kø. A-kasse registrerer ændringerne i eget system

Slettet: 6

Slettet: 6

Side 28: [1] Slettet Tøger Nørgaard 30-05-2012 17:21:00 A-kassetester sygemelder en

dimittend og a‐kassen er kendt.

GetAbsenceVersion6 skubbes på WSRM-kø på datoen for sygdommens start eller hvis datoen overskrides.

master test plan - star · arbejdsmarkedsstyrelsen · a-kassekommunikation via webservices ·...

Documents