master test plan - star · arbejdsmarkedsstyrelsen · a-kassekommunikation via webservices ·...
TRANSCRIPT
Knowledge Cube A/S · Bernstorffsgade 50, 7. sal · DK 1577 København V · T +45 33 98 46 00 F +45 33 14 46 00
CVR 28 51 04 89 · www.knowledgecube.net · [email protected]
ARBEJDSMARKEDSSTYRELSEN - A-KASSEKOMMUNIKATION VIA WEBSERVICES
MASTER TEST PLAN
VERSION 1.43
DATO 30. maj 2012
REFERENCE Anders Ellegaard Dahl
FORFATTER Nicolai L. Nielsen
KONTRAKTNUMMER SF099
Slettet: ARBEJDSMAR-KEDSSTYRELSEN
Slettet: A-KASSEKOMMUNIKATION VIA WEBSERVICES
Slettet: MASTER TEST PLAN
Slettet: 1.
Slettet: 22. maj 2012
Slettet: Nicolai L. Nielsen
Arbejdsmarkedsstyrelsen · A-kassekommunikation via webservices · Master Test Plan ·
Version 1.3 · 30. maj 2012
Side 2 af 29
DOKUMENTVERSIONER
Version Dato Initialer Afsnit Ændringer
1.0 25. april 2012 NLN Alle MTP for test i forbindelse med A-Kasse kommunikation via webservices.
1.1 26. april 2012 NLN Alle Opdateret med GetAbsenceVersion6 samt workflows afledt af sygeraskprojektet. Samt opdateret på baggrund af kommentarer fra AMS
1.2 7. maj 2012 NLN 10 Ændringer til personskema. Organisator ret-tet til KMD
1.3 22. maj 2012 TN 2.1, 7.1.1, 7.2.1, C, D
Konsekvensrettelse i forhold til versionering af GetAbsence samt tilføjelse af GetLatestIn-terviewDate. Tilføjet JC for testdata for KMD (tidl. Organisator).
1.4 30. maj 2012 TN Fjernet workflows afledt af syge/rask-projektet, herunder er GetAbsence rettet til version5. Der henvises nu til LB 3.3 ASE er flyttet til testslot 13.
Arbejdsmarkedsstyrelsen · A-kassekommunikation via webservices · Master Test Plan ·
Version 1.3 · 30. maj 2012
Side 3 af 29
INDHOLDSFORTEGNELSE
1 INTRODUKTION 5
2 TEST ITEMS 5
2.1 Fase 1 webservices 5 2.2 Event flows 6 2.3 Funktionscertifikater 7
3 PLAN FOR TESTAKTIVITETER 8
4 TEST TILGANG 9
4.1 Gentest og regressionstest 11 4.2 Rapportering af fejl 11 4.3 Test faser for AMS leverandører 12 4.3.1 Fabriksprøven 12 4.3.2 Accept kriterier 12 4.3.3 Afvikling af den interne integrationstest 12 4.4 Test faser for eksterne aftagere 13 4.4.1 Afvikling af komponenttest hos A-kasser 13 4.4.2 Afvikling af den eksterne integrationstest med A-kasser 13
5 PERFORMANCETEST 14
6 RELEASE HÅNDTERING 14
6.1 Releaseplan 14 6.2 Release notes 14 6.3 Release Leveranceprocedure 14 6.4 Release miljøsikring 15
7 TESTMILJØER 15
7.1 Testmiljø - T2 URL (intern integration/kundetest) 15 7.1.1 Fordeling af kommuner og jobcentre 15 7.2 Testmiljø - T3 URL (ekstern integration) 16 7.2.1 Fordeling af kommuner og jobcentre 16 7.3 Testmiljø – T8 URL (SF/AMP Build Verification/Deployment) 17
8 LEVERING AF TESTDATA 17
8.1 Konfiguration af testmiljøer (WSRM) 18
9 TEST STATUS 18
9.1 Statuskategorier 18 9.2 Test metrikker 18 9.3 Testrapportering 18 9.4 Mødeoversigt 19 9.5 Generelle accept- og stopkriterier 19
Arbejdsmarkedsstyrelsen · A-kassekommunikation via webservices · Master Test Plan ·
Version 1.3 · 30. maj 2012
Side 4 af 29
10 ORGANISERING 21
10.1 Personskema 21 10.2 Ansvarsskema 21 10.3 Procesgodkendelse 22
A GLOSSARY 23
10.4 Aktører 23 10.5 Begreber 24
B DOKUMENTSTRUKTUR 25
C DET OVERORDNEDE SCOPE FOR TESTEN I FASE 1. 26
D WORKFLOWS DER BØR EFTERPRØVES AF A-KASSERNE I INTEGRATIONSTESTEN. 27
Arbejdsmarkedsstyrelsen · A-kassekommunikation via webservices · Master Test Plan ·
Version 1.3 · 30. maj 2012
Side 5 af 29
1 Introduktion Dette dokument beskriver rammerne for testen af AMS projekt A-kassekommunikation via webservices og be-skriver dermed hvad der skal testes, samt hvis ansvar det er at udføre de respektive tests. Det primære formål med denne testplan er at klargøre hvilke testmæssige tiltag der er nødvendige for at sikre at de af kunden og leverandøren definerede krav til A-kassekommunikation via webservices overholdes. Master Test Planen er et vigtigt holdepunkt for alle involverede aktører. Det er derfor nødvendigt, at alle aktører læser testplanen igennem og forholder sig til indholdet. Afsnit 2: indeholder alle test items, altså de elementer, der skal testes i forbindelse med A-kassekommunikation via webservices, samt hvordan hvert enkelt element skal testes. Afsnit 3: beskriver testtilgangen; hvordan den strukturerede test skal afvikles, hvordan fejl skal rapporteres og gentestes, samt hvordan der skal regressionstestes. Afsnit 4: beskriver de forskellige testfaser, hvem der er ansvarlige for hvad, samt hvornår er der planlagt mile-pæle og leverancer. Afsnit 5: Omhandler performance test og tilgangen til dette. Afsnit 6, 7 og 8: omhandler releases, testmiljøer og håndtering af testdata. Afsnit 9: beskriver teststatus, kontrol og rapportering på testfremdriften i form af metrikker, skriftlige statusrap-porter, møder osv. Afsnit 10: beskriver hvordan testprojektet er organiseret og hvem der er involveret.
2 Test Items
2.1 Fase 1 webservices
ID Testområde Metode Ansvarlig Miljø
F1WS01 Systemtest (funktionel) af webservices – Intern Integra-tionstest
Automatiseret test KC KT2
F1WS02 Systemtest (funktionel) af A-kasse funktioner der aftager webservice – Komponenttest.
Manuel test A-Kasse leveran-dør
KT2
F1WS03 Integration mod udstillede webservices – Ekstern Inte-gratrionstest
Manuel test A-Kasse leveran-dør / KC
KT3
Procedurekrav
Alle test cases udformes med udgangspunkt i IEEE 829 standarden og leveres i Microsoft Word format in-den testens begyndelse.
Test cases skal være reviewet inden testafviklingen begynder. Alle afvigelser fundet under testen skal registreres i FogBugz. Testen dokumenteres i test summary rapport.
Arbejdsmarkedsstyrelsen · A-kassekommunikation via webservices · Master Test Plan ·
Version 1.3 · 30. maj 2012
Side 6 af 29
Afhængigheder
Testen af dette test-item forudsætter at følgende er klar til test: Det fælles datagrundlag Webservices A-Kasse integration mod webservices Funktionscertifikater WSRM opsætning jf. afsnit 8.1 Konfiguration af testmiljøer (WSRM)
Funktionalitetsoversigt
Yderligere informationer omkring beskrevne funktionalitet kan ses i dokumentet LB99_AMS_A-kassekommunikation via webservices_løsningsbeskrivelse_fase1_v33
DFDG- hændelse Beskrivelse af hændelse
Webservice-understøttelse:
T, A T: Tilmelding af person i jobcenter A: Afmelding af person i jobcenter eller ophør af medlemskab i a-kassen
(WSRM) GetUnemploymentEnrollmentVersion4 GetLatestInterviewDate (WSRM) GetCancelUnemploymentEnrollmentVersion4
C CV kundenummer eller CV status æn-dres.
(WSRM) GetCVStatusVersion4
F30 Servicebesked om oprettelse eller æn-dring af Jobplan
(WSRM) GetJobplanStatusVersion1
F31 F32 F33 F34
Servicebesked om sygdom, raskmel-ding, ferie eller mindre intensiv indsats. Der kan også være registreret en opdate-ring eller sletning af hændelsen.
(WSRM) GetAbsenceVersion5 og GetDeleteAbsenceVersion5
A-kasseskift og udmelding (MA og MT)
Skift af a-kasse Udmelding af a-kasse Fremsendelse af uafsluttede fraværsfor-hold(servicebeskeder) ved a-kasseskift
Bl.a. (WSRM) GetMembershipCancellation
CodeListService A-kasse kan oprette adgang til Code-ListServer og hente relevante Codelister.
CodeListService
WSRM-kø A-kasse kan åbne, tømme og afslutte WSRM-køen korrekt
2.2 Event flows
ID Testområde Metode Ansvarlig Miljø
EvtFl01 Funktionel test af understøttelsen af event flows – Intern integrationstest
Kombination af ma-nuel og automatiseret webservice test
KC KT2
EvtFl02 Funktionel test af event flows – Ekstern Inte-grationstest
Manuel test A-Kasse leverandør / KC
KT3
Procedurekrav
Alle test cases udformes med udgangspunkt i IEEE 829 standarden og leveres i Microsoft Word format inden
Slettet: 6
Slettet: 6
Slettet: 41
Arbejdsmarkedsstyrelsen · A-kassekommunikation via webservices · Master Test Plan ·
Version 1.3 · 30. maj 2012
Side 7 af 29
testens begyndelse. Test cases skal være reviewet inden testafviklingen begynder. Alle afvigelser fundet under end-to-end test registreres i FogBugz. Testen dokumenteres i test summary rapport.
Afhængigheder
Testen af dette test-item forudsætter at følgende er klar til test: Det fælles datagrundlag Webservices A-Kasse integration mod webservices Funktionscertifikater WSRM opsætning jf. afsnit 8.1 Konfiguration af testmiljøer (WSRM)
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 Funktionel test af brugen af Funktionscertifi-kater
Manuel test A-Kasse leverandør
KT2/3
Procedurekrav
Alle test cases udformes med udgangspunkt i IEEE 829 standarden og leveres i Microsoft Word format in-den testens begyndelse.
Test cases skal være reviewet inden testafviklingen begynder. Alle afvigelser fundet under end-to-end test registreres i FogBugz. Testen dokumenteres i test summary rapport.
Afhængigheder
Testen af dette test-item forudsætter at følgende: Afvikling af test mod test items 2.1 & 2.2 Forudsætninger for brug at funktionscertifikater er opfyldt jf. LB99_AMS_A-kassekommunikation via web-services_løsningsbeskrivelse_generelt_v30
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
Arbejdsmarkedsstyrelsen · A-kassekommunikation via webservices · Master Test Plan ·
Version 1.3 · 30. maj 2012
Side 8 af 29
funktionscertifikat pr. a-kasse. Testafviklingen gennemføres som en del af den beskrevne test mod items 2.1 & 2.2, således at funktionscertifi-katerne anvendes i denne test og derved indirekte testes.
3 Plan for testaktiviteter Følgende afsnit indeholder en oversigt over testafvikligen med de enkelte A-kassser.
Aktivitet Startdato Slutdato
Intern Integrationstest (KC) 15-06-2012
A-kasse test fase 1 slot 1 18-06-2012 20-07-2012
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
Arbejdsmarkedsstyrelsen · A-kassekommunikation via webservices · Master Test Plan ·
Version 1.3 · 30. maj 2012
Side 9 af 29
nummer
A-kasse test fase 1 slot 1
1.1 17 FOA Eget system
1.1 15 3FA Facilia
1.1 76 Danske Sundhedsorg. A-kasse Facilia
1.1 95 Dana Facilia
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
4 Test tilgang Som en del af udviklingsarbejdet vil der med sikkerhed blive introduceret fejl i løsningen eller integrationen til nogle af de øvrige systemer. Efter der er blevet testet, fundet fejl og rettet fejl, vil der være behov for yderligere
Slettet: 1.1
Slettet: 94
Slettet: ASE
Slettet: Eget system
Slettet: 1
Arbejdsmarkedsstyrelsen · A-kassekommunikation via webservices · Master Test Plan ·
Version 1.3 · 30. maj 2012
Side 10 af 29
tests. For at tage højde for denne ekstra testindsats, tager den strukturerede test udgangspunkt i en "three pass" strategi for testafviklingen, der er baseret på, at planlagte test cases afvikles over tre iterationer som en del af den formaliserede test. ”Three pass” strategien gælder for struktureret test på alle testniveauer, og gennemføres efter følgende princip.
Figur 2: Integrationstest over 3 iterationer.
Det overordnede formål med hvert enkelt af de tre testgennemløb er kort beskrevet herunder.
Test Pass 1 (P1)
Formål
Alle planlagte test cases udføres mindst en gang med henblik på at finde så mange af de fejl, der er i den udviklede løsning. Alle fejl oprettes i FogBugz og sendes til den, der har ansvaret for at rette de identificerede fejl. Der udfø-res løbende gentest og regressionstest efter behov, eksempelvis i forbindelse med miljøsikringer.
Entry kriterier Exit kriterier
Testmiljø klar Udviklet funktionalitet klar Testprocedurerudarbejdet og reviewet
Alle planlagte test cases er gennemløbet Alle fejl er dokumenteret i FogBugz Test log leveret med oversigt over testens forløb
Test Pass 2 (P2)
Formål
Alle test cases der er fejlet udføres mindst en gang med henblik på at verificere rettelser i løsningen, og derved sik-re at disse gentestes. Alle fejl oprettes i FogBugz og sendes til den, der har ansvaret for at rette de identificerede fejl. Der udføres løbende gentest og regressionstest efter behov, eksempelvis i forbindelse med miljøsikringer.
Entry kriterier Exit kriterier
Teststatusrapport for P1 udført og afleveret Alle åbne Fogbugz-sager efter afslutning af P1
Alle planlagte test cases er gennemløbet Alle fejl er dokumenteret i FogBugz
Arbejdsmarkedsstyrelsen · A-kassekommunikation via webservices · Master Test Plan ·
Version 1.3 · 30. maj 2012
Side 11 af 29
skal være analyseret Test log leveret med oversigt over testens forløb
Test Pass 3 (P3)
Formål
Alle planlagte test cases udføres en gang med henblik på at verificere, at rettelser ikke har introduceret nye fejl i løsningen. Alle fejl oprettes i FogBugz og sendes til den, der har ansvaret for at rette de identificerede fejl. Der ud-føres løbende gentest og regressionstest efter behov, eksempelvis i forbindelse med miljøsikringer.
Entry kriterier Exit kriterier
Teststatusrapport for P2 udført og afleveret Alle åbne Fogbugz-sager efter afslutning af P2
skal være analyseret
Alle planlagte test cases er gennemløbet Alle fejl er dokumenteret i FogBugz Test log leveret med oversigt over testens forløb
Hvis der til stadighed findes fejl i det 3. test pass bør man overveje gennemførelsen af endnu et test pass.
4.1 Gentest og regressionstest Gennem alle testfaser har leverandøreren ansvar for at genteste rettelser til fundne fejl. Regressionstest benyttes løbende igennem hele testforløbet, hver gang fejl fundet under test bliver rettet. Det er de enkelte leverandørers ansvar at udføre regressionstest, samt at vurdere hvornår dette er nødvendigt. Derudover udfører Systemforvalter begrænset regressionstest (miljøsikring) af AMS systemkompleks, når der lægges ny kode i testmiljøer. Regressionstest gennemføres som et absolut minimum som afslutningen af en test fase. Dette gøres for at sikre at man ikke ødelægger eksisterende funktionalitet (eller genintroducerer gamle fejl) i forbindelse med implemente-ringen af nye features eller fejlrettelser.
4.2 Rapportering af fejl Den grundlæggende proces ved rapportering af en fejl (bug) i FogBugz er vist i Figur 4. For yderligere informa-tion henvises til forvaltningshåndbogens afsnit 3. https://dokumentationsarkiv.knowledgecube.net/Forvaltning/Forvaltningshaandbog.pdf
Figur 4: Grundlæggende rapportering, rettelse og gentest af fejl i FogBugz.
Arbejdsmarkedsstyrelsen · A-kassekommunikation via webservices · Master Test Plan ·
Version 1.3 · 30. maj 2012
Side 12 af 29
4.3 Test faser for AMS leverandører I de følgende afsnit beskrives de test faser, som er relevante for AMS leverandører.
4.3.1 Fabriksprøven I forbindelse med udvikling hos AMS leverandører, er den enkelte leverandør ansvarlig for at kvalitetssikre alle leverancer inden levering til AMS testmiljøer. Testfasen skal sikre, at alle leverancer har en kvalitet så de kan te-stes i det samlede systemkompleks.
4.3.2 Accept kriterier
Accept kriterier
Entry kriterier Exit kriterier
FogBugz projekt oprettet Kravspecifikation/løsningsbeskrivelse dæk-
kende alle features er klar
Alle leverancer er kvalitetssikret inden leverance til AMS testmiljøer (KT2/KT3)
Der foreligger en reviewet Master Test Plan (dette dokument)
4.3.3 Afvikling af den interne integrationstest Integrationstesten afvikles, som beskrevet i afsnit 3, over 3 iterationer. Alle iterationer skal være gennemført og der skal være taget stilling til alle fundne fejl for at integrationstesten kan godkendes. Integrationstesten skal afvikles fra den grænseflade, som slutbrugeren skal benytte og testen skal afvikles i AMS KT2 testmiljø. Accept kriterier
Accept kriterier
Entry kriterier Exit kriterier
AMS Testmiljøer klar Udviklet funktionalitet klar Testprocedurer er udarbejdet og reviewet
af Systemforvalter Dokumentation klar - Kravspecifikation
opdateret
Alle test cases, der direkte (og udelukkende) afprøver integrationen i interne systemer er udført mindst 3 gange (jf. 3-pass strategi).
Alle test cases, der direkte afprøver integrationen i in-terne systemer, og som også skal udføres under inte-grationstest for eksterne systemer, er udført mindst en gang.
Aktører
Aktør Inddragelse
AMS • Deltager på teststatusmøder
SF • Deployments til testmiljøer
KC • Udførelse af test cases • Fejlretning • Dannelse af testdata • Verificering af korrekt testudførelse gennem udarbejdelse og verificering af testdata og –
cases. • Deltage i teststatusmøder
Arbejdsmarkedsstyrelsen · A-kassekommunikation via webservices · Master Test Plan ·
Version 1.3 · 30. maj 2012
Side 13 af 29
4.4 Test faser for eksterne aftagere I de følgende afsnit beskrives de test faser, som er relevante for eksterne aftagere.
4.4.1 Afvikling af komponenttest hos A-kasser A-Kasser er selv ansvarlige for at udføre en komponenttest af deres applikationer inden starten på integrationste-sten mod AMS KT2/3 testmiljø. For at den eksterne integrationstest kan startes er det en forudsætning at komponenttesten er afsluttet på tilfreds-stillende vis. Dvs.: Alle planlagte komponent test cases er gennemført. Blokerende fejl i A-kasse systemerne er rettet og gentestet.
4.4.2 Afvikling af den eksterne integrationstest med A-kasser Integrationstesten afvikles, som beskrevet i afsnit 3, over 3 iterationer. Alle iterationer skal være gennemført og der skal være taget stilling til alle fundne fejl for at integrationstesten kan godkendes. Derudover skal der ugent-ligt være afleveret test statusrapporter og en opdateret testlog. Integrationstesten skal afvikles i leverandørens system – fra business laget eller fra den grænseflade, som slut-brugeren skal benytte. Testes der på business laget skal leverandøren sikre at der fra grænsefladen, som slutbru-gerne skal benytte, kan udføres de test cases, som er planlagt i end-to-end testen. Leverandørens system skal væ-re integreret mod AMS KT3 testmiljø. Der må ikke benyttes stubbe/mocks objekter/detours. Hvis der benyttes testautomatisering, skal test cases være implementeret så de testes på det øverste lag – det lag som slutbrugeren skal benytte applikationen fra (dvs. der må under ingen omstændigheder testes direkte på OLTP/Service/Webservice lag). Accept kriterier
Accept kriterier
Entry kriterier Exit kriterier
Systemforvalter: Testmiljøer klar Testprocedurer er udarbejdet og reviewet
af Systemforvalter WSRM opsætning er gennemført
Eksterne:
Testlog som beskriver status på afviklede komponent test cases er afleveret til AMS/Systemforvalter
Funktionscertifikater er klar WSRM bestilling er gennemført
Alle test cases, der vedrør integrationen med eksterne systemer, er udført mindst 3 gange.
Der forligger en testlog for hver ekstern aktør, der dokumenterer resultatet af den eksterne integrations-test.
Der er leveret en testrapport til AMS, der dokumente-rer og vurderer resultatet af den samlede, eksterne in-tegrationstest.
Aktører
Aktør Inddragelse
AMS Deltager på teststatusmøder
SF Deployments til testmiljøer
KC KC vil deltage aktivt i dette testforløb og være inddraget i følgende testaktiveteter: • Dannelse af testdata
Arbejdsmarkedsstyrelsen · A-kassekommunikation via webservices · Master Test Plan ·
Version 1.3 · 30. maj 2012
Side 14 af 29
• Afvikling af kørsler - f.eks. af batchjobs • Verificering af korrekt testudførelse gennem udarbejdelse og verificering af testdata og –
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 relea-ses oftere. Jo tættere man kommer på release-dato, jo færre releases vil der forekomme. NB! A-kasse kommunikation via webservises er ikke en selvstændig release, og er derfor ikke beskrevet i en se-parat release plan. Features i forbindelse med A-kasserne er indeholdt i AMS releases 2012-1 & 2012-2 De planlagte releases kan findes på Systemforvalters Sharepoint, under ”Release dokumentation > Testmiljø-plan
6.2 Release notes Når en Bug ’resolves’ i FogBugz, skal den tildeles en specifik release (milestone) således at den person, der er ansvarlig for at lukke sagen, kan se, hvornår en given rettelse kan gentestes i et testmiljø. Det er ligeledes vigtigt, at leverandørerne opretter en release note til sagen i Fogbugz, når sagen løses, der i klart sprog beskriver hvordan fejlen er løst. Systemforvalter sørger for at danne en samlet release note til hver release i testperioderne. Denne release note di-stribueres til alle aktører, således at alle har et samlet overblik over hvilke fejlrettelser, der er med til en given re-lease. Den samlede release note dannes på baggrund af et releasenoteudtræk fra FogBugz. Dette udtræk foretages på releasedagen kl. 10.00, hvorfor alle release notes skal være påført løste sager senest kl. 09.30.
6.3 Release Leveranceprocedure Leveranceprocedurerne som følger:
Leverance til SF for AMP og Jobnet Levering af installationspakker (vejledninger, kode, DB scripts) skal ske senest 18:30 dagen inden release (man/ons). Se skema for procedure:
Miljø Senest levering fra UL (man/ons)
Installation (tirs/tors)
Miljøsikring (ons/fre)
Klarmelding (ons/fre)
KT2 KL. 18:30 Kl. 22:00 Kl. 03:00 KL. 09:00
Arbejdsmarkedsstyrelsen · A-kassekommunikation via webservices · Master Test Plan ·
Version 1.3 · 30. maj 2012
Side 15 af 29
KT3 KL. 18:30 Kl. 21:00 Kl. 04:00 KL. 09:00
KT4 KL. 18:30 Kl. 22:00 Kl. 05:00 KL. 09:00
KT9 KL. 18:30 Kl. 21:15 Kl. 07:00 KL. 09:00 Løbende vil der tirsdag/torsdag tentativt blive installeret og miljøsikret automatisk i AMS testmiljøer fra klokken 22:00 – dvs. uden for normal arbejdstid. Der vil på installationsdagen blive udsendt en announcement senest klokken 15:00 og status for installation udsendes klokken ca. 09:00 den efterfølgende dag.
6.4 Release miljøsikring Ved hver release skal der foretages en miljøsikring af alle systemer for at sikre, at der ikke er blokerende fejl i det installerede. Der laves automatisk en miljøsikringsrapport, som vil udgøre beslutningsgrundlaget for godken-delse eller en eventuel ny release. Hvis der findes blokerende fejl, beslutter Systemforvalterens Release Manager om der skal foretages en ny installation. Når en release til et testmiljø er godkendt, udsendes der en announcement på Systemforvalters Sharepoint (do-kumentationsarkivet) – det samme gør sig gældende, hvis en planlagt release forsinkes.
7 Testmiljøer Hvert af testmiljøerne består af en fuld kopi af arbejdsmarkedsportalen, Jobnet og SAS/BI platformen. Der benyttes følgende testmiljøer til test af A-kassekommunikation via webservices:
• KT2 - benyttes til Integrationstest til de interne systemer. • KT3 - benyttes til Integrationstest til eksterne systemer. • KT8 – benyttes til Build Verification Deployment hos Systemforvalter
7.1 Testmiljø - T2 URL (intern integration/kundetest) Herunder er URL’erne til testmiljø T2 angivet for henholdsvis Arbejdsmarkedsportalen og Jobnet: Dette testmiljø benyttes til integrationstest af de interne systemer, samt til Kundetesten.
Testområde Testmiljø
Arbejdsmarkedsportalen
• amportalT2.knowledgecube.net • serviceT2.knowledgecube.net • printT2.knowledgecube.net • okoT2.knowledgecube.net • viT2.knowledgecube.net
Jobnet
• CVBank: https://job-kt2.jobnet.dk/cv • Jobbanken: https://job-kt2.jobnet.dk/jobbanken • CVAdmin: https://cvadmin-kt2.jobnet.dk/CV_admin/
Resurseplanlægger • amportalT2.knowledgecube.net (link på AMP forsiden)
7.1.1 Fordeling af kommuner og jobcentre Konkret vil testdata bestå af adgang til et antal medlemmer fra en given a-kasse, hvor det vil være muligt at ud-føre de til fase 1 understøttede forretningsmæssige operationer via (test-udgaverne af) Arbejdsmarkedsportalen eller Jobnet, som så vil afspejle sig som hændelser på WSRM-køen. For at sikre at flere organisationer ikke – utilsigtet – benytter overlappende testdata i KT2, er en række jobcentre fordelt som vist i nedenstående skema.
Arbejdsmarkedsstyrelsen · A-kassekommunikation via webservices · Master Test Plan ·
Version 1.3 · 30. maj 2012
Side 16 af 29
Det er muligt at ønske testdata på specifikke jobcentre. Dette gøres ved at benytte blanketten til bestilling af test-data i dokumentationsarkivet og fremsende denne senest 14 dage før start af test. Ønskerne vil i videst muligt omfang søges tilgodeset. Såfremt der ikke fremsendes ønsker vil testdata blive tildelt administrativt.
Organisation Kommune/Jobcenter
AMS København, Frederiksberg
Knowledge Cube Vejle, Vordingborg, Langeland, Jammerbugten, Brøndby
Systemforvalter Esbjerg, Skanderborg
Business DK Nordfyn, Køge
Miracle/ASE Ringkjøbing-Skjern/Ringsted
Facilia
FOA Hvidovre og Herning
Tieto Brøndby, Faaborg-Midtfyn, Glo-strup, Vesthimmerland
KMD Assens, Ballerup, Billund, Born-holm
Frie Funktionærer
7.2 Testmiljø - T3 URL (ekstern integration) Herunder er URL’erne til testmiljø T3 angivet for henholdsvis Arbejdsmarkedsportalen og Jobnet: Dette testmiljø benyttes til Integrationstest til eksterne systemer.
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 ud-føre de til fase 1 understøttede forretningsmæssige operationer via (test-udgaverne af) Arbejdsmarkedsportalen eller Jobnet, som så vil afspejle sig som hændelser på WSRM-køen. For at sikre at flere organisationer ikke – utilsigtet – benytter overlappende testdata i KT2, er en række jobcentre fordelt som vist i nedenstående skema.
Arbejdsmarkedsstyrelsen · A-kassekommunikation via webservices · Master Test Plan ·
Version 1.3 · 30. maj 2012
Side 17 af 29
Det er muligt at ønske testdata på specifikke jobcentre. Dette gøres ved at benytte blanketten til bestilling af test-data i dokumentationsarkivet og fremsende denne senest 14 dage før start af test. Ønskerne vil i videst muligt omfang søges tilgodeset. Såfremt der ikke fremsendes ønsker vil testdata blive tildelt administrativt.
Organisation Kommune/Jobcenter
AMS København, Frederiksberg
Knowledge Cube Vejle, Vordingborg, Langeland, Jammerbugten, Brøndby
Systemforvalter Esbjerg, Skanderborg
Business DK Nordfyn, Køge
Miracle/ASE Ringkjøbing-Skjern/Ringsted
Facilia
FOA Hvidovre og Herning
Tieto Brøndby, Faaborg-Midtfyn, Glo-strup, Vesthimmerland
KMD Assens, Ballerup, Billund, Born-holm
Frie Funktionærer
7.3 Testmiljø – T8 URL (SF/AMP Build Verification/Deployment) Herunder er URL’erne til testmiljø T8 angivet for henholdsvis Arbejdsmarkedsportalen og Jobnet.
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 fik-tive (anonymiserede) CPR nr. frem for reelle CPR nr. De fiktive CPR nr. dækker over personer, som også er gjort anonyme i forhold til navn, adresse samt kontaktoplysninger. Personen flytter dog ikke kommune eller job-center og får heller ikke ændret fødselsdato samt køn. Bemærk at backend data ikke vil være anonymiserede.
Arbejdsmarkedsstyrelsen · A-kassekommunikation via webservices · Master Test Plan ·
Version 1.3 · 30. maj 2012
Side 18 af 29
Test data udstilles i de beskrevne miljøer, hvorfra de kan manipuleres vha. Arbejdsmarkedsportalen. Det er her A-kasserne har mulighed for at tilmelde, afmelde, fraværsmelde borgere, således at de i testen efterspurgte web service beskeder genereres. A-kasserne er selv ansvarlige for at generere den data der er behov for til at gennem-føre den beskrevne test.
8.1 Konfiguration af testmiljøer (WSRM) KC/Systemforvalter udsender et WSRM konfigurationsskema. De eksterne aftagere har ansvaret for at udfylde WSRM konfigurationsskemaet med den ønskede WSRM opsætning, så testmiljøerne kan konfigureres inden te-stens begyndelse.
9 Test status Der afholdes faste teststatusmøder hver uge i testforløbet, hvor en række test metrikker fremlægges og afrappor-teres. Formålet med statusmøderne er:
• Diskussion af testforløbets fremdrift • Imødekomme skred i testforløbets tidsplan • Fremlæggelse af fremdriftsrapport
Der er defineret følgende agenda for testmøderne:
1. Siden sidst 2. Fremdriftsrapportering (fejltrends og prosa) 3. Risikolisten 4. Indtil næste møde
9.1 Statuskategorier Der gøres brug af følgende statuskategorier til udført testarbejde (til opdatering af testlog):
Status Beskrivelse
Pass Item ”består” såfremt de i test casen beskrevne forventninger er mødt.
Fail Item består ikke eller der skal laves omfattende ændringer i testprocedurer.
Not tested Man vælger ikke at teste dette item.
Could not test Man er forhindret i at teste dette item (testen er blokeret).
9.2 Test metrikker For at følge de testaktiviteter, der afvikles som en del af testforløbet vil følgende metrikker blive benyttet:
• Testfremdriftsrapport • “Bugtrend”: Opsamling af aktive fejl sorteret ud fra prioritet • Open/Closed/Resolved metric • Total åbne vs. lukkede fejl
Disse testmetrikker vil blive afrapporteret til kunden stillet til rådighed for medlemmerne af testgruppen hver dag i integrationstest-, end-to-end- test og kundetestperioden.
9.3 Testrapportering Hver enkelt A-kasse har ansvaret for at udarbejde en teststatusrapport under de planlagte testfaser. Test rappor-ten skal indeholde en summering af den foregående uges test, samt en vurdering af status for de funktionelle om-råder – Listet i appendix C - Det overordnede scope for testen i fase 1.
Arbejdsmarkedsstyrelsen · A-kassekommunikation via webservices · Master Test Plan ·
Version 1.3 · 30. maj 2012
Side 19 af 29
Testrapporten skal sendes til Tøger Nørgaard, Nicolai L. Nielsen og Anders Ellegaard Dahl hver mandag inden kl. 12:00.
9.4 Mødeoversigt Mødeoversigten er en overordnet plan over opstarts-, status- og godkendelsesmøder i testforløbet for både de in-terne AMS integrationstest samt de eksterne testforløb med KMD og ML.
Mødetype og formål Testfase Deltagere Dato
Test readiness review – Test Slot 1 - Integrationstest (slot 1)
KC A-Kasser
Mandag 11/6
Test readiness review – Test Slot 2 - Integrationstest (slot 2)
KC A-Kasser
Mandag 30/7
Test readiness review – Test Slot 3 - Integrationstest (slot 3)
KC A-Kasser
Mandag 6/8
Test statusmøde
- Integrationstest
KC AMS
På foranledning as AMS
9.5 Generelle accept- og stopkriterier Dette afsnit beskriver de generelle accept- og stopkriterier for en testfase. En test er accepteret/bestået, hvis det fejlniveau, som er afdækket ved prøven, ligger under det aftalte fejlniveau. Fejlniveauet opgøres ved optælling af fejl i fire fejlkategorier, der defineres ud fra nedenstående skema. Stopkriterier indebærer en vurdering af det acceptable niveau af (antal) fejl, der kan danne grundlag for at en test (eller en serie af tests) skal suspenderes/indstilles. En test kan med fordel suspenderes, hvis der findes for mange fejl, da det ikke giver værdi at gennemføre eller fortsætte prøven – det er blot spild af ressourcer. Ved fejlrapportering og godkendelse anvendes følgende skema over fejlkategorier og acceptkriterier
Fejlkategori Beskrivelse Acceptkriterie
Kategori 1 Kritisk fejl
Programmel/udstyr/enhed har fejl, der medfører, at programmel/udstyr/enhed er utilgængelig. Andre mangler i forhold til opstillede krav, der er til hinder for Løsningens anvendelse, sidestilles hermed.
Brugervenligheden for en af de mest anvendte dele al Leverancen medfører produktionstab hos de brugende enheder.
Omgåelse er ikke mulig og det tjener ikke noget for-nuftigt formål at gennemføre prøven.
Opstår sådanne fejl, indstilles prøven.
Ingen fejl
Kategori 2 Alvorlig fejl
Arbejdsmarkedsstyrelsen · A-kassekommunikation via webservices · Master Test Plan ·
Version 1.3 · 30. maj 2012
Side 20 af 29
Programmel/udstyr/enhed har fejl der medfører, at Programmel/udstyr/enhed er utilgængelig. Andre mangler i forhold til opstillede krav, der er til hinder for Løsningens anvendelse, sidestilles hermed.
Brugervenligheden af Leverancen er ikke optimal på grund af generende og overflødige trin i ar-bejdsgangen
Omgåelse er mulig. Opstår sådanne fejl, kan Kunden vælge at indstille
prøven.
Ingen fejl
Kategori 3 Ikke-kritisk fejl
Programmel/udstyr/enhed har fejl, der medfører gene for Brugere.
Andre mangler i forhold til opstillede krav, der er til gene for Brugere, sidestilles hermed.
Alternativer er tilgængelige. Fejlen kan afhjælpes i prøveperioden. Ved flere end 5 af disse fejl kan Kunden vælge at ind-
stille prøven.
Max 5 fejl
Kategori 4 Kosmetisk fejl
Programmel/udstyr/enhed har fejl, der medfører min-dre gene for Brugerne og fejlen er ikke blokerende. Andre mangler i forhold til opstillede krav, der medfø-rer mindre eller ingen gene for Brugere, sidestilles hermed.
Fejlen kan umiddelbart rettes. Ved flere end 30 mindre generende fejl kan Kunden
vælge at indstille prøven med mindre andet aftales.
Max 30 fejl
De fire fejlkategorier bruges ved kategorisering af fejl uanset hvornår og ved hvilken prøve, den pågældende fejl er afdækket. Det er som udgangspunkt i kundetestfasen Kunden, der afgør, om der er tale om en kategori 1-, 2-, 3-, eller 4-fejl, samt om der ved kategori 3-fejl er anvist en anvendelig omgåelse. Kunden kan i Leverancekontrakten/bestillingen tilpasse antallet af maksimale fejl i kategori 3-4 i afprøvnings-planen for den enkelte Leverance i både op- og nedadgående retning. Fejlkategoriseringen vedrører fejl ved selve Leverancen. En fejl i f.eks. kategori 4 kan imidlertid af den ene eller anden grund have en udsættende virkning på udførelse af afvikling af prøven på andre områder. Alle fejl skal derfor prioriteres i forhold til afvikling af prøvearbejdet, således at alle fejl med opsættende virkning henføres til den højst prioriterede kategori af de konstaterede fejl. Leverandøren er forpligtet til at rette sådanne fejl på linje med kategori 1- og 2-fejl. Fejlniveau (Master) Beståelseskriterier på Master-testplan niveau indebærer følgende:
• Alle underliggende testplaner er færdigtestet inden for rammerne af accept kriterierne • Der skal være gennemført alle testpasses for de i master testplanen definerede testområder
Fejlniveau (funktioner) Beståelseskriterier for funktionsniveauer indebærer:
Arbejdsmarkedsstyrelsen · A-kassekommunikation via webservices · Master Test Plan ·
Version 1.3 · 30. maj 2012
Side 21 af 29
Alle test cases indenfor den enkelte funktion er gennemført det maksimale antal fejl i enkelte fejlkategorier, som anført i skemaet ovenfor.
10 Organisering Herunder beskrives testforløbets organisering i form af et personskema samt et ansvarsskema. Såfremt der er ændringer til nedenstående skema bedes følgende personer notificeret: Tøger Nørgaard & Nicolai L. Nielsen
10.1 Personskema
Person Rolle Virksomhed E-mail
Tøger Nørgaard Projektleder KC [email protected]
Nicolai L. Nielsen Test Manager KC [email protected]
Michael Lund Software tester KC [email protected]
Laust Christensen Software tester KC [email protected]
Hanne Skou Poulsen Test ansvarlig 3F: Facilia
Facilia [email protected]
Mark Svensson Test ansvarlig FOA FOA [email protected]
Steffen Dyrberg Test ansvarlig Tieto: EMO & Modulus
Tieto [email protected]
Karsten Madsen Test Ansvarlig ASE ASE [email protected]
Tue Mark Jensen Test Ansvarlig KMD KMD [email protected]
Peter Gøtze Test Ansvarlig KMD: Winnie
Helle Elnegaard Test Ansvarlig Frie Funktionærer
Frie Funkti-onærer
Anders Ellegaard Dahl Projektleder AMS [email protected]
Alex Larsen Projektleder AMS [email protected]
Fleming Jensen Test Manager AMS [email protected]
10.2 Ansvarsskema
Ansvarsområde Personer Virksomhed
Master Testplan Nicolai L. Nielsen KC
Nicolai L. Nielsen/ Tøger Nørgaard KC Teststrategi
Flemming Jensen AMS
Anders Ellegaard Dahl (projektleder) AMS
Alex Larsen (projektleder) AMS
Flemming Jensen AMS
Beslutningstagere
Tøger Nørgaard (Projektleder) KC
Ansvarlig for at udviklet funktionalitet er Tøger Nørgaard KC
Arbejdsmarkedsstyrelsen · A-kassekommunikation via webservices · Master Test Plan ·
Version 1.3 · 30. maj 2012
Side 22 af 29
Anders Ellegaard Dahl AMS
Hanne Skou Poulsen Facilia
Mark Svensson FOA
Steffen Dyrberg Tieto
Karsten Madsen ASE
Peter Gøtze KMD
klar til test
Helle Elnegaard Frie Funktio-nærer
Flemming Jensen AMS Godkendelse af den interne integrations-test Nicolai L. Nielsen KC
Nicolai L. Nielsen KC
Flemming Jensen AMS
Tøger Nørgaard KC
Hanne Skou Poulsen Facila
Mark Svensson FOA
Steffen Dyrberg Tieto
Karsten Madsen ASE
Peter Gøtze KMD
Godkendelse af intgrationstesten med A-kasserne
Helle Elnegaard Frie Funktio-nærer
Release management Torben Espersen SF
10.3 Procesgodkendelse Procesgodkendelse indebærer identificering af testpersoner, som kan godkende at en test er gennemført.
Person Rolle Testproces Virksomhed
Nicolai L. Nielsen Test manager Funktionstest Integrationstest (Intern/ekstern) Idriftsættelsestest Datakonverteringstest
KC
Flemming Jensen Test manager Funktionstest Kundetest Integrationstest Driftstest
AMS
Tøger Nørgaard Projektleder Review på testplaner Accepttest Integrationstest Driftstest Datakonverteringstest
KC
Anders Ellegaard Projektleder Review på testplaner AMS
Arbejdsmarkedsstyrelsen · A-kassekommunikation via webservices · Master Test Plan ·
Version 1.3 · 30. maj 2012
Side 23 af 29
Dahl Accepttest Integrationstest Driftstest Datakonverteringstest
Alex Larsen Projektleder Review på testplaner Accepttest Integrationstest Driftstest Datakonverteringstest
AMS
Hanne Skou Poulsen Test ansvarlig Komponenttest - Facilia Integrationstest - Facilia
Facilia
Mark Svensson Test ansvarlig Komponenttest - FOA eget system Integrationstest - FOA eget system
FOA
Steffen Dyrberg Test ansvarlig Komponenttest - EMO & Modulus Integrationstest - EMO & Modulus
Tieto
Karsten Madsen Test ansvarlig Komponenttest - ASE eget system Integrationstest - ASE eget system
ASE
Peter Gøtze Test ansvarlig Komponenttest - Winnie Integrationstest - Winnie
KMD
Helle Elnegaard Test ansvarlig Komponenttest - FF eget system Integrationstest - FF eget system
Frie Funktio-nærer
A Glossary Herunder beskrives termer benyttet i dette dokument (og tests) generelt:
10.4 Aktører
Aktør Beskrivelse
AMS Arbejdsmarkedsstyrelsen
AMS10 AMS 10. Kontor
CC CyberCom Group AB
KC Knowledge Cube A/S
SF Systemforvalteren
CM Change Manager
Arbejdsmarkedsstyrelsen · A-kassekommunikation via webservices · Master Test Plan ·
Version 1.3 · 30. maj 2012
Side 24 af 29
RM Release Manager
10.5 Begreber
Begreb Beskrivelse
AMP Arbejdsmarkedsportalen (AMP) understøtter sagsbehandling og styring af be-skæftigelsesindsatsen. Portalen er et fælles redskab for de professionelle aktører - på tværs af stat, kommuner, a-kasser og andre aktører.
Eksterne aftagere Leverandører af systemer til kommuner/jobcentre.
TASS Match En samlet funktionalitet, der understøtter jobcenterets og anden aktørs registre-ring af oplysninger om kontaktforløb herunder samtaler og resultatet af match-vurderinger og jobplanlægningen – for borgere i Match-målgrupperne.
LOR Lead of the Reporter. Den ansvarlige leder (for en person som finder en afvigel-se). Dette vil typisk være testlederen.
Master Test Plan Dette dokument. Indeholder Test Planen, alle Test Items og Test Specifikationer for alle Test Items.
TDS TransferDataService. Flytte- og opstartsdata servicen som benyttes til at flytte borgere mellem jobcentre og til at flytte data i forbindelse med opstart af syste-mer fra kommunale leverandører.
Test specifikation Beskrivelse af, hvordan Test Items testes, hvem der skal teste dem, samt hvor og hvornår de skal testes. I IEEE 829 kaldes dette ”Test design specification”. Dog indeholder Master Test Planens specifikationer ikke ”identifikation af tilknyttede højniveau test cases”. Dette vil i stedet fremgå i separate dokumenter og af test-loggen.
Test Item Det enkelte element (genstand), der er under test.
Test procedure specifi-kation
Et dokument, der specificerer en rækkefølge af handlinger for afviklingen af en test (en samling af test cases). I IEEE 829 kaldes dette også “Test procedure specification”.
Test case Et sæt inputværdier, startbetingelser for afvikling, forventede resultater, postbe-tingelser for afvikling designet med henblik på et bestemt mål eller testbetingelse, så som at aktivere en bestemt programsti eller at verificere overensstemmelse med et specifikt krav.
Test log En kronologisk registrering (log) af relevante detaljer om afviklingen af test.
Test status rapport Samlet statusrapport for gennemførte testarbejde.
FogBugz Bug-tracker. Benyttes til registrering og håndtering af afvigelser funder under test.
Arbejdsmarkedsstyrelsen · A-kassekommunikation via webservices · Master Test Plan ·
Version 1.3 · 30. maj 2012
Side 25 af 29
B Dokumentstruktur Figur 5: Dokumentstruktur angiver dokumentstrukturen i forhold til master-testplanen samt de enkelte testpro-cedurer og test cases, der er omfattet af denne master-testplan.
Figur 5: Dokumentstruktur
Arbejdsmarkedsstyrelsen · A-kassekommunikation via webservices · Master Test Plan ·
Version 1.3 · 30. maj 2012
Side 26 af 29
C Det overordnede scope for testen i fase 1. DFDG hændelse Beskrivelse
af hændelse Webserviceunderstøttelse:
T, A T: Tilmelding af person i jobcenter A: Afmelding af person i jobcenter eller ophør af medlemskab i a-kassen
(WSRM) GetUnemploymentEnrollmentVersion4 GetLatestInterviewdate (WSRM) GetCancelUnemploymentEnrollmentVersion4
C CV kundenummer eller CV status ændres.
(WSRM) GetCVStatusVersion4
F30 Servicebesked om oprettelse eller ændring af Jobplan
(WSRM) GetJobplanStatusVersion1
F31 F32 F33 F34
Servicebesked om sygdom, rask-melding, ferie eller mindre intensiv indsats. Der kan også være registre-ret en opdatering eller sletning af hændelsen.
(WSRM) GetAbsenceVersion5 og GetDeleteAbsenceVersion5
Akasseskift og udmelding (MA og MT)
‐ Skift af a-kasse ‐ Udmelding af a-kasse ‐ Fremsendelse af uafslutte-
de fraværsfor-hold(servicebeskeder) ved a-kasseskift
Bl.a. (WSRM) GetMembershipCancellation
Funktionscertifikater – brug af disse til opkobling
CodeListService A‐kasse kan oprette adgang til Co‐deListServer og hente relevante Codelister.
CodeListService
WSRMkø A‐kasse kan åbne, tømme og afslut‐te WSRM‐køen korrekt
Formateret: Skrifttype:Times New Roman, Ingenunderstregning
Formateret: Skrifttype:Times New Roman
Formateret: Skrifttype:Times New Roman, Ingenunderstregning
Formateret: Skrifttype:Times New Roman
Formateret: Skrifttype:Times New Roman, Ingenunderstregning
Formateret: Skrifttype:Times New Roman, Ingenunderstregning
Formateret: Skrifttype:Times New Roman, Ingenunderstregning
Formateret: Skrifttype:Times New Roman, Ingenunderstregning
Formateret: Skrifttype:Times New Roman, Ingenunderstregning
Slettet: 6
Slettet: 6
Arbejdsmarkedsstyrelsen · A-kassekommunikation via webservices · Master Test Plan ·
Version 1.3 · 30. maj 2012
Side 27 af 29
D Workflows der bør efterprøves af a-kasserne i integrationstesten. DFDG hændelse Hvorledes Resultat T: Tilmelding af person i jobcenter
A-kassetester tilmelder person som dagpengemodtager
GetUnemploymentEnrollmentVersion4 Skubbes på WSRM-kø. A-kasse registrerer tilmelding i eget system
A-kassetester tilmelder person som dimittend og vedkommen-de har registreret en a-kasse
GetUnemploymentEnrollmentVersion4 Skubbes på WSRM-kø. A-kasse registrerer tilmelding i eget system
A-kassetester tilmelder person som dimittend og vedkommen-de har ej registreret en a-kasse
Ingenting
A-kassetester opdaterer a-kassetilhørsforhold i akassere-gistret (MT-afsendes) for en dimittend og dato for dagepen-geret er d.d.
GetUnemploymentEnrollmentVersion4 Skubbes på WSRM-kø. A-kasse registrerer tilmelding i eget system
A-kassetester tilmelder person til jobcentret (gamle T09)
GetUnemploymentEnrollmentVersion4 Skubbes på WSRM-kø. GetLatestInterviewdate skubbes på WSRM-kø A-kasse registrerer tilmelding i eget system og kan udlæse datoen for seneste cv eller jobsamtale.
DFDG hændelse Hvorledes Resultat A: Afmelding af person i jobcenter eller ophør af medlemskab i akassen
A-kassetester framelder person
GetUnemploymentEnrollmentVersion4 Skubbes på WSRM-kø. A-kasse registrerer afmelding i eget system
A-kassetester udmelder person af a-kasse
GetUnemploymentEnrollmentVersion4 Skubbes på WSRM-kø. A-kasse registrerer afmelding i eget system
DFDG hændelse Hvorledes Resultat C: CV kundenummer eller CV status ændres.
A‐kassetester opretter CV GetCVStatusVersion5 skubbes på WSRM-kø. A-kasse registrerer ændring i eget system
A‐kassetester sætter CV util‐gængeligt for søgning
A‐kassetester sætter CV til‐gængeligt for søgning
A‐kassetester ændrer status på CV
Formateret: Skrifttype:Times New Roman, 10 pkt,Ingen understregning,Skriftfarve: Sort
Formateret: Indrykning:Venstre: 0 pkt.
Formateret: Skrifttype:Times New Roman, 10 pkt
Formateret: Skrifttype:Times New Roman, 10 pkt,Ingen understregning,Skriftfarve: Sort
Formateret: Skrifttype: 10pkt
Arbejdsmarkedsstyrelsen · A-kassekommunikation via webservices · Master Test Plan ·
Version 1.3 · 30. maj 2012
Side 28 af 29
DFDG hændelse Hvorledes Resultat F30: Servicebesked om oprettelse eller ændring af Jobplan
A-kassetester opretter jobplan
GetJobplanStatusVersion1 skubbes på WSRM-kø. A-kasse registrerer hændelse i eget system
A-kassetester ændrer eksiste-rende jobplan
GetJobplanStatusVersion1 skubbes på WSRM-kø. A-kasse registrerer ændring i eget system og skal binde denne til eksisterende jobplan.
DFDG hændelse Hvorledes Resultat F31/F32: Medlemmet er meldt syg/rask
A‐kassetester sygemelder en dagpengemodtager
GetAbsenceVersion5 skubbes på WSRM-kø på datoen for sygdommens start eller hvis datoen overskrides. A-kasse registrerer ændring i eget system
A-kassetester raskmelder en dagpengemodtager
GetAbsenceVersion5 skubbes på WSRM-kø for datoen for raskmeldingen eller hvis datoen over-skrides. A-kasse registrerer ændring i eget system og skal koble raskmeldingen til en sygemelding.
A-kassetester sygemelder en dimittend
GetAbsenceVersion5 skubbes på WSRM-kø på datoen for dagpengeret.
DFDG hændelse Hvorledes Resultat F33: Servicebesked om ferimelding
A-kassetester opretter feriefor-hold
GetAbsenceVersion5 skubbes på WSRM-kø på datoen for registreringen. A-kasse registrerer ændring i eget system
A-kassetester ændrer et eksiste-rende ferieforhold
GetAbsenceVersion5 skubbes på WSRM-kø på datoen for registreringen. A-kasse registrerer ændring i eget system
DFDG hændelse Hvorledes Resultat F34: Mindre intensiv ind‐sats
A‐kassetester angiver at dag‐pengemodtager er omfattet af mindre intensiv indsats (angi‐
GetAbsenceVersion5 skubbes på WSRM-kø A-kasse registrerer ændring i eget system
Formateret tabel
Slettet: 6
Slettet: GetCancelUnemploy-mentEnrollmentVersion4 skubbes på WSRM-køen efterfølgende F32 (automatisk afmelding A som følge af sygemelding)¶
Slettet: 6
Slettet: GetUnemploymentEn-rollmentVersion4 skubbes på WSRM-køen efterfølgende F31 (automatisk Tilmelding T som følge af raskmelding)¶
Slettet: 6
Slettet: 6
Slettet: 6
... [1]
Arbejdsmarkedsstyrelsen · A-kassekommunikation via webservices · Master Test Plan ·
Version 1.3 · 30. maj 2012
Side 29 af 29
ver barsel inden for 6 uger, på vej på pension inden for 6 uger)
DFDG hændelse Hvorledes Resultat Sletning af F31/F32/ F33/F34
A‐kassetester sletter et fra‐værsforhold
GetDeleteAbsenceVersion5 skubbes på WSRM-kø A-kasse registrerer ændring i eget system
DFDG hændelse Hvorledes Resultat A‐kasseskift A-kassetester skifter a-
kassemedlemskab på en til-meldt dagpengemodtager (MT-hændelse)
GetUnemploymentEnrollmentVersion4 Skubbes på WSRM-kø (eksisterende hændelse i DFDG) A-kasse registrerer tilmelding i eget system GetAbsenceVersion5 for alle uafsluttede fra‐værsforhold skubbes på WSRM-kø. A-kasse registrerer ændringerne i eget system
Slettet: 6
Slettet: 6
Side 28: [1] Slettet Tøger Nørgaard 30-05-2012 17:21:00 A-kassetester sygemelder en
dimittend og a‐kassen er kendt.
GetAbsenceVersion6 skubbes på WSRM-kø på datoen for sygdommens start eller hvis datoen overskrides.