ARBE JDSMA RK E DSSTYRELSEN - A-KASS EKOMM UNI KATION VIA W EBSERVI CE S

Transkript

1 ARBE JDSMA RK E DSSTYRELSEN - A-KASS EKOMM UNI KATION VIA W EBSERVI CE S MASTER TEST PLAN VERSION 1.65 DATO 10. September 6. oktober2012 REFERENCE Anders Ellegaard Dahl FORFATTER Nicolai L. Nielsen KONTRAKTNUMMER SF099 Knowledge Cube A/S Bernstorffsgade 50, 7. sal DK 1577 København V T F CVR info@knowledgecube.net

2 DOKUMENTVERSIONER Version Dato Initialer Afsnit Ændringer april 2012 NLN Alle MTP for test i forbindelse med A-Kasse kommunikation via webservices april 2012 NLN Alle Opdateret med GetAbsenceVersion6 samt workflows afledt af sygeraskprojektet. Samt opdateret på baggrund af kommentarer fra AMS maj 2012 NLN 10 Ændringer til personskema. Organisator rettet til KMD maj 2012 TN 2.1, 7.1.1, 7.2.1, C, D Konsekvensrettelse i forhold til versionering af GetAbsence samt tilføjelse af GetLatestInterviewDate. Tilføjet JC for testdata for KMD (tidl. Organisator) maj 2012 TN Fjernet workflows afledt af syge/raskprojektet, herunder er GetAbsence rettet til version5. Der henvises nu til LB 3.3 ASE er flyttet til testslot September 2012 NLN Alle MTP opdateret i henhold til aftale med AMS vedr. revideret go-live plan for AKS kommunikation vha. WS /10 MJE Tilrettelser ifølge Anders Ellegaard Dahl Side 2 af 31

3 INDHOLDSFORTEGNELSE 1 INTRODUKTION 5 2 TEST ITEMS Fase 1 webservices Event flows Funktionscertifikater 7 3 PLAN FOR TESTAKTIVITETER 8 4 TEST TILGANG Gentest og regressionstest Rapportering af fejl Test faser for AMS leverandører Fabriksprøven Afvikling af den interne integrationstest Test faser for eksterne aftagere Afvikling af komponenttest hos A-kasser Afvikling af den eksterne integrationstest med A-kasser PERFORMANCETEST RELEASE HÅNDTERING Releaseplan Release notes Release Leveranceprocedure Release miljøsikring TESTMILJØER Testmiljø - KT3 URL Testmiljø KT4 URL Testmiljø KT8 URL Testmiljø KT10 URL LEVERING AF TESTDATA Konfiguration af testmiljøer (WSRM) TEST STATUS Statuskategorier Test metrikker Testrapportering Generelle accept- og stopkriterier ORGANISERING Personskema Ansvarsskema 2421 Side 3 af 31

4 10.3 Procesgodkendelse 2522 A GLOSSARY Aktører Begreber 2623 B DOKUMENTSTRUKTUR 2825 C DET OVERORDNEDE SCOPE FOR TESTEN I FASE D WORKFLOWS DER BØR EFTERPRØVES AF A-KASSERNE I INTEGRATIONSTESTEN Side 4 af 31

5 1 Introduktion Dette dokument beskriver rammerne for testen af AMS projekt A-kassekommunikation via webservices og beskriver 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 milepæ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 statusrapporter, 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 Integrationstest F1WS02 Systemtest (funktionel) af A- kasse funktioner der aftager webservice Komponenttest. F1WS03 Procedurekrav Integration mod udstillede webservices Ekstern Integratrionstest Automatiseret test KC KT2 Manuel test Manuel test A-Kasse leverandør A-Kasse leverandør / KC KT2 KT3/4 & KT10 Test cases udformes som en Test Charter og leveres i Microsoft Word format inden testens begyndelse. Alle test cases udformes med udgangspunkt i IEEE 829 standarden og leveres i Microsoft Word format inden 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. Side 5 af 31

