Slettet: ARBEJDSMAR- KEDSSTYRELSEN ARBEJDSMARKEDSSTYRELSEN - A-KASSEKOMMUNIKATION VIA WEBSERVICES MASTER TEST PLAN Slettet: A- KASSEKOMMUNIKATION VIA WEBSERVICES Slettet: MASTER TEST PLAN VERSION 1.43 Slettet: 1. DATO 30. maj 2012 Slettet: 22. maj 2012 REFERENCE Anders Ellegaard Dahl FORFATTER Nicolai L. Nielsen Slettet: Nicolai L. Nielsen KONTRAKTNUMMER SF099 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 info@knowledgecube.net
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 rettet 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 GetLatestInterviewDate. Tilføjet JC for testdata for KMD (tidl. Organisator). 1.4 30. 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 13. Side 2 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 Side 3 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 Side 4 af 29
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 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. KT2 KT3 Side 5 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 DFDG- hændelse Beskrivelse 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 C F30 F31 F32 F33 F34 A-kasseskift og udmelding (MA og MT) CodeListService WSRM-kø CV kundenummer eller CV status ændres. Servicebesked om oprettelse eller ændring 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 Code- ListServer og hente relevante Codelister. A-kasse kan åbne, tømme og afslutte WSRM-køen korrekt Webservice-understøttelse: (WSRM) GetUnemploymentEnrollmentVersion4 GetLatestInterviewDate (WSRM) GetCancelUnemploymentEnrollmentVersion4 (WSRM) GetCVStatusVersion4 (WSRM) GetJobplanStatusVersion1 (WSRM) GetAbsenceVersion5 og GetDeleteAbsenceVersion5 Bl.a. (WSRM) GetMembershipCancellation CodeListService Yderligere informationer omkring beskrevne funktionalitet kan ses i dokumentet LB99_AMS_Akassekommunikation via webservices_løsningsbeskrivelse_fase1_v33 Slettet: 6 Slettet: 6 Slettet: 41 2.2 Event flows ID Testområde Metode Ansvarlig Miljø EvtFl01 EvtFl02 Procedurekrav Funktionel test af understøttelsen af event flows Intern integrationstest Funktionel test af event flows Ekstern Integrationstest Kombination af manuel og automatiseret webservice test Manuel test KC A-Kasse leverandør / KC Alle test cases udformes med udgangspunkt i IEEE 829 standarden og leveres i Microsoft Word format inden KT2 KT3 Side 6 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) 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 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 KT2/3 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 Forudsætninger for brug at funktionscertifikater er opfyldt jf. LB99_AMS_A-kassekommunikation via webservices_løsningsbeskrivelse_generelt_v30 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 Side 7 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 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 Intern Integrationstest (KC) 15-06-2012 A-kasse test fase 1 slot 1 18-06-2012 20-07-2012 A-kasse test fase 1 slot 2 06-08-2012 07-09-2012 A-kasse test fase 1 slot 3 13-08-2012 14-09-2012 Test Slot A-kasse A-kasse System Kommentar Side 8 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 A-kasse test fase 1 slot 2 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 A-kasse test fase 1 slot 3 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 Slettet: 1.1 Slettet: 94 Slettet: ASE Slettet: Eget system Slettet: 1 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 Side 9 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 (P 1 ) 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 Testmiljø klar Udviklet funktionalitet klar Testprocedurerudarbejdet og reviewet Exit kriterier 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 (P 2 ) Formål Alle test cases der er fejlet udføres mindst en gang med henblik på at verificere rettelser i løsningen, og derved sikre 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. Entry kriterier Teststatusrapport for P 1 udført og afleveret Alle åbne Fogbugz-sager efter afslutning af P 1 Exit kriterier Alle planlagte test cases er gennemløbet Alle fejl er dokumenteret i FogBugz Side 10 af 29
skal være analyseret Test log leveret med oversigt over testens forløb Test Pass 3 (P 3 ) 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 udføres løbende gentest og regressionstest efter behov, eksempelvis i forbindelse med miljøsikringer. Entry kriterier Teststatusrapport for P 2 udført og afleveret Alle åbne Fogbugz-sager efter afslutning af P 2 skal være analyseret Exit kriterier 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 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. https://dokumentationsarkiv.knowledgecube.net/forvaltning/forvaltningshaandbog.pdf Figur 4: Grundlæggende rapportering, rettelse og gentest af fejl i FogBugz. Side 11 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 testes i det samlede systemkompleks. 4.3.2 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) 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 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 mindst 3 gange (jf. 3-pass strategi). 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. 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 Side 12 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å integrationstesten mod AMS KT2/3 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. 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 ugentligt 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 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 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 Entry 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 Exit kriterier 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 integrationstest. Der er leveret en testrapport til AMS, der dokumenterer og vurderer resultatet af den samlede, eksterne integrationstest. Aktører Aktør AMS SF KC Inddragelse Deltager på teststatusmøder Deployments til testmiljøer KC vil deltage aktivt i dette testforløb og være inddraget i følgende testaktiveteter: Dannelse af testdata Side 13 af 29
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 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 distribueres til alle aktører, således at alle har et samlet overblik over hvilke fejlrettelser, der er med til en given release. 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 Side 14 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 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. 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 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 KT2, er en række jobcentre fordelt som vist i nedenstående skema. Side 15 af 29
Det er muligt at ønske testdata på specifikke jobcentre. Dette gøres ved at benytte blanketten til bestilling af testdata 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 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 Hvidovre og Herning Brøndby, Faaborg-Midtfyn, Glostrup, Vesthimmerland Assens, Ballerup, Billund, Bornholm 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. Testområde Testmiljø Arbejdsmarkedsportalen amportalt3.knowledgecube.net servicet3.knowledgecube.net printt3.knowledgecube.net okot3.knowledgecube.net vit3.knowledgecube.net 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 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 KT2, er en række jobcentre fordelt som vist i nedenstående skema. Side 16 af 29
Det er muligt at ønske testdata på specifikke jobcentre. Dette gøres ved at benytte blanketten til bestilling af testdata 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 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 Hvidovre og Herning Brøndby, Faaborg-Midtfyn, Glostrup, Vesthimmerland Assens, Ballerup, Billund, Bornholm 7.3 Testmiljø T8 URL (SF/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: 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 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. Side 17 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 gennemfø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 testens begyndelse. 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: 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 Could not test 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). 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. Side 18 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 interne 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 Test readiness review Test Slot 2 Test readiness review Test Slot 3 - Integrationstest (slot 1) - Integrationstest (slot 2) - Integrationstest (slot 3) KC A-Kasser KC A-Kasser KC A-Kasser Test statusmøde - Integrationstest KC AMS Mandag 11/6 Mandag 30/7 Mandag 6/8 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 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 Ingen fejl Side 19 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 arbejdsgangen 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 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. 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: Side 20 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 tn@knowledgecube.net Nicolai L. Nielsen Test Manager KC nln@knowledgecube.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 Tieto Steffen.Dyhrberg@tieto.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 Alex Larsen Projektleder AMS all@ams.dk Fleming Jensen Test Manager AMS flj@ams.dk 10.2 Ansvarsskema Ansvarsområde Personer Virksomhed Master Testplan Nicolai L. Nielsen KC Teststrategi Nicolai L. Nielsen/ Tøger Nørgaard KC Flemming Jensen AMS Beslutningstagere Anders Ellegaard Dahl (projektleder) AMS Alex Larsen (projektleder) AMS Flemming Jensen AMS Tøger Nørgaard (Projektleder) KC Ansvarlig for at udviklet funktionalitet er Tøger Nørgaard KC Side 21 af 29
klar til test Godkendelse af den interne integrationstest Godkendelse af intgrationstesten med A- kasserne 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 Tøger Nørgaard Hanne Skou Poulsen Mark Svensson Steffen Dyrberg Karsten Madsen Peter Gøtze Helle Elnegaard Release management Torben Espersen SF AMS Facilia FOA Tieto ASE KMD Frie Funktionærer AMS KC KC AMS KC Facila FOA Tieto ASE KMD Frie Funktionærer 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 Tøger Nørgaard Projektleder Review på testplaner Accepttest Integrationstest Driftstest Datakonverteringstest KC AMS Anders Ellegaard Projektleder Review på testplaner AMS KC Side 22 af 29
Dahl 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 Helle Elnegaard Test ansvarlig Komponenttest - FF eget system Integrationstest - FF eget system AMS Facilia FOA Tieto ASE KMD 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 Side 23 af 29
RM Release Manager 10.5 Begreber Begreb AMP Eksterne aftagere TASS Match LOR Master Test Plan TDS Test specifikation Test Item Test procedure specifikation Test case Test log Test status rapport FogBugz 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 (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 24 af 29
B 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. Figur 5: Dokumentstruktur Side 25 af 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) GetCancelUnemploymentEnrollmentVersion4 C CV kundenummer eller CV status ændres. (WSRM) GetCVStatusVersion4 F30 Servicebesked om oprettelse eller ændring af Jobplan (WSRM) GetJobplanStatusVersion1 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 Slettet: 6 Slettet: 6 Formateret: Skrifttype: Times New Roman, Ingen understregning Formateret: Skrifttype: Times New Roman Formateret: Skrifttype: Times New Roman, Ingen understregning Formateret: Skrifttype: Times New Roman Formateret: Skrifttype: Times New Roman, Ingen understregning Formateret: Skrifttype: Times New Roman, Ingen understregning Formateret: Skrifttype: Times New Roman, Ingen understregning Formateret: Skrifttype: Times New Roman, Ingen understregning Formateret: Skrifttype: Times New Roman, Ingen understregning Side 26 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 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 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 A kassetester opretter CV GetCVStatusVersion5 skubbes på WSRM-kø. eller CV status ændres. A-kasse registrerer ændring i eget system A kassetester sætter CV utilgængeligt for søgning A kassetester sætter CV tilgæ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: 10 pkt Side 27 af 29
DFDG hændelse Hvorledes Resultat F30: Servicebesked om oprettelse eller ændring af Jobplan A-kassetester opretter jobplan GetJobplanStatusVersion1 skubbes på WSRMkø. A-kasse registrerer hændelse i eget system A-kassetester ændrer eksisterende jobplan GetJobplanStatusVersion1 skubbes på WSRMkø. 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 Formateret tabel Slettet: 6 Slettet: GetCancelUnemploymentEnrollmentVersion4 skubbes på WSRM-køen efterfølgende F32 (automatisk afmelding A som følge af sygemelding) A-kassetester raskmelder en dagpengemodtager A-kassetester sygemelder en dimittend 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. Slettet: 6 Slettet: GetUnemploymentEnrollmentVersion4 skubbes på WSRM-køen efterfølgende F31 (automatisk Tilmelding T som følge af raskmelding)... [1] DFDG hændelse Hvorledes Resultat F33: Servicebesked om A-kassetester opretter ferieforhold GetAbsenceVersion5 skubbes på WSRM-kø på ferimelding datoen for registreringen. Slettet: 6 A-kassetester ændrer et eksisterende ferieforhold A-kasse registrerer ændring i eget system GetAbsenceVersion5 skubbes på WSRM-kø på datoen for registreringen. A-kasse registrerer ændring i eget system Slettet: 6 DFDG hændelse Hvorledes Resultat F34: Mindre intensiv indsats A kassetester angiver at dagpengemodtager er omfattet af mindre intensiv indsats (angi GetAbsenceVersion5 skubbes på WSRM-kø A-kasse registrerer ændring i eget system Slettet: 6 Side 28 af 29
ver barsel inden for 6 uger, på vej på pension inden for 6 uger) DFDG hændelse Hvorledes Resultat Sletning af A kassetester sletter et fraværsforhold GetDeleteAbsenceVersion5 skubbes på WSRMkø F31/F32/ F33/F34 Slettet: 6 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ø (eksisterende hændelse i DFDG) A-kasse registrerer tilmelding i eget system GetAbsenceVersion5 for alle uafsluttede fraværsforhold skubbes på WSRM-kø. Slettet: 6 A-kasse registrerer ændringerne i eget system Side 29 af 29
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.