6 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 Konfiguration af testmiljøer (WSRM)Konfiguration af testmiljøer (WSRM) Funktionalitetsoversigt DFDG- hændelse af hændelse Beskrivelse T, A T: Tilmelding af person i jobcenter A: Afmelding af person i jobcenter eller ophør af medlemskab i a-kassen C F30 F31 F32 F33 F34 A-kasseskift og udmelding (MA og MT) CodeListService WSRM-kø CV kundenummer eller CV status æn-dres. Servicebesked om oprettelse eller æn-dring af Jobplan Servicebesked om sygdom, raskmelding, ferie eller mindre intensiv indsats. Der kan også være registreret en opdatering eller sletning af hændelsen. Skift af a-kasse Udmelding af a-kasse Fremsendelse af uafsluttede fraværsforhold(servicebeskeder) ved a- kasseskift A-kasse kan oprette adgang til CodeListServer og hente relevante Codelister. A-kasse kan åbne, tømme og afslutte WSRM-køen korrekt Webservice-understøttelse: (WSRM) GetUnemploymentEnrollmentVersion4 GetLatestInterviewDate GetCancelUnemploymentEnrollmentVersion4 (WSRM) GetCVStatusVersion5 (WSRM) GetJobplanStatus (WSRM) GetAbsenceVersion5 og GetDeleteAbsenceVersion5 Bl.a. (WSRM) GetUnemploymentEnrollmentVersion4 GetLatestInterviewdate GetAbsenceVersion5 CodeListServices: ClientCategoryTypeIdentifier, RemovalCauseTypeIdentifier, CVStatusIdentifier, JobplanStatusIdentifier, AbsenceTypeIdentifier, CurrentUnemploymentStatusTypeIdentifier Formatted: Font: Times New Roma Formatted: Font: Times New Roma Yderligere informationer omkring beskrevne funktionalitet kan ses i dokumentet LB99_AMS_Akassekommunikation via webservices_løsningsbeskrivelse_fase1_v Event flows ID Testområde Metode Ansvarlig Miljø EvtFl01 Funktionel test af understøttelsen af event flows Intern integrationstest Kombination af manuel og automatiseret webservice test KC KT2 EvtFl02 Funktionel test af event flows Ekstern Integrationstest Manuel test A-Kasse leverandør KT3/4 & Side 6 af 31

7 Procedurekrav / KC KT10 Test cases udformes som en Test Charter og leveres i Microsoft Word format inden testens begyndelse. Alle test cases udformes med udgangspunkt i IEEE 829 standarden og leveres i Microsoft Word format inden 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 Konfiguration af testmiljøer (WSRM)Konfiguration af testmiljøer (WSRM) Funktionalitetsoversigt 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 Formatted: Font: Times New Roma Formatted: Font: Times New Roma 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 ID Testområde Metode Ansvarlig Miljø FCert01 Procedurekrav Funktionel test af brugen af Funktionscertifikater Manuel test A-Kasse leverandør KT3/4 & KT10 Test cases udformes som en Test Charter og leveres i Microsoft Word format inden testens begyndelse. Alle test cases udformes med udgangspunkt i IEEE 829 standarden og leveres i Microsoft Word format inden 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 Side 7 af 31

8 Forudsætninger for brug at funktionscertifikater er opfyldt jf. LB99_AMS_A-kassekommunikation via webservices_løsningsbeskrivelse_generelt_v31 Funktionalitetsoversigt 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 funktionscertifikat pr. a-kasse. Testafviklingen gennemføres som en del af den beskrevne test mod items 2.1 & 2.2, således at funktionscertifikaterne 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 Integrationstest med A-kasserne i KT3/4 Tidligere benævnt A-kasse test fase 1 slot SF flytning af KT10 miljø og forberedelser A-kasser flytter testmiljø til KT Integrationstest med A-kasserne i KT Go-live aktiviteter Beskrives i drejebog for idriftsætning udarbejdet af AMS Systemforvalter Side 8 af 31

9 A-kasse nummer A-kasse System KT miljø frem til 14/ FA Facilia KT3 76 Danske Sundhedsorg. A-kasse Facilia KT3 95 Dana Facilia KT3 14 Socialpædagoger Winnie/KMD KT3 24 Metalarbejdere Winnie/KMD KT3 34 Næring mv. Winnie/KMD KT3 53 HK Winnie/KMD KT3 62 Dansk funktionærforbund Winnie/KMD KT3 72 Teknikernes A-kasse Winnie/KMD KT3 81 BUPL Winnie/KMD KT3 82 Business Danmarks A-kasse Winnie/KMD KT3 91 Akademikernes A-kasse Winnie/KMD KT3 92 Funkt. Og Tjenestemænd Winnie/KMD KT3 83 Frie funktionær Eget system KT3 94 ASE Eget system KT3 17 FOA Eget system KT4 10 Journalistik mv. Netcompany/Modulus KT4 18 Danmarks Lærere Netcompany/Modulus KT4 37 El-faget Netcompany/Modulus KT4 40 Byggefagene Netcompany/Modulus KT4 57 Arbejdsløshedskassen STA Netcompany/Modulus KT4 86 Ingeniørernes A-kasse Netcompany/Modulus KT4 88 Magisternes A-kasse Netcompany/Modulus KT4 98 CA Netcompany/Modulus KT4 22 Danske Lønmodtagere Netcompany/EMO KT4 67 Ledernes A-kasse Netcompany/EMO KT4 73 Kristlig A-kasse Netcompany/EMO KT4 4 Test tilgang Testen afvikles med udgangspunkt i de scenarier der er beskrevet i testloggen der findes på Dokumentationsarkivet (ligeledes beskrevet i appendiks D - Workflows der bør efterprøves af a-kasserne i integrationstesten.). Formålet med testen er at afprøve integrationen mellem DFDG (AMS) og A-kassernes systemer, derfor er der ikke indeholdt test cases af systemtest- og forretningsmæssig karakter. Side 9 af 31

10 Side 10 af 31

11 Testen afvikles i følgende aktiviteter: Integrationstest med A-kasserne i KT3/4 (Tidligere benævnt A-kasse test fase 1 slot 3) Test med fokus på integrationen til A-kasse systemerne vha. webservices. Testen afvikles med udgangspunkt i de beskrevne scenarier, og A-kasse leverandørerne. Testen afbrydes den 14. september, hvorfor det er meget vigtigt at alle A-kasserne som minimum har gennemført de i test loggen beskrevne scenarier mindst en gang. Resultaterne at den enkelte A-kasseleverandørs test skal videreformidles til AMS vha. en opdateret test log, jf. retningslinjer i afsnit om test rapportering. Gennemførslen af alle scenarier er ekstra vigtig da resultaterne af denne test vil være bestemmende for muligheden for fejlretning i perioden mellem denne og efterfølgende integrationstest fase. SF flytning af KT10 miljø og forberedelser Forberedende aktivitet med henblik på at klargøre til næste (og sidste) fase af integrationstesten, der kommer til at foregå i KT10. Som en del af forberedelserne vil SF kopiere WSRM opsætning & abonnementer fra det miljø A-kassen brugte i forgående test fase (beskrevet i afsnit 3 - Plan for testaktiviteterplan for testaktiviteter), således at alle har den samme setup for test i KT10 som de havde i KT3/4. Disse aktiviteter berør ikke A-kasse leverandørerne, der derfor ikke skal foretage sig noget i denne forbindelse. A-kasser flytter testmiljø til KT10 Når KT10 er konfigureret og miljøsikret af SF, kan A-kasse leverandørerne flytte til det nye miljø. Dette gøres af A-kasserne ved enten at om-konfigurere et eksisterende testmiljø, eller åbne et nyt der peger mod KT10. Dette er en forudsætning for videre integrationstest med AMS, idet de eksisterende test miljøer KT3/4 anvendes til andre formål, ligeledes skal migreres og dataløftes midt i den periode der er afsat til testen. SF har udsendt nye certifikater der skal anvendes til brug for test i KT10. Integrationstest med A-kasserne i KT10 Afviklingen af test i KT10 starter den 8. oktober. Fra denne dato vil AMS levere testdata, samt bistå ved afviklingen af de få test cases der måtte være udestående. Fokus på de første to uger af testen er at få alle igennem de beskrevne scenarier, således at der ikke længere er nogen der melder om fejlede test cases. Desuden kan denne test periode anvendes af A-kasse leverandørerne til efterfølgende test faser så som bruger accept test mm. Go-live aktiviteter Beskrives i drejebog for idriftsætning udarbejdet af AMS Systemforvalter 4.1 Gentest og regressionstest Gennem alle testfaser har leverandørernes 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 implementeringen 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 information henvises til forvaltningshåndbogens afsnit 3. Side 11 af 31

12 Sagen er ikke løst Inquiry Bug FogBugz sag oprettes og sendes til udvikling Status: Active Sagen sendes til intern verifikation hos leverandøren Status: Resolved (Fixed Needs QA) Er sagen løst? Feature Schedule Item Sagen er ikke løst Sagen er løst Status: Closed Sagen er løst Mener kunden at sagen er løst? Sagen sendes til kundetest Status: Resolved (Fixed) Figur 4: Grundlæggende rapportering, rettelse og gentest af fejl i FogBugz. 4.3 Test faser for AMS leverandører I de følgende afsnit beskrives de test faser, som er relevante for AMS leverandører 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 testes i det samlede systemkompleks. Accept kriterier Accept kriterier Entry kriterier FogBugz projekt oprettet Kravspecifikation/løsningsbeskrivelse dækkende alle features er klar Exit kriterier Alle leverancer er kvalitetssikret inden leverance til AMS testmiljøer (KT2/KT3) Der foreligger en reviewet Master Test Plan (dette dokument) Afvikling af den interne integrationstest Integrationstesten skal afvikles fra den grænseflade, som slutbrugeren skal benytte og testen skal afvikles i AMS KT3 testmiljø. Accept kriterier Accept kriterier Entry kriterier AMS Testmiljøer klar Udviklet funktionalitet klar Testprocedurer er udarbejdet og reviewet af Systemforvalter Dokumentation klar - Kravspecifikation opdateret Exit kriterier Alle test cases, der direkte (og udelukkende) afprøver integrationen i interne systemer er udført Alle test cases, der direkte afprøver integrationen i interne systemer, og som også skal udføres under integrationstest for eksterne systemer, er udført mindst en gang. Side 12 af 31

13 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 4.4 Test faser for eksterne aftagere I de følgende afsnit beskrives de test faser, som er relevante for eksterne aftagere Afvikling af komponenttest hos A-kasser A-Kasser er selv ansvarlige for at udføre en komponenttest af deres applikationer inden starten på integrationstesten mod AMS KT3/4 testmiljø. For at den eksterne integrationstest kan startes er det en forudsætning at komponenttesten er afsluttet på tilfredsstillende vis. Dvs.: Alle planlagte komponent test cases er gennemført. Blokerende fejl i A-kasse systemerne er rettet og gentestet Afvikling af den eksterne integrationstest med A-kasser Integrationstesten afvikles, som beskrevet i testloggen. Alle scenarier skal være gennemført under testen og der skal være taget stilling til alle fundne fejl for at integrationstesten kan godkendes. Derudover skal der ugentligt være afleveret test statusrapport og en opdateret testlog fra A-kasse leverandørerne til AMS. Disse rapporter anvendes til at følge op på testen, og er således vigtige for at der kan ydes den rette support til A-kasse leverandørerne. Integrationstesten skal afvikles i leverandørens system fra business laget eller fra den grænseflade, som slutbrugeren skal benytte. Testes der på business laget skal leverandøren sikre at der fra grænsefladen, som slutbrugerne 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 KTx testmiljø. (x= KT3/4 frem til 14/9 og KT10 fra 8/10) 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 Entry kriterier Systemforvalter: Testmiljøer klar Testprocedurer er udarbejdet og reviewet af Systemforvalter WSRM opsætning er gennemført Exit kriterier Alle test cases, der vedrør integrationen med eksterne systemer er gennemført Der forligger en testlog for hver ekstern aktør, der dokumenterer resultatet af den eksterne integrationstest. Side 13 af 31

14 Eksterne: Testlog som beskriver status på afviklede komponent test cases er afleveret til AMS/Systemforvalter Funktionscertifikater er klar WSRM bestilling er gennemført Der er leveret en testrapport til AMS, der dokumenterer og vurderer resultatet af den samlede, eksterne integrationstest. 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 Afvikling af kørsler - f.eks. af batchjobs Verificering af korrekt testudførelse gennem udarbejdelse og verificering af testdata og cases. Deltage i teststatusmøder A-Kasser Udførelse af test cases Fejlretning Verificering af korrekt testudførelse gennem udarbejdelse og verificering af testdata og cases. Deltage i teststatusmøder 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 releases 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 separat release plan. Features i forbindelse med A-kasserne er indeholdt i AMS releases & Der er milestones hver tirsdag og torsdag, og installationen vil finde sted kl. 22 de pågældende dage Ændringerne kan derfor først ses den efterfølgende dag. 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. Side 14 af 31

15 Systemforvalter sørger for at danne en samlet release note til hver release i testperioderne. Denne release note distribueres til alle aktører, således at alle har et samlet overblik over hvilke fejlrettelser, der er med til en given release. Dette foregår i AMS Dokumentationsarkiv, hvor AMS SF uploader releasenoten i forbindelse med release til testmiljøerne. Den samlede release note dannes på baggrund af et releasenoteudtræk fra FogBugz. Dette udtræk foretages på releasedagen kl , hvorfor alle release notes skal være påført løste sager senest kl Release notes findes her: spx?rootfolder=%2freleasedokumentation%2freleases%20%28amp%2djn%2dws%2 9%2F2012%2D3%2FRelease%20notes Formatted: English (U.S.) 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 tidsfrister: Miljø Senest levering fra UL (man/ons) Installation (tirs/tors) Miljøsikring (ons/fre) Klarmelding (ons/fre) 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 KT10 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 godkendelse 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 (dokumentationsarkivet) 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. Data til rådighed er løftet fra produktion 9. juli Der benyttes følgende testmiljøer til test af A-kassekommunikation via webservicesa-kassekommunikation via webservices: KT3/4 - benyttes til Integrationstest med A-kasserne frem til 14/ KT10 - benyttes til Integrationstest med A-kasserne frem fra den 8/ frem til 26/ KT8 benyttes til Build Verification Deployment hos Systemforvalter samt systemtest af fejlrettelser i DFDG Formatted: Font: 10 pt, Italic Side 15 af 31

16 7.1 Testmiljø - KT3 URL Benyttes til Integrationstest med A-kasserne frem til 14/ Herunder er URL erne til testmiljø KT3 angivet for henholdsvis Arbejdsmarkedsportalen og Jobnet: Testområde Testmiljø Arbejdsmarkedsportalen amportalt3.knowledgecube.net servicet3.knowledgecube.net printt3.knowledgecube.net okot3.knowledgecube.net vit3.knowledgecube.net Jobnet CVBank: Jobbanken: CVAdmin: Jobcenter-planner amportalt3.knowledgecube.net (link på AMP forsiden) 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 udfø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 KT3, er en række jobcentre fordelt som vist i nedenstående skema. Organisation AMS Knowledge Cube Systemforvalter Business DK Miracle/ASE Facilia FOA Tieto KMD Frie Funktionærer Kommune/Jobcenter København, Frederiksberg Vejle, Vordingborg, Langeland, Jammerbugten, Brøndby Esbjerg, Skanderborg Nordfyn, Køge Ringkjøbing-Skjern/Ringsted Fredericia, Guldborgsund, Haderslev Hvidovre og Herning Brøndby, Faaborg-Midtfyn, Glostrup, Vesthimmerland Assens, Ballerup, Billund, Bornholm Roskilde 7.2 Testmiljø KT4 URL Benyttes til Integrationstest med A-kasserne frem til 14/ Herunder er URL erne til testmiljø KT4 angivet for henholdsvis Arbejdsmarkedsportalen og Jobnet: Testområde Testmiljø Arbejdsmarkedsportalen amportalt4.knowledgecube.net servicet4.knowledgecube.net printt4.knowledgecube.net Side 16 af 31

17 okot4.knowledgecube.net vit4.knowledgecube.net Jobnet CVBank: Jobbanken: CVAdmin: Resurseplanlægger amportalt4.knowledgecube.net (link på AMP forsiden) Side 17 af 31

18 Fordeling af kommuner og jobcentre Samme som KT 3 Se afsnit Testmiljø KT8 URL Benyttes af AMS Systemforvalter til test og AMP Build Verification/Deployment. Herunder er URL erne til testmiljø T8 angivet for henholdsvis Arbejdsmarkedsportalen og Jobnet: Testområde Testmiljø Arbejdsmarkedsportalen amportalt8.knowledgecube.net servicet8.knowledgecube.net printt8.knowledgecube.net okot8.knowledgecube.net vit8.knowledgecube.net Jobnet CVBank: Jobbanken: CVAdmin: Jobcenter-planner amportalt8.knowledgecube.net (link på AMP forsiden) 7.4 Testmiljø KT10 URL Benyttes til Integrationstest med A-kasserne fra den 8/ NB! AMS Systemforvaltning flytter miljøet til nyt domæne i perioden 12/9-25/9 September. URLs oplyst her er efter KT10 er flyttet. Herunder er URL erne til testmiljø KT10 angivet for henholdsvis Arbejdsmarkedsportalen og Jobnet: Testområde Testmiljø Arbejdsmarkedsportalen amportalt10.amstest.dk servicet10. amstest.dk printt10. amstest.dk okot10. amstest.dk vit10. amstest.dk Jobnet CVBank: Jobbanken: CVAdmin: Resurseplanlægger amportalt104. amstest.dk (link på AMP forsiden) Fordeling af kommuner og jobcentre Samme som KT 3 Se afsnit 0 8 Levering af testdata Testdata vil være baseret på en kopi af produktionsdata, dog vil data være anonymiseret. Population består af fiktive (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 jobcenter og får heller ikke ændret fødselsdato samt køn. Bemærk at backend data ikke vil være anonymiserede og Side 18 af 31

19 data til rådighed i miljøerne er løftet fra produktion 9. juli 2012 Der er ikke planlagt dataløft de anvendte miljøer i testperioderne. 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 kan desuden bestille data vha. FogBugz, hvor der oprettes en sag som assignes til Testteam (KC). Følgende kan bestilles: CPR lister af borgere der er medlemmer i en given A-kasse i testmiljøet Generering af hændelser på borgere: o Tilmeldt - 1. Medlemmer af A-kassen o Ikke-tilmeldte - 1. Borgere der er medlem af en anden A-kasse o Nyjobplan - 1. Der er oprettet en jobplan på borgeren o Ændret-jobplan - 1.Der er oprettet en jobplan på borgeren med en aktivitet. 2.Jobplanen er læst. 3.Jobplanen er gemt igen på samme GUID hvor aktiviteten har fået en anden slutdato o Anulleret-jobplan - 1.Der er oprettet en jobplan på borgeren med en aktivitet. 2.Jobplanen er læst. 3.Jobplanen er opdateret med JobplanStatusTypeIdentifier = 3(Suspenderet) o nyt-cv-kundenr - 1. Tilmelder borgeren med et nyt CV nummer o Ændret-tilgængelighed - 1. Tilmelder DPM. 2. Ændre CV status til 3(CV ej godkendt) o F31F32 - Syg/Rask melding o F33-1. Medlemmet der har meldt ferie fra d.d. til d.d.+14 o F33Update - 1. Medlemmet der har meldt ferie fra d.d. til d.d Opdateret slutdato på ferien til d.d. +10 o F34 - Fravær: 42: Arbejdsfordeling, vejrlig eller materialemangel mv. Bestillingen af test data foregår ved at udfylde CPR numre for de borgere der ønskes manipuleret til nedenstående Excel fil, og vedhæfte filen til den FogBugz sag der oprettes til bestilling af data. BEMÆRK! Der er en fane pr. hændelse, således at disse kan separeres, og det er vigtigt at der indsættes CPR på de faner man ønsker hændelser for. 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 testens begyndelse. Som en del af forberedelserne af flytning til KT10 vil SF kopiere WSRM opsætning & abonnementer fra det miljø A-kassen brugte i forgående test fase (beskrevet i afsnit 3 - Plan for testaktiviteterplan for testaktiviteter), således at alle har den samme setup for test i KT10 som de havde i KT3/4. 9 Test status Der afholdes faste teststatusmøder hver uge i testforløbet, hvor en række test metrikker fremlægges og afrapporteres. 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: Side 19 af 31

20 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 Fail Not tested Blocked Item består såfremt de i test casen beskrevne forventninger er mødt. Item består ikke eller der skal laves omfattende ændringer i testprocedurer. Man vælger ikke at teste dette item. Man er forhindret i at teste dette item (testen er blokeret). Formatted Table Status Planned Completed Pass Fail Blocked Not tested Not Started Beskrivelse Item er planlagt til at starte. Item er udført. Item består såfremt de i test casen beskrevne forventninger er mødt. Item består ikke eller der skal laves omfattende ændringer i testprocedurer. Man er forhindret i at teste dette item (testen er blokeret). Man vælger ikke at teste dette item. Item ikke startet. 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 rapporten skal indeholde en summering af den foregående uges test, samt en vurdering af status for de funktionelle områder Listet i appendix C - Det overordnede scope for testen i fase 1. Testrapporten skal sendes til Nicolai L. NielsenMette Jensen og Anders Ellegaard Dahl hver mandag inden kl. 12:00. Side 20 af 31

21 9.4 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 Side 21 af 31

22 Fejlkategori Beskrivelse Acceptkriterie Kategori 1 Kategori 2 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 fornuftigt formål at gennemføre prøven. Opstår sådanne fejl, indstilles prøven. Alvorlig 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 af Leverancen er ikke optimal på grund af generende og overflødige trin i arbejdsgangen Omgåelse er mulig. Opstår sådanne fejl, kan Kunden vælge at indstille prøven. Ingen fejl 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 indstille prøven. Max 5 fejl Kategori 4 Kosmetisk fejl Programmel/udstyr/enhed har fejl, der medfører mindre 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. Side 22 af 31

23 Kunden kan i Leverancekontrakten/bestillingen tilpasse antallet af maksimale fejl i kategori 3-4 i afprøvningsplanen 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: 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: Kenneth Lund & Nicolai L. Nielsen 10.1 Personskema Person Rolle Virksomhed Kenneth Lund Projektleder KC kl@knowledgecube.net Nicolai L. Nielsen Mette Jensen Test Manager indtil 30/9 Test Manager fra 1/10 KC KC nln@knowledgecube.net mje@knowlwdgecube.net Michael Lund Software tester KC ml@knowledgecube.net Laust Christensen Software tester KC lc@knowledgecube.net Hanne Skou Poulsen Test ansvarlig 3F: Facilia Facilia Hanne.skou.poulsen@3f.dk Mark Svensson Test ansvarlig FOA FOA masv001@foa.dk Steffen Dyrberg Test ansvarlig Tieto: EMO & Modulus Netcompany sd@netcompany.com Karsten Madsen Test Ansvarlig ASE ASE karsten.madsen@ase.dk Tue Mark Jensen Test Ansvarlig KMD KMD tuj@kmd.dk Peter Gøtze Helle Elnegaard Test Ansvarlig KMD: Winnie Test Ansvarlig Frie Funktionærer KMD Frie Funktionærer pg@kmd.dk hje@f-f.dk Anders Ellegaard Dahl Projektleder AMS aeh@ams.dk Side 23 af 31

24 Alex Larsen Projektleder AMS Fleming Jensen Test Manager AMS 10.2 Ansvarsskema Ansvarsområde Personer Virksomhed Master Testplan Nicolai L. Nielsen KC Teststrategi Nicolai L. Nielsen/ Kenneth Lund KC Flemming Jensen AMS Beslutningstagere Anders Ellegaard Dahl (projektleder) AMS Ansvarlig for at udviklet funktionalitet er klar til test Godkendelse af den interne integrationstest Godkendelse af integrationstesten med A- kasserne Alex Larsen (projektleder) Flemming Jensen Kenneth Lund (Projektleder) Kenneth Lund Anders Ellegaard Dahl Hanne Skou Poulsen Mark Svensson Steffen Dyrberg Karsten Madsen Peter Gøtze Helle Elnegaard Flemming Jensen Nicolai L. Nielsen Nicolai L. Nielsen Flemming Jensen Kenneth Lund Hanne Skou Poulsen Mark Svensson Steffen Dyrberg Karsten Madsen Peter Gøtze Helle Elnegaard Release management Torben Espersen SF AMS AMS KC KC AMS Facilia FOA Netcompany ASE KMD Frie Funktionærer AMS KC KC AMS KC Facila FOA Netcompany ASE KMD Frie Funktionærer Side 24 af 31

25 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 Flemming Jensen Test manager Funktionstest Kundetest Integrationstest Driftstest Kenneth Lund Projektleder Review på testplaner Accepttest Integrationstest Driftstest Datakonverteringstest Anders Ellegaard Dahl Projektleder Review på testplaner Accepttest Integrationstest Driftstest Datakonverteringstest Alex Larsen Projektleder Review på testplaner Accepttest Integrationstest Driftstest Datakonverteringstest Hanne Skou Poulsen Test ansvarlig Komponenttest - Facilia Integrationstest - Facilia Mark Svensson Test ansvarlig Komponenttest - FOA eget system Integrationstest - FOA eget system Steffen Dyrberg Test ansvarlig Komponenttest - EMO & Modulus Integrationstest - EMO & Modulus Karsten Madsen Test ansvarlig Komponenttest - ASE eget system Integrationstest - ASE eget system Peter Gøtze Test ansvarlig Komponenttest - Winnie Integrationstest - Winnie KC AMS KC AMS AMS Facilia FOA Netcompany ASE KMD Side 25 af 31

26 Helle Elnegaard Test ansvarlig Komponenttest - FF eget system Integrationstest - FF eget system Frie Funktionæ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 RM Release Manager 10.5 Begreber Begreb AMP Eksterne aftagere TASS Match LOR Master Test Plan TDS Test specifikation Test Item Test procedure specifi- Beskrivelse Arbejdsmarkedsportalen (AMP) understøtter sagsbehandling og styring af beskæftigelsesindsatsen. Portalen er et fælles redskab for de professionelle aktører - på tværs af stat, kommuner, a-kasser og andre aktører. Leverandører af systemer til kommuner/jobcentre. En samlet funktionalitet, der understøtter jobcenterets og anden aktørs registrering af oplysninger om kontaktforløb herunder samtaler og resultatet af matchvurderinger og jobplanlægningen for borgere i Match-målgrupperne. Lead of the Reporter. Den ansvarlige leder (for en person som finder en afvigelse). Dette vil typisk være testlederen. Dette dokument. Indeholder Test Planen, alle Test Items og Test Specifikationer for alle Test Items. TransferDataService. Flytte- og opstartsdata servicen som benyttes til at flytte borgere mellem jobcentre og til at flytte data i forbindelse med opstart af systemer fra kommunale leverandører. 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. Det enkelte element (genstand), der er under test. Et dokument, der specificerer en rækkefølge af handlinger for afviklingen af en test Side 26 af 31

27 kation Test case Test log Test status rapport FogBugz (en samling af test cases). I IEEE 829 kaldes dette også Test procedure specification. Et sæt inputværdier, startbetingelser for afvikling, forventede resultater, postbetingelser 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. En kronologisk registrering (log) af relevante detaljer om afviklingen af test. Samlet statusrapport for gennemførte testarbejde. Bug-tracker. Benyttes til registrering og håndtering af afvigelser funder under test. Side 27 af 31

28 B Dokumentstruktur Figur 5: Dokumentstruktur Figur 5: Dokumentstruktur angiver dokumentstrukturen i forhold til master-testplanen samt de enkelte testprocedurer og test cases, der er omfattet af denne master-testplan. Formatted: Font: Not Bold (A) Projekt dokumenter (B) Test item input 1. Input til testplan 2. Input til testplan (C) Master testplan (D) Test case specifikation 4.Testdokumentation 5. Testdokumentation (E) Test procedure specifikation 6a. Input til testudførsel 6b. Input til testudførsel (F) Udfør tests 7a. Opret fejlrapport 7b. Ajourfør testlog (G) Fejlrapport (FogBugz) (H) Testlog 8a. Input til statusrapport 8b. Input tilstatusrapport (I) Send statusrapport 9. Send statusrapport Figur 5: Dokumentstruktur Side 28 af 31

29 C Det overordnede scope for testen i fase 1. DFDG- hændelse Beskrivelse Webservice-understøttelse: af hændelse 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) CancelUnemploymentEnrollmentVersion4 C CV kundenummer eller CV status ændres. (WSRM) GetCVStatusVersion5 F30 Servicebesked om oprettelse eller ændring af Jobplan (WSRM) GetJobplanStatus F31 F32 F33 F34 A-kasseskift og udmelding (MA og MT) Funktionscertifikater brug af disse til op- kobling- CodeListService WSRM-kø Servicebesked om sygdom, raskmelding, ferie eller mindre intensiv indsats. Der kan også være registreret en opdatering eller sletning af hændelsen. - Skift af a-kasse - Udmelding af a-kasse - Fremsendelse af uafsluttede fraværsforhold(servicebeskeder) ved a-kasseskift A-kasse kan oprette adgang til CodeListServer og hente relevante Codelister. A-kasse kan åbne, tømme og afslutte WSRM-køen korrekt (WSRM) GetAbsenceVersion5 og GetDeleteAbsenceVersion5 Bl.a. (WSRM) GetMembershipCancellation CodeListService: ClientCategoryTypeIdentifier RemovalCauseTypeIdentifier CVStatusIdentifier JobplanStatusIdentifier AbsenceTypeIdentifier CurrentUnemploymentStatusTypeIdentifier Side 29 af 31

30 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 vedkommende har registreret en a-kasse A-kassetester tilmelder person som dimittend og vedkommende har ej registreret en a-kasse A-kassetester opdaterer a- kassetilhørsforhold i akasseregistret (MT-afsendes) for en dimittend og dato for dagepengeret er d.d. A-kassetester tilmelder person til jobcentret (gamle T09) GetUnemploymentEnrollmentVersion4 Skubbes på WSRM-kø. A-kasse registrerer tilmelding i eget system Ingenting GetUnemploymentEnrollmentVersion4 Skubbes på WSRM-kø. A-kasse registrerer tilmelding i eget system 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 a- kassen A-kassetester framelder person A-kassetester udmelder person af a-kasse CancelUnemploymentEnrollmentVersion4 Skubbes på WSRM-kø. A-kasse registrerer afmelding i eget system "CancelUnemploymentEnrollmentVersion4 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 utilgængeligt for søgning GetCVStatusVersion5 skubbes på WSRM-kø. A-kasse registrerer ændring i eget system A-kassetester sætter CV tilgængeligt for søgning GetCVStatusVersion5 skubbes på WSRM-kø. A-kasse registrerer ændring i eget system A-kassetester ændrer status på CV GetCVStatusVersion5 skubbes på WSRM-kø. A-kasse registrerer ændring i eget system DFDG- hændelse Hvorledes Resultat F30: Servicebesked om oprettelse eller ændring af Jobplan A-kassetester opretter jobplan GetJobplanStatus skubbes på WSRM-kø. A-kasse registrerer hændelse i eget system Side 30 af 31

31 A-kassetester ændrer eksisterende jobplan GetJobplanStatus 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-kassetester raskmelder en dagpengemodtager A-kassetester sygemelder en dimittend A-kasse registrerer ændring i eget system GetAbsenceVersion5 skubbes på WSRM-kø for datoen for raskmeldingen eller hvis datoen overskrides. A-kasse registrerer ændring i eget system og skal koble raskmeldingen til en sygemelding. GetAbsenceVersion5 skubbes på WSRM-kø på datoen for dagpengeret. DFDG- hændelse Hvorledes Resultat F33: Servicebesked om ferimelding A-kassetester opretter ferieforhold GetAbsenceVersion5 skubbes på WSRM-kø på datoen for registreringen. A-kasse registrerer ændring i eget system A-kassetester ændrer et eksisterende ferieforhold DFDG- hændelse Hvorledes Resultat F34: Mindre intensiv indsats A-kassetester angiver at dagpengemodtager er omfattet af mindre intensiv indsats (angiver barsel inden for 6 uger, på vej på pension inden for 6 uger) GetAbsenceVersion5 skubbes på WSRM-kø på datoen for registreringen. A-kasse registrerer ændring i eget system GetAbsenceVersion5 skubbes på WSRM-kø A-kasse registrerer ændring i eget system DFDG- hændelse Hvorledes Resultat Sletning af F31/F32/ F33/F34 A-kassetester sletter et fraværsforhold GetDeleteAbsenceVersion5 skubbes på WSRMkø A-kasse registrerer ændring i eget system DFDG- hændelse Hvorledes Resultat A-kasseskift A-kassetester skifter a- kassemedlemskab på en tilmeldt dagpengemodtager (MThændelse) GetUnemploymentEnrollmentVersion4 Skubbes på WSRM-kø GetLatestInterviewdate skubbes på WSRM-kø. A-kasse registrerer tilmelding i eget system GetAbsenceVersion5 for alle uafsluttede fraværsforhold skubbes på WSRM-kø. A-kasse registrerer ændringerne i eget system Side 31 af 31